From mrw@sandstorm.net Tue Sep 1 06:37: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 517023A6907 for ; Tue, 1 Sep 2009 06:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 Kl-U2oqlp1Fy for ; Tue, 1 Sep 2009 06:37:26 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 6E95A3A68AD for ; Tue, 1 Sep 2009 06:37:26 -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 n81DbO86073472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2009 09:37:24 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <412E7B1A-AEAD-4ACD-8588-D6EFE6DDEAFF@sandstorm.net> From: Margaret Wasserman 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: Tue, 1 Sep 2009 09:37:26 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) 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: Tue, 01 Sep 2009 13:37:27 -0000 On Aug 31, 2009, at 5:02 PM, Joel M. Halpern wrote: > 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. I think that this rewording is a substantial improvement over the wording in the diffs that Dino sent. One typo: "checksum, field it" should be "checksum field, it" in the 6th line. Personally, I think that we should (at least) encourage people to check the checksum when a non-zero checksum is received. In other words, I would prefer to change "If an ETR receives a non-zero value in the checksum field, it MAY compute and validate" to "If an ETR receives a non-zero value in the checksum field, it SHOULD compute and validate". This would better correspond to what I thought we'd agreed on the list earlier, which is that an ETR may ignore a non-zero checksum, while still allowing systems to ignore inbound non-zero UDP checksums when they have a good reason for doing so. The reference to the Eubanks-Chimento draft (which is in the note Joel mentions above) should be changed to a normative reference, as it contains normative text necessary to implement this protocol (similar to the UDP RFC 768 reference). Assuming that you move the reference to the normative reference section, I believe that these changes would address tracker issues #9, #10 and #12. Margaret From mrw@sandstorm.net Tue Sep 1 06:42: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 3BC2B3A6840 for ; Tue, 1 Sep 2009 06:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 gZYo5V47YKJH for ; Tue, 1 Sep 2009 06:42:20 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id AD8363A685D for ; Tue, 1 Sep 2009 06:41: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 n81Dg06l073628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2009 09:42:00 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <04DC887D-C635-4D58-9E93-4959148B4480@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, 1 Sep 2009 09:42:02 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> X-Mailer: Apple Mail (2.935.3) 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: Tue, 01 Sep 2009 13:42:21 -0000 On Aug 31, 2009, at 5:47 PM, Dino Farinacci wrote: > > > UDP Checksum: this field MAY be transmitted as zero by an ITR and > when received by an ETR, MUST accept the packet for forwarding. Aside from the grammatical issue with this sentence (no subject), the ETR does not really "accept a packet for forwarding", it decapsulates it and forwards the inner packet. So, this isn't quite right, either... > > When an ITR transmits a non-zero value, an ETR MAY verify the > checksum value. The ETR validates a checksum when it receives it, not when the ITR transmits it... > 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. Is it really necessary for us to describe the normal parts of UDP checksum handling here? What about saying less? Something like: UDP Checksum: This is the UDP checksum field, as described in [RFC 768] as updated by [UDP-TUNNELS]. And leave it at that? Margaret From mrw@sandstorm.net Tue Sep 1 06:45: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 0A7B53A6F4E for ; Tue, 1 Sep 2009 06:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 wmwUVCz2TCYx for ; Tue, 1 Sep 2009 06:45:09 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 294493A6F04 for ; Tue, 1 Sep 2009 06:45:09 -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 n81DiqYK073903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2009 09:44:52 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <109C5821-8563-4AD2-80BC-5B3192319CE4@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <64D637CF-771E-465E-9464-1D4031544A1F@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, 1 Sep 2009 09:44:54 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3AFA.8060908@joelhalpern.com> <64D637CF-771E-465E-9464-1D4031544A1F@cisco.com> X-Mailer: Apple Mail (2.935.3) 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: Tue, 01 Sep 2009 13:45:10 -0000 Hi Dino, You and Joel are digging into the details of the R-bit here, but personally I don't understand why we need an R-Bit at all? Could you please explain the purpose of the R-bit and what the structure of the LISP header will be when it is set? From what I've heard so far, it sounds like the R-bit is a one-bit version field, where (at least some) of the fields in the LISP header will have other purposes when it is set. If so, why do we believe we need to use a version bit for that purpose, rather than using one the other extensions methods we've discussed (new UDP port or control- plane signaling)? Thanks, Margaret On Aug 31, 2009, at 5:52 PM, 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 >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From mrw@sandstorm.net Tue Sep 1 06:48: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 EEA2C3A6FB9 for ; Tue, 1 Sep 2009 06:48:29 -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 OvKBpSqFsb8J for ; Tue, 1 Sep 2009 06:48:29 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 6DE123A6FCB for ; Tue, 1 Sep 2009 06:48:27 -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 n81DmbSj074071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2009 09:48:37 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <876D9BC8-4D97-41E9-B469-89DEF7D6F1EB@sandstorm.net> From: Margaret Wasserman 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: Tue, 1 Sep 2009 09:48:39 -0400 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) 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 13:48:30 -0000 On Aug 31, 2009, at 8:48 PM, Joel M. Halpern 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. From what I've heard so far, this seems like the best choice. After we've run some experiments and have better understanding of the problems that we run into with locator liveness, etc. we will be in a better position to know how/if this sort of hint could be useful in practice. If we reserve the field for now, we can use it for whatever makes sense when we know more. Margaret From mrw@sandstorm.net Tue Sep 1 06:59: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 E10043A6881 for ; Tue, 1 Sep 2009 06:59:59 -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 Frbh7L3VwyGD for ; Tue, 1 Sep 2009 06:59:59 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 120B63A6861 for ; Tue, 1 Sep 2009 06:59:58 -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 n81E07hV074686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2009 10:00:07 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <224C489C-6E82-4ED8-9134-DC1EF69AFD78@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, 1 Sep 2009 10:00:09 -0400 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> X-Mailer: Apple Mail (2.935.3) 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 14:00:00 -0000 On Aug 31, 2009, at 8:53 PM, Dino Farinacci wrote: > How about this: > > M: this bit is reserved for use by the LISP mobile-node design > documented in [LISP-MN]. > > Okay? This doesn't seem like a good choice to me, because this bit is completely useless if mobile nodes (ones that implement LISP-MN) are the only ones that know about it. In order for this bit to be useful to mobile nodes, the LISP xTRs at their (non-mobile) correspondent sites need to recognize this bit, and act differently when it is present. Since we don't know, at this point, the specifics of what the remove LISP nodes should do when this bit is present, I think we should leave the bit undefined until we do. If we discover, in our experiments, that there are things that non- mobile LISP nodes should do to work well with mobile LISP nodes, we can add the appropriate bit(s), if any, along with the description of what to do when they are present, to the main LISP draft at that time. Margaret From hartmans@mit.edu Tue Sep 1 07:25: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 39DAC28C64E for ; Tue, 1 Sep 2009 07:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 4VsLwCJO2QFQ for ; Tue, 1 Sep 2009 07:25: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 7C6AC3A67FB for ; Tue, 1 Sep 2009 07:25:10 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 86920646C1; Tue, 1 Sep 2009 10:25:20 -0400 (EDT) To: Margaret Wasserman References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> From: Sam Hartman Date: Tue, 01 Sep 2009 10:25:20 -0400 In-Reply-To: (Margaret Wasserman's message of "Tue\, 1 Sep 2009 09\:42\:02 -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] 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: Tue, 01 Sep 2009 14:25:11 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> Is it really necessary for us to describe the normal Margaret> parts of UDP checksum handling here? What about saying Margaret> less? Something like: I think we need to at least say that for LISP data plane packets, an ITR MAY send a 0 checksum. I'd assume that the udp-tunnels draft will not mandate that all tunneling protocols allow senders to send 0 checksums, but instead will create that option and allow tunnel protocols to enable sending 0 checksums after doing the necessary analysis (your issue #13, I believe). So, simply referring to that draft doesn't seem enough. My personal preferences are 1) Joel's text with Margaret's updates saying receivers SHOULD verify checksums 2) Joel's text with typo corrections 3) Margaret's short text above with the additional of "LISP ITRs MAY send a zero checksum" 4) Margaret's text in the thread about closing issues #9, #10 and #12 From jnc@mercury.lcs.mit.edu Tue Sep 1 07:34: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 1C3EA3A67B2 for ; Tue, 1 Sep 2009 07:34:38 -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 lBPNwchWtkjx for ; Tue, 1 Sep 2009 07:34: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 7D6623A6FDA for ; Tue, 1 Sep 2009 07:33:50 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 191FB6BE574; Tue, 1 Sep 2009 10:34:03 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090901143403.191FB6BE574@mercury.lcs.mit.edu> Date: Tue, 1 Sep 2009 10:34:03 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu 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: Tue, 01 Sep 2009 14:34:38 -0000 > From: Margaret Wasserman > Could you please explain the purpose of the R-bit and what the > structure of the LISP header will be when it is set? The R-bit is for use in experimentation (and perhaps adoption into service, if it proves to be useful) with mapping 'versioning' - i.e. a way of detecting out-of-date mappings held at ITRs. As to the header usage, I think the wording has been left more 'generic' than the likely actual use will be, because we wanted to leave as few constraints as possible (because until we do it, we won't know exactly what all data/ information we will need). My understanding/sense is that this mechanism is likely to use just the 32-bit field in the header, 'time-shared' with the normal locator-status functionality which uses that field. > From what I've heard so far, it sounds like the R-bit is a one-bit > version field, where (at least some) of the fields in the LISP header > will have other purposes when it is set. Not really, to me, because to me a version field would imply a different header layout entirely. To take one (or more) fields and change its semantics, based on the setting of a flag bit, to me doesn't really qualify as a 'new heade version'. Yeah, this is to some degree just terminology, but still, I think it is a useful distinction. We do have a very short header, because of space overhead concerns, and to me it makes perfect sense to 'time-share' a field between a usage which does not _have_ to be in every last packet if the protocol is to function (think the TCP sequence number), and another low-duty-cycle control function. This is especially apt in this case, as the two functions (xTR liveness, and mapping freshness) are closely related. > why do we believe we need to use a version bit for that purpose, rather > than using one the other extensions methods we've discussed (new UDP port or > control- plane signaling)? Well, in this particular case, neither really makes sense. Using a separate port just to do a different control function would be overkill, I think. And it's being piggy-backed on the user-data traffic _precisely_ to avoid the overhead of separate control traffic. (I.e. while it's not done _all_ the time, it's not a very _rare_ operation either.) Having said that, IIRC there are other unused, 'must-be-zero' flag bits in what is now the first byte that _could_ be dedicated to a version field - i.e. flag a different header format. (There are 8 bits total, and if my memory is working, only 5 have been allocated - and there are some combinations of the existing ones which are currently illegal, and could also be used to signal a new header format.) We haven't gone ahead and allocated such bits/values because we want to retain maximum flexibility for the future - we may decide that function X is more important than a version field (since we do, as you point out, have other options for a new header format). Noel From hoefling@informatik.uni-wuerzburg.de Tue Sep 1 07:45: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 5935028C736 for ; Tue, 1 Sep 2009 07:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 sTm+KbeiERxx for ; Tue, 1 Sep 2009 07:45:06 -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 8396B28C30D for ; Tue, 1 Sep 2009 07:45:06 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 0EA86199AE5; Tue, 1 Sep 2009 16:45:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 01E0A199AE2; Tue, 1 Sep 2009 16:45:17 +0200 (CEST) Received: from [132.187.12.113] (win3113.informatik.uni-wuerzburg.de [132.187.12.113]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id E1A79199AE0; Tue, 1 Sep 2009 16:45:13 +0200 (CEST) Message-ID: <4A9D3379.6030809@informatik.uni-wuerzburg.de> Date: Tue, 01 Sep 2009 16:45:13 +0200 From: =?ISO-8859-1?Q?Michael_H=F6fling?= Organization: University of Wuerzburg 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 X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de 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: Tue, 01 Sep 2009 14:45:07 -0000 Hi Dino, while I read the -04 diff I found one thing that sticked into my eyes. Section 13 states that only echo-noncing is described in -04. > 13. Prototype Plans and Status [...] > As of this writing the following accomplishments have been achieved: [...] > 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. This is however not correct and should thus be changed to the following: ### START ### An experimental implementation has been written for three locator reachability algorithms. Both the so-called echo-noncing and the so-called RLOC-probing are documented in this specification. The third one is called TCP-counts, which will be documented in future drafts. ### STOP ### Regards, Michael -- Michael Hoefling, M.S. University of Wuerzburg, Institute of Computer Science Department of Distributed Systems (Informatik III) Am Hubland, D-97074 Wuerzburg, Germany, room A202 phone: (+49)-931/31-86634 mailto:hoefling@informatik.uni-wuerzburg.de From hartmans@mit.edu Tue Sep 1 07:49: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 9BDFB28C73F for ; Tue, 1 Sep 2009 07:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=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 bhxYF+qAcelx for ; Tue, 1 Sep 2009 07:49:51 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id C9B7328C76C for ; Tue, 1 Sep 2009 07:49:51 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9B424646C1; Tue, 1 Sep 2009 10:49:31 -0400 (EDT) To: Jari Arkko , lisp@ietf.org References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> From: Sam Hartman Date: Tue, 01 Sep 2009 10:49:31 -0400 In-Reply-To: <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> (Dino Farinacci's message of "Wed\, 26 Aug 2009 12\:29\:26 -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 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: Tue, 01 Sep 2009 14:49:52 -0000 Jari, thanks for making the high level decision on LISP mobility. My interpretation of your wording as chair follows; please let me know if I got it wrong. First, as always, we're designing an extensible protocol. So, extensibility features that might be needed if we expand our scope in the future are in scope--that includes things like making sure we could allocate a flag in the future,making sure we have ways to evolve ITR/ETR behavior in the future, etc. I.E. the sorts of holes Noel is talking about. However, at this point, the IETF has not considered the following questions, and this working group is not chartered to consider them: 1) is LISP going to be part of a mobility solution 2) If so, how course-grain/fine-grain 3) How does LISP fit together with protocols like MIP6, MIP4, NETLMM, NEMO 4) Will any LISP mobility solution be based on the current LISP mobility architecture As a personal note, I'd recommend anyone interested in LISP and mobility take a look at draft-ietf-mext-aero-reqs-04; I read it as a secdir reviewer. It seems that some of those requirements may not be such a good fit for our existing mobility toolbox. I have not thought much about whether LISP would be a good fit for them, but it seems worth thinking about. In terms of mobility impact on our base specs, we're not currently considering mobility or mobility related changes in the base specs, beyond the sort of leaving room for future expansion we discussed above. Even if it were in scope, we'd need to come to a conclusion on whether LISP was a mobility approach that the IETF wanted to pursue before we'd want to consider mobility issues in the LISP design. The boundary between mobility, which is out of scope for now, and things like renumbering of a multi-homed site can be a bit fuzzy. My personal belief is that when you start considering issues like preserving connections when all existing RLOCs change, rapid change of RLOCs, or optimizing for /32 or /128 EID allocations, you're definitely into the mobility realm. Sam Hartman LISP co-chair From jnc@mercury.lcs.mit.edu Tue Sep 1 07:59: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 B3A0D3A6B57 for ; Tue, 1 Sep 2009 07:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 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 Sgko9mvtoXQx for ; Tue, 1 Sep 2009 07:59: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 6BEF23A6AC0 for ; Tue, 1 Sep 2009 07:59:26 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1C7726BE574; Tue, 1 Sep 2009 10:57:49 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090901145749.1C7726BE574@mercury.lcs.mit.edu> Date: Tue, 1 Sep 2009 10:57:49 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu 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: Tue, 01 Sep 2009 14:59:30 -0000 > From: Sam Hartman > I think we need to at least say that for LISP data plane packets, an > ITR MAY send a 0 checksum. We may want to upgrade that to a "SHOULD"; my reasoning for this is a cost-benefit analysis. Furthermore, depending on how we word the rest of the statement (i.e. covering reception processing), it may actually be very desirable to suppress generation of checksums. One has to start with the recognition that this non-end-end checksum buys us very little, simply because it's non-end-end. (In fact, if we have applications which have an actual use for damaged packets, it will have a _negative_ impact, as it will cause such packets to be discarded.) Since it buys us little/no benefit, if it has any cost at all, it's going to fail a cost-benefit analysis. This alone would have pushed me toward tossing the checksum altogether (i.e. MUST), but I understand that there are some boxes on which that would present real difficulties, so I can see that that is not a feasible choice. As to the costs, one cannot fully work out them out unless one knows exactly what the ETRs will be doing (and will be mandated to do), but here are some points. On an ETR which is doing checksums in software, _iff_ it checksums all non-zero-checkum UDP packets, that overhead will slow down packet processing, and reduce potential throughput. Whether this is significant is in the eye of the beholder, I suspect. More seriously, potentially, we've also been informed that there are boxes on which it is expensive (or even impossible), to calculate checksums - e.g. because the box doesn't normally have access to the entire packet. I would _assume_ that this holds true for _checking_ checksums too. Were we to mandate (or even just 'SHOULD' checking checksums), that could prove problematic for those boxes - and moreso if a high percentage of the packets they receive have checksums set. > receivers SHOULD verify checksums Same analysis, basically. A non end-end checksum buys one very little, it anything at all - especially since link-level-checksums _already_ filter out most damaged packets. So I fail entirely to see that the benefits of checking them are worth the costs involved in so doing. Sure, if it's difficult to _suppress_ on any particular box, let it check them. But IMO we shouldn't encourage useless (i.e. wasted) processing in the spec. Noel From mrw@sandstorm.net Tue Sep 1 07:59: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 D99E23A6FEF for ; Tue, 1 Sep 2009 07:59:32 -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 x-pmw7hrOZqS for ; Tue, 1 Sep 2009 07:59:32 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id F0A563A6F45 for ; Tue, 1 Sep 2009 07:59: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 n81EwM8N078568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2009 10:58:22 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: 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, 1 Sep 2009 10:58:22 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> X-Mailer: Apple Mail (2.935.3) 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: Tue, 01 Sep 2009 14:59:32 -0000 On Sep 1, 2009, at 10:25 AM, Sam Hartman wrote: >>>>>> "Margaret" == Margaret Wasserman writes: > > > Margaret> Is it really necessary for us to describe the normal > Margaret> parts of UDP checksum handling here? What about saying > Margaret> less? Something like: > > I think we need to at least say that for LISP data plane packets, an > ITR MAY send a 0 checksum. Good point. Margaret From dino@cisco.com Tue Sep 1 08:34: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 2989A3A6FC7 for ; Tue, 1 Sep 2009 08:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 P7Oj4sfbUU-k for ; Tue, 1 Sep 2009 08:34:29 -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 6C49F3A6CB8 for ; Tue, 1 Sep 2009 08:34:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAD7cnEqrR7MV/2dsb2JhbADEd4hBAY9/BYQb X-IronPort-AV: E=Sophos;i="4.44,312,1249257600"; d="scan'208";a="379765903" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2009 15:34:42 +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 n81FYgJk026326; Tue, 1 Sep 2009 08:34:42 -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 n81FYgms028281; Tue, 1 Sep 2009 15:34: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); Tue, 1 Sep 2009 08:34:42 -0700 Received: from [192.168.1.4] ([10.21.65.120]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 08:34:42 -0700 Message-Id: From: Dino Farinacci To: =?ISO-8859-1?Q?Michael_H=F6fling?= In-Reply-To: <4A9D3379.6030809@informatik.uni-wuerzburg.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, 1 Sep 2009 08:34:41 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9D3379.6030809@informatik.uni-wuerzburg.de> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 01 Sep 2009 15:34:42.0247 (UTC) FILETIME=[B9A84570:01CA2B19] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=461; t=1251819282; x=1252683282; 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=09Friday=20Sep=204t h |Sender:=20; bh=JflDNDqqVevEl+AX3dUjJtzQP+W1Ljz5PE9rVL02/ug=; b=Ns1xzGl9pEhS5brx0PwUFXIKvxddjb9C3btWNEhCvBPzVvX7UUsa15zPs2 xb5oQkwUvc99pR/Zdy45X9znuSfPcEfrojz0tt1MgTV2mTDevmBrNq74Pzz1 7qOGyZSiYRC1CGddY7hhD3LotBM2pAne296VxLhsoIm96iaq6PxEQ=; 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: Tue, 01 Sep 2009 15:34:30 -0000 > This is however not correct and should thus be changed to the > following: > > ### START ### > An experimental implementation has been written for three > locator reachability algorithms. Both the so-called echo-noncing > and the so-called RLOC-probing are documented in this specification. > The third one is called TCP-counts, which will be documented in > future drafts. > ### STOP ### Thanks Michael. I will make the change. Dino From jmh@joelhalpern.com Tue Sep 1 08:40: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 3EA7228C2E3 for ; Tue, 1 Sep 2009 08:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 dz2vJ3QKu93G for ; Tue, 1 Sep 2009 08:40:26 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 06A3328C804 for ; Tue, 1 Sep 2009 08:39:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8CF54430373; Tue, 1 Sep 2009 08:40:04 -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 02AD543036E; Tue, 1 Sep 2009 08:40:03 -0700 (PDT) Message-ID: <4A9D4052.8040008@joelhalpern.com> Date: Tue, 01 Sep 2009 11:40:02 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Noel Chiappa References: <20090901143403.191FB6BE574@mercury.lcs.mit.edu> In-Reply-To: <20090901143403.191FB6BE574@mercury.lcs.mit.edu> 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: Tue, 01 Sep 2009 15:40:28 -0000 I am not following the reasoning on the R bit. In particular, how can we know that it should never be set with N and L, but not know what it means? And do we really expect a receiver who does not understand the R bit to ignore messages with the R bit set and the N or L bits sets? Why? It seems both simpler and more versatile to simpler declare the R bit to be reserved. And to remove all the comments about N or L not being set with R. Yours, Joel Noel Chiappa wrote: > > From: Margaret Wasserman > > > Could you please explain the purpose of the R-bit and what the > > structure of the LISP header will be when it is set? > > The R-bit is for use in experimentation (and perhaps adoption into service, > if it proves to be useful) with mapping 'versioning' - i.e. a way of > detecting out-of-date mappings held at ITRs. > > As to the header usage, I think the wording has been left more 'generic' than > the likely actual use will be, because we wanted to leave as few constraints > as possible (because until we do it, we won't know exactly what all data/ > information we will need). My understanding/sense is that this mechanism is > likely to use just the 32-bit field in the header, 'time-shared' with the > normal locator-status functionality which uses that field. > > > > From what I've heard so far, it sounds like the R-bit is a one-bit > > version field, where (at least some) of the fields in the LISP header > > will have other purposes when it is set. > > Not really, to me, because to me a version field would imply a different > header layout entirely. To take one (or more) fields and change its > semantics, based on the setting of a flag bit, to me doesn't really qualify > as a 'new heade version'. Yeah, this is to some degree just terminology, but > still, I think it is a useful distinction. > > We do have a very short header, because of space overhead concerns, and to me > it makes perfect sense to 'time-share' a field between a usage which does not > _have_ to be in every last packet if the protocol is to function (think the > TCP sequence number), and another low-duty-cycle control function. This is > especially apt in this case, as the two functions (xTR liveness, and mapping > freshness) are closely related. > > > why do we believe we need to use a version bit for that purpose, rather > > than using one the other extensions methods we've discussed (new UDP port or > > control- plane signaling)? > > Well, in this particular case, neither really makes sense. Using a separate > port just to do a different control function would be overkill, I think. And > it's being piggy-backed on the user-data traffic _precisely_ to avoid the > overhead of separate control traffic. (I.e. while it's not done _all_ the > time, it's not a very _rare_ operation either.) > > Having said that, IIRC there are other unused, 'must-be-zero' flag bits in > what is now the first byte that _could_ be dedicated to a version field - > i.e. flag a different header format. (There are 8 bits total, and if my > memory is working, only 5 have been allocated - and there are some > combinations of the existing ones which are currently illegal, and could also > be used to signal a new header format.) We haven't gone ahead and allocated > such bits/values because we want to retain maximum flexibility for the future > - we may decide that function X is more important than a version field (since > we do, as you point out, have other options for a new header format). > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Tue Sep 1 08:40: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 F002828C7D5 for ; Tue, 1 Sep 2009 08:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 xhGNbZcj87jC for ; Tue, 1 Sep 2009 08:40: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 047093A7020 for ; Tue, 1 Sep 2009 08:40:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPLcnEqrR7PE/2dsb2JhbADEfYhBAY9/BYJAgVuKYQ X-IronPort-AV: E=Sophos;i="4.44,312,1249257600"; d="scan'208";a="235868321" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 01 Sep 2009 15:40:21 +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 n81FeLA3009676; Tue, 1 Sep 2009 08:40:21 -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 n81FeLCc004201; Tue, 1 Sep 2009 15:40:21 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, 1 Sep 2009 08:40:21 -0700 Received: from [192.168.1.4] ([10.21.65.120]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 08:40:21 -0700 Message-Id: <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@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, 1 Sep 2009 08:40:20 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 01 Sep 2009 15:40:21.0055 (UTC) FILETIME=[839A44F0:01CA2B1A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=536; t=1251819621; x=1252683621; 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]=20Suggested=20UDP=20checksum=20t ext |Sender:=20; bh=ba4jh89/UdRezKg9axd7M/kbv98vC6jHbo3p+dBb44w=; b=JXAh6efNGQY9yZPR7ycKgd1ty0SkmUohn3hGMjCj1p1TXzPUug+ZvHeMn2 zRdmdBMIn0WdYIO51RXZU+ajO44zeB/plIPkYA0pbTr+XdCM8m7NSWvPK5Me s0SNoc8zI9; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "lisp@ietf.org" , Margaret Wasserman 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: Tue, 01 Sep 2009 15:40:37 -0000 > My personal preferences are > > 1) Joel's text with Margaret's updates saying receivers SHOULD > verify checksums > 2) Joel's text with typo corrections > 3) Margaret's short text above with the additional of "LISP ITRs MAY > send a zero checksum" > 4) Margaret's text in the thread about closing issues #9, #10 and #12 How about Joel and Margaret get together and write the text and I will include it. Provided it is detailed and accurate enough. Joel's text was not specific enough to implement from. Dino From dino@cisco.com Tue Sep 1 08:40: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 9A31E28C2C9 for ; Tue, 1 Sep 2009 08:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 BlJP2IoVLbFd for ; Tue, 1 Sep 2009 08:40:48 -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 2644728C78F for ; Tue, 1 Sep 2009 08:40:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGvdnEqrR7PE/2dsb2JhbADEaohBAY9/BYQb X-IronPort-AV: E=Sophos;i="4.44,312,1249257600"; d="scan'208";a="379771305" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2009 15:41:01 +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 n81Ff18W011385; Tue, 1 Sep 2009 08:41:01 -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 n81Ff1lD005050; Tue, 1 Sep 2009 15:41: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, 1 Sep 2009 08:41:00 -0700 Received: from [192.168.1.4] ([10.21.65.120]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 08:41:00 -0700 Message-Id: From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <412E7B1A-AEAD-4ACD-8588-D6EFE6DDEAFF@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, 1 Sep 2009 08:41:00 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <412E7B1A-AEAD-4ACD-8588-D6EFE6DDEAFF@sandstorm.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 01 Sep 2009 15:41:00.0759 (UTC) FILETIME=[9B449E70:01CA2B1A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=285; t=1251819661; x=1252683661; 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]=20Suggested=20UDP=20checksum=20t ext |Sender:=20; bh=FQ5E3v+RyEDK26UriQckbJ41vjWS6miryFQlCSvtuU8=; b=tsAs+2Ft8NyxaLDHNUe+EiIYRev3UmVtFyJl20aBexuI3UPXTEh8TneZtK eTBH+OxGrQU2GA9jPjmpRXv2nhrYbnLuy5f+YZYbSqA7+JiKJkkoIaYl5XS8 aAHlon0yxS; 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] 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: Tue, 01 Sep 2009 15:40:49 -0000 > The reference to the Eubanks-Chimento draft (which is in the note > Joel mentions above) should be changed to a normative reference, as > it contains normative text necessary to implement this protocol > (similar to the UDP RFC 768 reference). Consider it done. Dino From hartmans@mit.edu Tue Sep 1 08:52: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 9560A28C2C9 for ; Tue, 1 Sep 2009 08:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 sGtUXer41ud6 for ; Tue, 1 Sep 2009 08:52: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 D8E9F3A6AD6 for ; Tue, 1 Sep 2009 08:52:26 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8EBB9646C1; Tue, 1 Sep 2009 11:52:36 -0400 (EDT) To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <9FD28265-5194-4630-AB14-AF901BFBBCBE@cisco.com> From: Sam Hartman Date: Tue, 01 Sep 2009 11:52:36 -0400 In-Reply-To: <9FD28265-5194-4630-AB14-AF901BFBBCBE@cisco.com> (Dino Farinacci's message of "Mon\, 31 Aug 2009 11\:35\: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] 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: Tue, 01 Sep 2009 15:52:27 -0000 >>>>> "Dino" == Dino Farinacci writes: >> Dino, the following entries reference comments I can't seem to >> find on the list. Can you point me to the list discussion >> involved? Dino> There isn't any because the commenters choose to not use the Dino> list. OK, it definitely seems reasonable to me for people to suggest changes to fix obvious bugs with basically one solution to you privately and for you to go forward like you've done here. Some of these additional changes depend on changes in your first message I'm still reviewing. However, unless we have some concerns about dependent changes, all of these look fine. Dino> The diff file should be able to explain why the Dino> changes were made. Not really; it does a much better job of explaining what changes were made rather than why. The level of detail you provided in your second message is about right for changes based on private comments. Thanks for the great work, --Sam From jnc@mercury.lcs.mit.edu Tue Sep 1 08:52: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 0CE7228C791 for ; Tue, 1 Sep 2009 08:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 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 8PfcZUkH-Fup for ; Tue, 1 Sep 2009 08:52:52 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 437EA28C79F for ; Tue, 1 Sep 2009 08:52:52 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 053A16BE574; Tue, 1 Sep 2009 11:53:04 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090901155305.053A16BE574@mercury.lcs.mit.edu> Date: Tue, 1 Sep 2009 11:53:04 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu 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: Tue, 01 Sep 2009 15:52:53 -0000 > From: "Joel M. Halpern" > how can we know that it should never be set with N and L, but not know > what it means? Look at it as a bit which says 'the meaning of some header fields can be time-shared to another use'. Clearly, in that case, it makes sense to say 'bits which indicate that those fields are being used to contain _other_ values cannot be set'. I forget which bits are which (and I'm too lazy to look at the spec :-), so I don't recall if it prohibits other use of only the 32-bit field, or of the 32-bit _and_ the 24-bit field. To the extent that it's a true general-purpose 'research' bit, it makes sense to allow it to use both of those fields (and therefore disallow setting of _any/all_ bits which indicate use of those fields). > It seems both simpler and more versatile to simpler declare the R bit > to be reserved. And to remove all the comments about N or L not being > set with R. The problem with that is that if we want to eventually (and interoperably) morph the R bit into an actual functional bit (e.g. for checking for outdated mappings), to do that in an _interoperable_ way we need a tiny bit of specification about how 'vanilla' ETRs will treat it, so we can design an interoperable deployment strategy. Noel From hartmans@mit.edu Tue Sep 1 08:58: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 6D0A728C7EE for ; Tue, 1 Sep 2009 08:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 feHxNNvwamaJ for ; Tue, 1 Sep 2009 08:58: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 B9A9B3A68B2 for ; Tue, 1 Sep 2009 08:58:27 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4B949646C1; Tue, 1 Sep 2009 11:58:38 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Tue, 01 Sep 2009 11:58:38 -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] Please review section 9: traceroute behavior X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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 15:58:28 -0000 I skipped over section 9 on traceroute behavior when I first reviewed the LISP draft. I thought it simply described how LISP interacted with traceroute, rather than providing normative behavior changes. I have a few concerns: 1) It's not obvious to me how you tell a traceroute packet from a non-traceroute packet. We should provide normative guidance for this. 2) As far as I can tell, MPLS treats its tunnels as a single hop and provides another distinct facility for tracing through the MPLS hops. Why is it desirable to expose the LISP tunnel? 3) Is the TTL text in 9.3 safe? Does the fact that we are cross-AF protect us from loops? From dino@cisco.com Tue Sep 1 09:05: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 413D528C832 for ; Tue, 1 Sep 2009 09:05:17 -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 xGu4vBIaB1Wt for ; Tue, 1 Sep 2009 09:05:16 -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 4B31728C819 for ; Tue, 1 Sep 2009 09:05:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEfjnEqrR7O6/2dsb2JhbADEdIhBAZAFBYQbimE X-IronPort-AV: E=Sophos;i="4.44,313,1249257600"; d="scan'208";a="379791624" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2009 16:05:30 +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 n81G5Ujl021481; Tue, 1 Sep 2009 09:05:30 -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 n81G5UGr012303; Tue, 1 Sep 2009 16:05: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); Tue, 1 Sep 2009 09:05:29 -0700 Received: from [192.168.1.4] ([10.21.65.120]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 09:05:29 -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, 1 Sep 2009 09:05:29 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 01 Sep 2009 16:05:29.0568 (UTC) FILETIME=[06BF1600:01CA2B1E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1619; t=1251821130; x=1252685130; 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]=20Please=20review=20section=209= 3A=20traceroute=20behavior |Sender:=20; bh=R8ZgAMsN2Pi5HfasMVU5Xe/mwVVaq2LtH2PbyKuXY+A=; b=ZEyIhrgxYn6eCsUmFQeELwTQ9Ji7dgtaAXfckMrrqHp+vQSBO6M1Y3HdUB GJxpEwRUtV3JhRfVEZiMJXQ9X3TuL9rKkLXhjoGDb/oBjMbjL7MD/uDCWFGW CKWpSRBmcA; 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] Please review section 9: traceroute behavior X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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 16:05:17 -0000 > I skipped over section 9 on traceroute behavior when I first reviewed > the LISP draft. I thought it simply described how LISP interacted > with traceroute, rather than providing normative behavior changes. > > I have a few concerns: > > 1) It's not obvious to me how you tell a traceroute packet from a > non-traceroute packet. We should provide normative guidance for this. We preferred to leave this out because there are so many forms from the various OSes. Is it okay to leave this out because it will cause a big time sink. Let's leave it to the implementations to decide what signatures relate to traceroute. > 2) As far as I can tell, MPLS treats its tunnels as a single hop and > provides another distinct facility for tracing through the MPLS > hops. Why is it desirable to expose the LISP tunnel? LISP doesn't really have traditional tunnels. They are dynamic encapsulating paths. It is really important to debug the path because users may not have physical access to the ITR to initiate a traceroute from there. This has proved useful when we debug on the LISP test network. We use it daily. > 3) Is the TTL text in 9.3 safe? Does the fact that we are cross-AF > protect us from loops? There can be no loops because we use an increasing TTL for traceroute. And that is what is used across segment 2. In the cross-AF case, we make the ITR-to-ETR path look like one-hop. That is all there is to it. Dino > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Tue Sep 1 09:08: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 4ABCD28C75D for ; Tue, 1 Sep 2009 09:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 Ha5ZdBM1vx39 for ; Tue, 1 Sep 2009 09:08: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 94D4A28C608 for ; Tue, 1 Sep 2009 09:07:52 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3383C646C1; Tue, 1 Sep 2009 12:08:01 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090901145749.1C7726BE574@mercury.lcs.mit.edu> From: Sam Hartman Date: Tue, 01 Sep 2009 12:08:01 -0400 In-Reply-To: <20090901145749.1C7726BE574@mercury.lcs.mit.edu> (Noel Chiappa's message of "Tue\, 1 Sep 2009 10\:57\:49 -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] 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: Tue, 01 Sep 2009 16:08:28 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Sam Hartman I think we need to at >> least say that for LISP data plane packets, an ITR MAY send a 0 >> checksum. Noel> We may want to upgrade that to a "SHOULD"; my reasoning for Noel> this is a cost-benefit analysis. Furthermore, depending on Noel> how we word the rest of the statement (i.e. covering Noel> reception processing), it may actually be very desirable to Noel> suppress generation of checksums. Noel> One has to start with the recognition that this non-end-end Noel> checksum buys us very little, simply because it's Noel> non-end-end. (In fact, if we have applications which have an Noel> actual use for damaged packets, it will have a _negative_ Noel> impact, as it will cause such packets to be discarded.) I think that if I thought about it enough I'd find the above compelling and end up at: * senders SHOULD NOT send a checksum * Receivers SHOULD check a checksum if present I'd be using your reasoning on the send side. My reasoning on the receive side is that changing the UDP handling seems problematic to me and unjustified especially if we are recommending that senders not send checksums. However, if we can all live with MAY/MAY, I think we'll be mostly done with this issue, so while I'm happy to continue circling if people really want to, we could just declare victory on MAY/MAY. The SHOULD NOT/SHOULD comment is my personal opinion. However I believe we're close to consensus on MAY/MAY as a chair. Also, as a chair, I'm not seeing any new information added to this discussion at this point. From hartmans@mit.edu Tue Sep 1 09: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 E33E428C850 for ; Tue, 1 Sep 2009 09:09:43 -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=[AWL=-0.034, 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 ysZfxg6fj8IU for ; Tue, 1 Sep 2009 09: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 09F8C28C276 for ; Tue, 1 Sep 2009 09:09:43 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 006D4646C1; Tue, 1 Sep 2009 12:09:52 -0400 (EDT) To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> From: Sam Hartman Date: Tue, 01 Sep 2009 12:09:52 -0400 In-Reply-To: <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> (Dino Farinacci's message of "Tue\, 1 Sep 2009 08\:40\:20 -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] 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: Tue, 01 Sep 2009 16:09:44 -0000 >>>>> "Dino" == Dino Farinacci writes: >> My personal preferences are >> >> 1) Joel's text with Margaret's updates saying receivers SHOULD >> verify checksums 2) Joel's text with typo corrections 3) >> Margaret's short text above with the additional of "LISP ITRs >> MAY send a zero checksum" 4) Margaret's text in the thread >> about closing issues #9, #10 and #12 Dino> How about Joel and Margaret get together and write the text Dino> and I will include it. Provided it is detailed and accurate Dino> enough. Joel's text was not specific enough to implement Dino> from. I'm happy with this provided that it's consistent with this discussion and no one objects to it. From jmh@joelhalpern.com Tue Sep 1 09:15: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 E62F228C866 for ; Tue, 1 Sep 2009 09:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 SfQYIunK6FqL for ; Tue, 1 Sep 2009 09:15:26 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 32AAE3A6B55 for ; Tue, 1 Sep 2009 09:15:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D9C9B4303A7; Tue, 1 Sep 2009 09:15:13 -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 672404303A2; Tue, 1 Sep 2009 09:15:13 -0700 (PDT) Message-ID: <4A9D4890.4060006@joelhalpern.com> Date: Tue, 01 Sep 2009 12:15:12 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Noel Chiappa References: <20090901155305.053A16BE574@mercury.lcs.mit.edu> In-Reply-To: <20090901155305.053A16BE574@mercury.lcs.mit.edu> 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: Tue, 01 Sep 2009 16:15:27 -0000 There is a classic interoperability issue with extension bits and their interaction with existing fields. But, given the path you are on, I don't see the problem. Suppose we reserve the R bit. And suppose that when it gets defined, we agree that it should never be set along with the N (24 bit nonce) or L (32 bit locator reachability) bits. Then no one who correctly uses the bits will set them that way. And anyone who understands the R bit will understand it is an error if those bits are set. Anyone who receives a correctly formed packet with a set R bit, who does not understand the R bit, will simply ignore that bit. They will also observe the unset N and L bits, and ignore whatever value is in the corresponding fields. The only problem would be if someone sent a packet with the R bit set, incorrectly set the N or L bits, and sent it to a receiver who did not understand the R bit. That receiver would not understand that this was an error. So far, declaring it reserved has almost the same effect as the definition you have in place, except in detecting a complex error case. The difference is if, when we go to use the bits, we decide that one (or both) of the N and L bits & fields should retain their existing meaning. Under the current textual definition, that is prohibited. If we instead simply declare that the bit is reserved, then when we get to working it out, we can decide what the rules for the N and L bits should bit (preserving their existing meanings.) It seems very strange to define things in such a way that we can not make choices that may well prove useful. (I can imagine R bit uses that want to keep one or the other of N and L. I can also imagine uses which don't.) The other alternative is to treat the R bit as a version flag, and declare that anyone receiving a message with the R bit set should just ignore the message. Dino said that was not the goal. And it seems we have other ways of achieving that goal, so I would prefer not to go there. Yours, Joel Noel Chiappa wrote: ... > > It seems both simpler and more versatile to simpler declare the R bit > > to be reserved. And to remove all the comments about N or L not being > > set with R. > > The problem with that is that if we want to eventually (and interoperably) > morph the R bit into an actual functional bit (e.g. for checking for outdated > mappings), to do that in an _interoperable_ way we need a tiny bit of > specification about how 'vanilla' ETRs will treat it, so we can design an > interoperable deployment strategy. > > Noel > From dino@cisco.com Tue Sep 1 09:19: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 709C03A6C55 for ; Tue, 1 Sep 2009 09:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 jACo1oCjczxC for ; Tue, 1 Sep 2009 09:19:42 -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 776C63A7029 for ; Tue, 1 Sep 2009 09:16:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKTlnEqrR7MV/2dsb2JhbADEWIhBAZAFBYJAgVs X-IronPort-AV: E=Sophos;i="4.44,313,1249257600"; d="scan'208";a="379800778" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2009 16:16:55 +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 n81GGtb0003375 for ; Tue, 1 Sep 2009 09:16:55 -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 n81GGtTT026070 for ; Tue, 1 Sep 2009 16:16:55 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, 1 Sep 2009 09:16:54 -0700 Received: from [192.168.1.4] ([10.21.65.120]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 09:16:54 -0700 Message-Id: From: Dino Farinacci 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, 1 Sep 2009 09:16:54 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 01 Sep 2009 16:16:54.0958 (UTC) FILETIME=[9F454CE0:01CA2B1F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=657; t=1251821815; x=1252685815; 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:=20To=20help=20converge=20on=20the=20UDP=20checksu m=20text=20proposed=20for=20-04 |Sender:=20; bh=dyTnxMq9UKMyFvPUa+bMe0UmBFFFpStpyIgjK6QiiAo=; b=hVxH5sLo904WIyWtIYPHy0Rhly0IyhRZyKO6VXHuuC83ayg46HaHnNZzvr vhGm+9SVHChmgtOr59pVywbuw/ukIFLlcJvwoPgjmlwVyNT/ZpNGPpW6A9I4 zIxoCwdZSj3/Z61X87Ts4XPAXsJwcroqLAKm0mfMVhK+p3ZiIdld8=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [lisp] To help converge on the UDP checksum text proposed for -04 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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 16:19:43 -0000 Let's start with this text. Please wordsmith it: UDP Checksum: this field MAY be transmitted as zero by an ITR and when received by an ETR, MUST accept the packet for decapsulation. 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 decapsulation, 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. Thanks, Dino From hartmans@mit.edu Tue Sep 1 09:44: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 470283A7038 for ; Tue, 1 Sep 2009 09:44:20 -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=[AWL=-0.034, 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 EwoV2fqT00V4 for ; Tue, 1 Sep 2009 09:44: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 548073A6F91 for ; Tue, 1 Sep 2009 09:44:00 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4BD7B646C1; Tue, 1 Sep 2009 12:44:08 -0400 (EDT) To: "Joel M. Halpern" References: <20090901155305.053A16BE574@mercury.lcs.mit.edu> <4A9D4890.4060006@joelhalpern.com> From: Sam Hartman Date: Tue, 01 Sep 2009 12:44:08 -0400 In-Reply-To: <4A9D4890.4060006@joelhalpern.com> (Joel M. Halpern's message of "Tue\, 01 Sep 2009 12\:15\:12 -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: Noel Chiappa , 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: Tue, 01 Sep 2009 16:44:20 -0000 I'd like to ask for the r-bit discussion to take a break until we here a response to my query on #16 from the map versioning authors. As far as I can tell this facility was introduced as part of a compromise for the map versioning discussion. I want to get an answer to my questions to those folks before we go forward more into the details of the r-bit. I think it is safe to say that we will not be done with the r-bit discussion in time for a September 4 deadline. From jnc@mercury.lcs.mit.edu Tue Sep 1 11:09: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 A93E93A6C4E for ; Tue, 1 Sep 2009 11:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 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 wFkQYBQ+LqFU for ; Tue, 1 Sep 2009 11:09:10 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id E10233A68AB for ; Tue, 1 Sep 2009 11:09:09 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 078696BE60E; Tue, 1 Sep 2009 14:09:22 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090901180923.078696BE60E@mercury.lcs.mit.edu> Date: Tue, 1 Sep 2009 14:09:22 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu 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: Tue, 01 Sep 2009 18:09:10 -0000 > From: "Joel M. Halpern" > So far, declaring it reserved has almost the same effect ... except in > detecting a complex error case. > The difference is if ... we decide that one (or both) of the N and L > bits & fields should retain their existing meaning. > Under the current textual definition, that is prohibited. If we instead > simply declare that the bit is reserved, then when we get to working it > out, we can decide what the rules for the N and L bits The difference is that in your alternative scenario, while you may (see below) have preserved a bit of flexibility for the future (i.e. being able to have instances in which both R and one of {N,L} are set), you have done so at the cost of making it harder to incrementally deploy in general service some new mechanism which uses the R-bit, since in your scenario non-upgraded boxes would (I assume) toss packets with that bit set (since it would be 'reserved'). In other words, without some sort of mechanism to agree on whether or not an ITR/ETR pair should use the new R mechanism, you would get packets black-holing. And even if we did go with the original scenario, I think we could still change the semantics (so that both, for example, R and N could be set), without being any worse off than in your alternative scenario. That's because we'd be in the exact same boat - old and new boxes could not interoperate without some mechanism to make sure they are both using the new semantics. (I.e. both would have to understand that the previously prohibited bit setting pattern(s) was now allowed, and what it meant, and the sender would have to know that the receiver would understand it.) So I guess I don't see any downside to specifying it now? Or am I misunderstanding something? Noel From rw@firstpr.com.au Tue Sep 1 11:12: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 D04113A7051 for ; Tue, 1 Sep 2009 11:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbGUL7Qkc5Ae for ; Tue, 1 Sep 2009 11:12:33 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 46D0E3A704C for ; Tue, 1 Sep 2009 11:12:32 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id CE9D1175C09; Wed, 2 Sep 2009 04:12:44 +1000 (EST) Message-ID: <4A9D641F.3090209@firstpr.com.au> Date: Wed, 02 Sep 2009 04:12:47 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: lisp@ietf.org References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 01 Sep 2009 18:12:34 -0000 Short version: Since WG participants presumably believe that LISP-ALT is either the only possible solution to the scalable routing problem, or that it is clearly superior to the alternatives (LISP-NERD, APT and Ivip), then AFAIK the WG must be planning to make LISP-ALT work in a future scenario in which the great majority of its hundreds of millions of EIDs are for individual mobile devices. If the scalable routing solution doesn't need to handle mobile devices, then there will never be more than a few million, perhaps 10 million, EIDs. LISP-NERD, APT or Ivip could scale to 10M EIDs without any fuss. Any of these would all be superior to LISP-ALT since none of them involve delaying initial packets or depending on a global-scale query server system - as ALT does. NERD is nice and simple - nice and fast. If we are not trying to do mass-market mobility, NERD would be a better solution than ALT. To complete this initial phase of work the WG needs to establish a coherent plan for how LISP would be deployed - how it would work in the next few years and in the decades to come. That means you need to plan how LISP will handle hundreds of millions or billions of mobile devices, each with its own EID. While I understand that development of LISP-mobile is out of scope for the WG as currently chartered, I want to make two points. Firstly, anyone who is interested in LISP-mobile will probably find it interesting to read my critique a month ago: Critique of Mobile LISP: draft-meyer-lisp-mn-00 - why not use the TTR approach instead? http://www.ietf.org/mail-archive/web/lisp/current/msg00772.html No-one has responded to this on list or privately. If Mobility is out of scope for the WG, the RRG would be a good place to discuss it. Secondly, as part of developing a well documented and hopefully widely shared set of principles about what LISP is, how it is to be deployed etc.: Discussing LISP deployment Sam Hartman 2009-08-22 http://www.ietf.org/mail-archive/web/lisp/current/msg01092.html I believe the WG must plan how LISP will do mobility. (I believe it can, but only with the TTR mobility approach and not at all with the approach of the recent LISP-mobile I-D.) The entire WG effort to develop LISP is based on using the ALT mapping distribution system, which is a successor to CONS. Both ALT and CONS go to a lot of trouble to avoid any one device having to store the entire mapping database. The primary or perhaps only reason for doing this is so that LISP can scale to very large numbers of EIDs. AFAIK, the *only* reason you are pursuing ALT, instead of the alternatives, is because of this goal of seemingly endless EID scalability. I think everyone currently working on LISP ALT, or any similarly endlessly scalable successor to ALT, needs to justify all this effort, and all the difficulties this goal entails for scalable routing and therefore all future Internet users, in terms of there actually being a need, albeit in the long-term, for such large numbers of EIDs that no other simpler alternative would be able to cope. The most obvious alternative is LISP-NERD: every ITR downloads the entire mapping database via HTTP or whatever from a bunch of servers. Then it is pretty easy for end-user networks to update the mapping in the central servers and let the changes propagate to all ITRs. NERD is simple and fast. There are no delayed or dropped packets as there are with ALT. There is no fancy mapping distribution network - no complex ALT network of routers with their long-paths, bottlenecks, etc. NERD sits at the "simple" extreme of the spectrum. ALT sits at the other end. In between are two systems - APT and Ivip - which involve ITRs getting mapping in a few milliseconds, via a local query server. This gives APT and Ivip the same major advantage as NERD compared to ALT: no significant delays in ITRs tunneling initial packets. Likewise, these three systems have the advantage over ALT that there is no real-time, moment-to-moment, dependency on a global query server system, with all its potential and likely delays and packet loss problems. Both APT and Ivip enable most or all ITRs to be caching ITRs - since they use local (such as in the same ISP) full database query servers. So APT and Ivip ITRs are simpler and cheaper than NERD ITRs. Therefore they can be more plentiful, closer to sending hosts - or in the case of Ivip, *in* sending hosts (not behind NAT). ALT incurs major costs of complexity, global dependencies for ITRs to work at all moment-to-moment - and most seriously it will delay initial packets of a significant number of new communication flows, by times such as fractions of a second to one or two seconds. That will make it very hard for us to get it widely adopted. In order to justify pursing ALT, I understand you all must be proceeding on the basis that none of the alternatives (LISP-NERD, APT or Ivip) could possibly do the job. ALT has a bunch of disadvantages over these three, and AFAIK only one potential advantage: the mapping database is entirely distributed, so it can (in principle) handle vast numbers of EIDs without scaling problems in any one device. To establish that ALT is the only realistic approach to scalable routing, AFAIK, you need to prove to yourselves that ALT's endless scalability is absolutely essential to the successful long-term resolution of the routing scalability problem. In order to do this, I think you would need to establish three things at least: 1 - That there will be a demand for a very high number of EIDs - say YYY million EIDs. 2 - That ALT can scale well, solving the routing scalability problem, handling this number YYY million EIDs, at some time in the future when this number will be needed. 3 - That no other alternative (currently LISP-NERD, APT or Ivip) could be developed to the point where it could handle YYY million EIDs, whenever in the future (2020, 2030 etc.) these will be required. Lets toss some numbers around. At what number of EIDs would LISP-NERD encounter serious scaling problems? Lets think IPv6 mapping with (I guess) about 100 bytes per EID. PCs today (and therefore today's servers and dedicated routers in a few years time) have 8, 12 or whatever GB of RAM. They have terabyte hard drives too. Even for ECC RAM, the cost is insignificant in the scheme of things. A LISP-NERD ITR will be a caching ITR with packet switching in hardware or software - co-located with a full database query server. The query server would be in the same box, including the same server/router, or in the same rack just one or two patch cables away. I will assume the full mapping database sits in RAM. Even if every EID consumed 256 bytes of RAM, a 12GB machine can handle 48 million EIDs. The task of sending all the world's mapping data to these LISP-NERD ITRs will not be a problem. By the time we have 48M EIDs, bandwidth will be even cheaper than it is today. The update traffic is not going to be high, since LISP mappings don't change all that often. The whole of LISP is built on the relative stability of mappings, with ITRs handling the moment-to-moment changes in reachability, making their own decisions about which of multiple ETRs to tunnel the packets to. (APT makes the same assumption. Ivip is totally different in this regard.) So for LISP-ALT to be chosen in preference to the simple, chunky, fast, LISP-NERD, you must be planning to handle more than 10s of millions of EIDs. You must be requiring the scalable routing solution to cope with hundreds of millions of EIDs - billions or even 10 billion. With equivalent hardware and communication costs, both APT and Ivip can scale to a much larger number of EIDs than LISP-NERD, because only the local query servers have to store the full mapping database and get all the updates. Dozens or hundreds of much simpler ITRs can work from a single local query server - so for the same or more likely much lower total cost you can make these local query servers more expensive, with massive RAM, multiple CPUs etc. Its hard to put a figure on it, but lets say that with 2025 technology and communication costs, APT or Ivip could scale nicely to handle 200M EIDs, 500M EIDs or the like. If you are still sure that ALT is the only way to solve the routing scaling problem, then you must be planning on handling 500M, 1B, 5B or more EIDs. This means you must be planning on most of those EIDs being for individual mobile devices, because there is never going to be demand for non-mobile EIDs in anything like these numbers. There's only a subset of non-mobile Internet customers who have any significant motivation to use a scalable routing solution - for the benefits of multihoming, and/or portability between ISPs and/or inbound traffic engineering if they are multihomed. If the population grows to 10B people, there are only going to be a finite number of businesses or other organisations big enough to want any of these benefits of scalable routing. Let's assume there is one such organisation for every 1000 people (10,000 people seems more realistic to me). As long as the scalable routing solution doesn't have to provide an EID for mobile devices, then the maximum number of end-user networks it needs to support will be 10M. Some will have two or more EIDs, but most will only have one. So if the scalable routing solution is not directly involved in mobility, then you simply don't need something as complex and problematic (initial packet delays ...) as ALT, because the alternatives LISP-NERD, APT and Ivip will scale just fine to 10M EIDs. Therefore, if you are convinced that LISP-ALT is the only viable approach to scalable routing, AFAIK, you must believe: 1 - The scalable routing solution must provide an EID for each mobile device. AND 2 - There will be hundreds of millions or billions of these mobile devices - enough that NERD, APT or Ivip couldn't possibly scale to this number of EIDs, even with the technology of 2020, 2030 etc. AND 3 - LISP-ALT will scale nicely when it does handle hundreds of millions or billions of EIDs - and the great majority of those EIDs are going to be for hand-held mobile devices. As I wrote in my critique, I believe you can't make LISP work with mobile devices as per the current I-D. I believe you could make LISP-ALT support mobility, including for billions of EIDs, using the TTR approach to mobility: http://www.firstpr.com.au/ip/ivip/#mobile I explained this over two years ago and Steve Russert and I wrote up this nice documentation of it a year ago. So as far as I can see, as long as you believe LISP-ALT is the only viable solution to the scalable routing problem, in order to establish how LISP will really work in the long-term, you need to plan now for how LISP-ALT will handle hundred of millions of EIDs for individual mobile devices. - Robin From darlewis@cisco.com Tue Sep 1 11: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 ACA1028C8E3 for ; Tue, 1 Sep 2009 11:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 90m3iflw0kzG for ; Tue, 1 Sep 2009 11:15:47 -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 B5CCB28C6E5 for ; Tue, 1 Sep 2009 11:15:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIMBnUqrR7MV/2dsb2JhbADEHYhBAZAgBYQb X-IronPort-AV: E=Sophos;i="4.44,313,1249257600"; d="scan'208";a="200784511" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 01 Sep 2009 18:16:01 +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 n81IG1kR026278; Tue, 1 Sep 2009 11:16:01 -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 n81IG1rH022039; Tue, 1 Sep 2009 18:16:01 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); Tue, 1 Sep 2009 11:16:01 -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, 1 Sep 2009 11:16:00 -0700 Message-ID: In-Reply-To: <4A9D641F.3090209@firstpr.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP Mobility Architecture Thread-Index: AcorL9YCqKGBbnMJRmafHrUYNkRGzwAAC4pA References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> <4A9D641F.3090209@firstpr.com.au> From: "Darrel Lewis (darlewis)" To: "Robin Whittle" , X-OriginalArrivalTime: 01 Sep 2009 18:16:01.0473 (UTC) FILETIME=[42ECF310:01CA2B30] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=371; t=1251828961; x=1252692961; 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]=20LISP=20Mobility=20Architecture |Sender:=20; bh=hsfOFHywGP/sOJ35p3KDKVz3KXXIv3SKLBL8wGnh2rw=; b=YrBh7iuphxymKslgEUBoXGtpd2R1dNYb9WkpQDA5tRM/g5n/4E5wlaxXh4 uVQOw/Imjsfrb5sTYgP4/feEDFKHkQTeqpCXi7ZIrEPfZQZBQ5CzTyQWCRnT zz4a4qGedmdHnrd/8zdc03yRCObySkIdMvYBbYSoOWqDjsdtLPY2M=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 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: Tue, 01 Sep 2009 18:15:48 -0000 >=20 > While I understand that development of LISP-mobile is out of scope > for the WG as currently chartered, I want to make two points. >=20 Robin, The WG received no such direct guidance from the Area Director (Jari). Only words to the effect that we should focus on the main spec's first, to build a solid foundation for any follow on work. -Darrel From jari.arkko@piuha.net Tue Sep 1 11:28: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 51B7128C93B for ; Tue, 1 Sep 2009 11:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[AWL=-0.122, 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 j1lim1-egv-L for ; Tue, 1 Sep 2009 11:28:33 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 2552728C949 for ; Tue, 1 Sep 2009 11:27:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 83169D62E2; Tue, 1 Sep 2009 21:27:49 +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 I4cxeyBzwHBg; Tue, 1 Sep 2009 21:27:49 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1EEE3D6247; Tue, 1 Sep 2009 21:27:49 +0300 (EEST) Message-ID: <4A9D67A4.5060007@piuha.net> Date: Tue, 01 Sep 2009 21:27:48 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Darrel Lewis (darlewis)" References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> <4A9D641F.3090209@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robin Whittle , 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: Tue, 01 Sep 2009 18:28:34 -0000 Then maybe I need to be clearer. Mobility and many other advanced features are out of scope. For now. When you complete the base specifications, we can talk about rechartering to add more features. Jari From darlewis@cisco.com Tue Sep 1 11:28: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 122DE28C93C for ; Tue, 1 Sep 2009 11:28:46 -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 UTQMfTYo7HM8 for ; Tue, 1 Sep 2009 11:28:45 -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 69B7528C952 for ; Tue, 1 Sep 2009 11:28:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABcEnUqrR7MV/2dsb2JhbADEEIhBAZAgBYQb X-IronPort-AV: E=Sophos;i="4.44,313,1249257600"; d="scan'208";a="379901914" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2009 18:28:51 +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 n81ISpFt022640; Tue, 1 Sep 2009 11:28:51 -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 n81ISpS0006645; Tue, 1 Sep 2009 18:28:51 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, 1 Sep 2009 11:28:51 -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, 1 Sep 2009 11:28:50 -0700 Message-ID: In-Reply-To: <4A9D67A4.5060007@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP Mobility Architecture Thread-Index: AcorMer26mgJlVIKQ4KV+CYE+uXmogAABeHA References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> <4A9D641F.3090209@firstpr.com.au> <4A9D67A4.5060007@piuha.net> From: "Darrel Lewis (darlewis)" To: "Jari Arkko" X-OriginalArrivalTime: 01 Sep 2009 18:28:51.0214 (UTC) FILETIME=[0DBA1AE0:01CA2B32] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=270; t=1251829731; x=1252693731; 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]=20LISP=20Mobility=20Architecture |Sender:=20; bh=FoMthz2VggM7lWuSqZCRkbh5FyXHe3icXyJz9qasYVw=; b=Sibz4KM8Ejh4rd8xVfIMJewLOQ48rj8ndeULScTqjBxpUemX8Pt5e5bN2X YMdv7CHZofqYqP33vRcoDExVxwWgZrhnAQTsvS0xJKT2xCB9ZKzmOrGpEQqQ 5N2IWyX4u/j+kg9nZpsc0Be5TwukpQ38fO2EwEhWxNLGfHYXBDRMc=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Robin Whittle , 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: Tue, 01 Sep 2009 18:28:46 -0000 >=20 > Then maybe I need to be clearer. Mobility and many other advanced=20 > features are out of scope. For now. When you complete the base=20 > specifications, we can talk about rechartering to add more features. >=20 Thanks for being clear Jari. -Darrel From dino@cisco.com Tue Sep 1 11:35: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 6AB6A28C961 for ; Tue, 1 Sep 2009 11:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, DC_PNG_UNO_LARGO=0.558, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGH8KL3WF7Cb for ; Tue, 1 Sep 2009 11:35:28 -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 F3EA828C9A6 for ; Tue, 1 Sep 2009 11:34:20 -0700 (PDT) X-Files: Picture 4.png : 110000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPcFnUqrR7O6/2dsb2JhbADDaYhBAZAiBYQbgVxv X-IronPort-AV: E=Sophos;i="4.44,313,1249257600"; d="png'150?scan'150,208,150";a="235982436" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 01 Sep 2009 18:34:29 +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 n81IYTg3016235; Tue, 1 Sep 2009 11:34:29 -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 n81IYT1p012227; Tue, 1 Sep 2009 18:34:29 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, 1 Sep 2009 11:34:29 -0700 Received: from [192.168.1.4] ([10.21.65.120]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 11:34:28 -0700 Message-Id: From: Dino Farinacci To: Robin Whittle In-Reply-To: <4A9D641F.3090209@firstpr.com.au> Content-Type: multipart/mixed; boundary=Apple-Mail-130-792445274 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 1 Sep 2009 11:34:28 -0700 References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> <4A9D641F.3090209@firstpr.com.au> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 01 Sep 2009 18:34:29.0061 (UTC) FILETIME=[D7197750:01CA2B32] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=164358; t=1251830069; x=1252694069; 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]=20LISP=20Mobility=20Architecture |Sender:=20; bh=JnkHc5gmUHMCiLfCg5WDtS7l6/AUlOiDJgQExvFWf4o=; b=U1NAX1IalGOcB8GS70wYR33HkmP9fXIhKsPvqIKEpbra8X5IZHH0iOHl46 1QzzwCNa8XM0IKjB5hY9EIbEX8FUdhEY8iBaURfp3CYApKpid0Zo9lYGD4MT zbzFW/Kt2K; 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] 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: Tue, 01 Sep 2009 18:35:30 -0000 --Apple-Mail-130-792445274 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Robin, I just want to make one technical response with a few points: (1) LISP-ALT does not carry mappings. (2) LISP-ALT carries EID-prefixes registered from sites to a specific aggregation boundary. (3) LISP-ALT also carries aggregated EID-prefixes into the core (the LISP-ALT core), upstream from the aggregation boundaries. (4) When a mobile-node changes locations and gets a new locator, nothing in LISP-ALT changes. The mobile-node keeps Map-Registering to its Map-Server which is the same ALT topological point regardless where the mobile-node moves to or how often it moves. Mobile-node roaming causes no route injection or withdrawal in the BGP that runs on the ALT. I have enclosed a picture of how the mapping database architecture is modular. So if you want to remove the center piece (labeled ALT), you can insert your favorite solution and the outer elements don't have to change (i.e. xTRs and CPE devices). Dino P.S. Note the diagram shows a scenario with non-LISP sites as well. --Apple-Mail-130-792445274 Content-Disposition: inline; filename="Picture 4.png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; x-mac-type=504E4766; name="Picture 4.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAoAAAAHKCAIAAAAchG3jAAAABGdBTUEAANkDQtZPoQAADzNpQ0NQ Q29sb3IgTENEAAB4nJWXCThUX//Az52VwVhCQhprhAhZS/Zs2feKmGHsxthFJCLKmqVIlFLJ0o4K ESqprCVF1pAkS3bz3qF+v9//fZ/3eZ//mWfu/dzv/S7nnu+559wvAOwEZwrFGwEA8PENpFoc1CLY 2TsQsD0ACzjgHxpIOhMDKJpmZsbgv7Zf3QCinzuk6b7uDQS9Hks3+dK2vIf9jcLBsv9ut9HwVDgg AJAUzJzkTdags8smW9E5JJASCLM7nYnuziSYI2CWolpZaMN8g+6HvMmVdHbZ5Bd0DiaS6bYfAMBw +JI8fAHATsKsTnINIMK36XFJpACiD8ypACC0fHz8YP9snbBcnEihwrZsqzCL0Mdls8uu/gCo7gGA MetvmSfc13IqALxLf8t2MgHAHQJA2T/0Zi02xgrifhvgJi+3IYKYtQBA99Fos2Jw39IBWEuj0Vau 0GhrVwFAfgKgzpsYRA3+PV4Q1ArA/7refObfDQkHpCdYEFDBJBSD2IuEkGtoEYwn9g2jExOauRv/ nK2e4xPnzFb5bSS+4u0TBEkhqkix2IAEq6Sq9EEZxT3b5bEKU4rtyndVz+6zVxc8MKqZr22hs6Z3 SV/J4JWRvXGnibVpvbmcxQXLFWt7m2o7vL2TQ8XhuaMKjlSn68f6XNiJeqQA10tu9eRRD5ynhJee t6NPsO85vwJKuX8t9V3AQODPYBCCDxUIkw1XPL7t+FREfWTWCf8o/Wih6LWTH2Men8qPjY7zOG0Z fyBB5oxgIncSy1n0Wdq5teT1FFoalI7MwJzHnF/JHMxqyi7JSb8QctEl1zxP/ZJ0vsBltgJUwWLh 5JUvV7uKmq9VX68ovnTj3M2IW94ltrc1SsXLWMvWK8Ad7F2me/j7LA+YHzI9wj6iVc5VjVf3PX73 5NnTiprLtYl1Ic/c6q0bdJ7vbRRt4mlmeYF4sfhy/FVdS8Jr41Z869s3qW9N3+HfvWyLbT/QvtRR 3unWtb2rozvpvdb7xQ+lPS4feT6+7T39af+nuc8Vfa79zP0Xvoh8KR1QGWgatBocGgoaxg7njEiN 1I1ajo5+DRtjHrs8Ljf+fMJyYuhb4CR6MuO74PfyKbWpxh8WP75Me07P/gyfQcycneWeLZgTnyub l5t/8Evm15UFlgW3hZpFpkXdxROLlYs/l0hLfcudq5HrSTQafQaDCAgBpSI0kJzIdbQw5gi2ilEN 186chCeyGXKocmpxO/BE8hbyNwtMCQoIG4mSdsZKnJcMkBbZ/ULWX45Xvn6vhxJe+ZaqltrH/T7q qxoJWizaSbpovYiDXw1sDB8Ycx7yNWkw4zb3tLhruWC93ybYttxuyGHLYZ0jPkdzHRucRp0xLiJE bZKTa6hbMvma+xOPt54DXrM+DL4CfnIUQ/8j1OCA1MDCoIRg15B9oVtD58M6wu8cT4ugRNqcUI0S iEZFT57sjqk7VRKbFRdz2jfeIUH/jFKiaBJHEu3st3NdybUpV1Pj07zTLTKUzu/IxGXOZvVlv8p5 eKHoYlpuVJ73Jft83ctyBTsKcYVz8GxoLbp/Lfd6bLH7DYebbreOlyTcvlhaVFZa/rSi8c7ru2/u td3vfvDhYc+jnsreqg/VPY/7ngw8Ha35UTv/DNSzNPA939Uo07S9aan57Yuil+GvzFskXoPX3a23 35x66/BOpg3Z9r69pCOq07JLtGuuu/b9uQ8OPWI90x8re2M+6X/Gfn7YR+pn76/74jewY6B1MHxI Yuj98KmR3SPdo5FfRb6+HPMdZx+vmDCf+PkteXLXZNN35+8rU2k/xH/UT9tNT/6MmuGYuTGrPts+ 5zL3c/7kL7Zf+QsiC3mLPIsFS3uWOpfTVsirxLXY9VwagWZHS6E1b+SfCxiCCxAE+UPziGTkPhRA 9aI7ML0MgFEKF8LUzCKKT2RdZvfnGOG052rZqsxTxIvjI/PXCDDtMCPkCPYL7xTxFL0pNiTOJ2G6 64RkiVS79C8Zblm5PUZyNvJkBcreEMUIpQjlcJUwVaqa+z7X/SR1twNuGk6aDloW2sY6mrryeoIH 2fSB/pRBj2GDUZlxzqFoEzdTUzNlcxELvMWS5bDVO+samyLbcDtDey77QYc7h6OPmB7lPzrhWO10 5piNs6jznEs9MY10zFXKdcmtiZzm7uQh5bHo2eB1ztvGh8+ny/e0n6xfDyXGX8y/lRoUwBtQG+ga xBhUHmwdvBxSGGoQOhOWG64fPn/8aoRlJCay+oRPlEhUb3TmScsY1pjXpxJjdeJAXM3p4/FK8bMJ 5Wd8Enclfk0qOutyTuBcb3JuikMqX2pvWm66Y4ZgxvD5G5leWQrZiOy2nMsX/C5q5G7JHcl7dCkp 3+WySgF7wURh45XCqzFFpGu613cWMxZ/v9Fxs/pWITzLAksdywzKlSqE77DeBXdn7g3d73nQ+rDh 0aPK+1Ul1dceFzzJfZpTk12bUXfuWWJ9fMPp59GNYU1BzZQXbi/dXoW3ZLwubn34pvrts3fP2ura X3Z0dX7umn3P+8Gw59THF5/kP5f1Gw6gB0eHl7+6TLB+l5n+Op++co2e/829j94wigBk6gFg8xYA i5sApJnAWx0bPEGOAWDGAoCVCkB8EgeIG/MACpD/a//gAXLgEHADJ0AWKANN4DOYg5ghIUgVMoPc oSgoGyqDmqB+aBHBhhBHaCGOIIIRqYgSRBNiEEFD8iGVkdbIQGQG8h6yAzmL4kIpoRxQkairqJeo GTQ/+iA6AH0Z/Rq9hBHH2GLiMZWYcSw/1gx7GvsUO8cgxeDGcIWhj5Gf8TBjHmM/ThjngavALTFp M6UzDTDLMscxf2SRZTnDMozXxBfg11mPsTaxSbOdZwfsFPYBDiuO1i06W2o593FWcalx1XIf5G7f enTrN57IbezbbvJq8/bxRfIL8jdu9xbgEHiyg0zgIjQKBgqJCg0KN4ncFS0US9wZJk6WsN2lIykr RZBmkv61e0Dmley9PXlyp+R9FKz3qikKKeGU5pT7VFpUa9Sa9/XunzoAaWzTlNBS0T6k46RL1Ys7 mKNfZtBo+Nlo5dA2k72mjmZx5hUWH63YrfVt4myf243a0w4TjmgedXfMdKo7Nu0iRiSRilxHyJLu wR6NXtzefj6NfryUQP+WALHA6KD3IbKhZ8KGjlMjhU8MRl+L8Y1VO80VP3+mK6npXGVKedr1jMLM 4uzSC3dyKy81XG4o7C9KLz58i+d2R3n0XYX7/Y8uVFs95aztr3/SmPriRAvlzfG2oM60948/fu5D DhgMF4+d/p41H7SksPx+5ftqz9r19cKN9YMb7AFGG/nPBhXgBfgCFiF2SALShOzhNSURugo9hbqh aQQOIYJQR9gjAuHs30a8RIwiUUghpAbSCRmFzEfWIQdRKNROlCHKD5WFqkP9QO9Am6Nj0Y/Q3zAE jA3mLOY5ZhWriPXHlmEnGXYxeDKUMEwx7mEMZnyKQ+NMcbm4MSZFpgSmXubdzKeZ+1lUWLJY5vHW +EpWXtaTrN/YbNjq2RXYizn4OTK3sG1J4mTmTOLCc2VyC3CXbFXZ+oLnMM/0tjO8wrw1fEf41vkL t+tuHxdI3qG0o4+QJKgg2C+UJOwockBUXAwvNrezT7xZ4v6uPMkEqWBp4m5zGQ1ZmT1CcpzyjAqQ wsLeH4oTSmPK4ypTqnP70Pt51CUPaGjYaXppndS+qHNH97XeiD5ksMPwgJGzccKh2ybdZihzeYtj ltlW7TZMtofsQu1jHTIOlxypOfrJcfUYt7OqyzFiMump6wSZ393CI9Gz3hvyUfcN8btHmaaKB5Dh fbEnhCPUKCwuvD/CJXIhKuXkzpjaWLu4pfjcM2qJA2eTk/elfE8ryLDN3JY1klN28USedb5cAb5w vUj8utON9FuNpVC51p1T9949lKlMf4x4GlaHrT/fqNjc9yq91emdQPtq1+iH572lfVUDTcP9Yynf eqbypr/OdM4FzC8u3N/IvygwBaGgADTDX5EckCJ0BIqGrkEt0E8ED+IAgoxIQVQhhpFsSHWkN/IS 8g0KAb/hvqgbqCG0EJqIvoYew0hjAjCPsWisBbYQO8Ogy5DLMMt4iLEEx4TzxXUy7WO6zczHnMKC YYlmWcdHsyJYE9m2sl1hl2av4jjI8WmLPycT5zUuXa4x7rStaltHebK3GfFCvNV8wfxK/IvbHwtE 7tAhMBG6BS8LeQmbiOwXVRDbtVNIfLsE/67tkgJSO6V371aVMZC130ORS5C/rtCwd1gJp6ygQlTN VVvY76H+RYOkOaJN1YX0svSlDJqMnIyXTVLMxM2fWBpZfbHxs123jzvMcaTAUdmpxZnoQiMVummQ hzwSveS9B32TKCr+IwE5QbrB86E3wo9GoCKLogyjp2LSYxXiPsWfOiOS2HTWK5klpTRNP33g/Iks gezHF6wv/sxLzpe8XF/ofGWlKPO6YnH7TXIJ+vaFMvnyljsedxfvZz6UevS86mj13JOkGvHal8/I DdjnRU2mzUsv81uMWxFvLr3ja8vv2NVZ203+wNBT1ev1Gd9X9sV2YHLIZ3h41PJr1TjnhNm3U5Ol 35um2n50Tjf9fDCTOus9JzX3bT7/l/6vmYWERf7F8iWZpVvLIsv5K4gVt5VXq7tX41fb1vjWXNfK 15bXD61X0cRo6fT8b9ZLGw2n7eftRyUYa+v8j+Lu/9t8vIP+xOCA/8y+Liamv3mMEmhmtbEKAbAc EGypC5/hPQtic/PQM/jNBJKzjhHM/DDLhrtrm9B9wGzsRtWz2LSF7DydDc1gxsPs6+prbbnpH4qg eG/UuHROpgRqWWzseAAqcA3Q/aNTGe5uZfvb9hU1yMJ646sari29/IwsfsdaJbnq/O4bgsHX28R4 My6CxyPQYKOWhXk30APOcDVGBq5AGhgDbaDz+0iA5QSY/OC7riAA1hve0PujZbNx7fFvVtLwqkz3 F7xh4wVGYfZx8oihwr7+r3ci7DkIeMN6QYAqWyI7Lrv6lw49qvdG5D8So/+Q/PHzt64HIMHnf/rf kNOj+9x1C87xC1O1cUeJoeRQe1FaqP0odZQKIKC4UbxAGqWAUkZpog6g1OB7Km8mH03+FWdzfFz+ ek6jP32Gj77/MWbEf/QGbNbvG985cA7yYunUkLkY/e9zLdA1dKNG1vajhFE9yO6BBE0KxdtVimDg S9wtRZCTlVUB/wJX0XpAPL/WlAAAAAlwSFlzAAALEwAACxMBAJqcGAAAACR0RVh0U29mdHdhcmUA UXVpY2tUaW1lIDcuNi4yIChNYWMgT1MgWCkAYDI1PgAAAAd0SU1FB9kJARIhCj+habAAACAASURB VHic7L0HmBzXde9ZOXWOkzNmkAMBEmCmKAZJtkQqWIGKz5KlZ0uybD2n9ZPtz95nr3f37bd+liyt MxUtSqZFS1RgFHNAIECASDOYnHs6V1eOe6pqpjkYgBRIDdAzwP2x0ayuW11TVV11//fce+45uOu6 GAKBQCAQiEsL0egDQCAQCATiSgQJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJ MAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKB QCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQ DQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJ MAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKB QCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQAJMAKBQCAQDQB3XbfRx4BA INYfy6uOdV2N4Di+YgGBuDQgAUYgEG8YqDccxwneg4Vza5KZYkm3TIakFMMgcDzEcTVVhfUcTduO A1pHUaSs6RRBsgwtaxpsw9I07MswTYokOYZWdAPW6KYJ2wssC++wzFAUTZKyroc5VjW8ItizZVu6 aUERSRCGZfU1N12gmuI+hE+wgGQYccmgGn0ACARinRHoruVjmia827YdyHB9m5Ik/+ehw5ppBoqI YzgIqmYYUATiCpvCGhA7w7TgnSYpkGrcL4J9WI5N4gRNkbplgdaatu06LkNT8BdgGTQ22CdLUab3 d13WU3Tbsh0SCnAClm/Zsmlbe9svPJFAcSlQdJqmfOorL97VQyDqIAsYgUC8irsEttSxfG4VAVoL imsYhq7rqqpKinJ4fHK8WAIJTIV4STcYiqwoal6S2mOxlmikputgV8Z5vgwWsIvxzKIFDMZxVdNA UAWaFjXQZtcrcjEVLGCKBENZ1gzWk20wc+0IBxawC4rOUxRIr6TrMZaRQf5tJ8pxhm1plsVRnkif WsiDkHcm4rq/BtZbYCUzzO721rjA18+irr4Mw/A+LMvCMunJOLKDEZcCJMAIBGKRepey7VPvXl6+ DRidugH2pwXqqyhKoVJ9YXR8uiqCXq2QLI4kb2prIvw+XpA7DMxKgsQ8G5XAll7eMk5gJKz3BPGN Ha3jYI4NzQF/wcFsf9l1hvLF8YpYP6OgTeHA8VDkpng0zXPBccLfA7MXVFcQhEgkEvbhONB9sLrJ 5X8oEGP8HN7g1UUgVoIEGIFAeATqC7prmmZg3Qbdy7KmW6BzGA6CDHbngZGxM/M5kEsSx+1FW9kN OU4ad3nMJQKjkqJJ0DGOY4QQI/A0L8DHS3wuIJBwJoaiGIqsyvKsqhfglCwL847XATl1MZwj8A6e a4qE4tFoLBoLhUOZRAKsYDiBFRILy+QSUFofML6UJ4W4/EACjEAgPKAqCDqWFR9ZluFdVJRD07OG ZYMYaaZVlBXYLMOxPNiuriOrmqbrUIlECJxlaIbjWZ5nQyHOe4VJag25mECDIl+piKoGNrIpSd4Z aqqGkw5Nhwicp2kwhXGK3N3Z0ZlKgsouV18Q2kB32SUCKxn1VCN+SZAAIxBXBBcysgv2rqqq43Pz LwyeASXGHbusqPOKGsIxBsM8exfH0gQe9UxcCgczl2UpjiMDexdkiWXXhVHoGfiqCvawZtvTxZKs Kq5lw3ErOCGwbFcsYkFbxMXAFm4NCSTh2b5wfjzPh0Khek91fbS40WeDWMesoSYqAoG4SCwf3H2t iUOwEoSpJkk/PvzybKXq+mO6sA1hWbxYIjA8Eg6FE8lYIhGOJyiGCabv4OvQCqQZsNaZkH92mXQa ThxW2pZ5ZnZuqlQ5mS+6fhFF4FUSB/sY2huguKC+8Xgc2ij1Fgysf63RYmzZmHEjThGxPkAWMAJx mVOfNWT6GL4LVd3JKhDaqqo+8sqJ0Vze85Zy3SSJpwy9Vq1ICpiFRHtff2tfnxAON/pULjpwQUAy lVptZGJiWlYt34cLNDbtmM0cm0gmM5lMOpmKxaKCIAQd0SskNuivDozjoBTJMOK1QAKMQFzmBOrr 9bhqWjC4CwuGaS7UpOFCybAtnqarqjZbFdM8y+OErKlx13Z0A2eYZEtLtq2dONvOuxKA1snY3Hyx XNZkSQIL2bYF2/IGgXmuI5nc1tYaDgkMwwQRPIKvBEIbzGsKCKYXo6FixGuBBBiBuMypu1aJolit Vkfm5kuSbFvmZE0uqhqDYYG6sgTeyTMcw+A0Q7CsEItzoRBSDk1VR2dmFyRJVxSv/5miWYbuT8Qj PAfi2hoS6pcocAD3NNofLQZgAU0sRrwOaAwYgbjMCdybwQIG23dmIf/8+JRimmC1ma7LqUrI1EGA aZZNZLPRRIIRPB/mK9DkfS04nh/o6W6WZVNVFVnK5ws50zpZKBHe3Ga8j2fjxKsCDHILuhuNRk3T hDX1vuiGngFi7YIEGIFY39RjZbyWezPYbYqqnpycfub0YFlWVMviFRkr5i3D0E2DT6W7tmxJt7RS vq2GIUPtHCiSTEajWDTqOpm2tvZaTZodHymWylIoOmjZJOayuiYoEoXjHMdFIpFkMgktnvoYcOCu tcICrg8Mo0HiKxkkwAjEOsZZwo+3uMjyDWqa9uiRY/lqdXQhDx9p12XB/F2YMy2rua19w44d8WQK ie4FgoONy7IpeKVTslg9PjxSVHWTwA2WF6FQVZhKNaWq8BMEM5dIL7S1a3qRNakVdnDQKR2sr/dR Ixm+0kBjwAjEeqUeuAoIAlcBsKZuCsuG8eTpoRPTswJNsQTRRJOMaai6Hk5nMq1tnCA0+gzWPYau Dw8N5VRNtiwb8y46n5tNCUJTNtvc3JxKpYJJwyuGgQPXLX/uNBu4awVKjDqrrzSQACMQ65VAfVVV rQeu0jQN1ngGseOUNH24WJosVxM03REWaALnWJYKR4RYDFlaq4skSzOzcwvlStlxMU0TVDnDMel4 PJFIgAAHfljLsw7DR1gZzC0GBEEIomshX60rDSTACMS6BJ5cy7JAcSVJqlar5XIZ3kGGVU2bABV2 3aphKKYVxdwOlk4kk1wiQQuhNRUe8jKjJoqzVXFkZhYaRoztJWJqwmywf+vxOuqDvn6cbG+0OO6L dCwWAxlGobWuQNDTiECsV+oaLIpisVhcKBTmRals21WCcl2HtGwwxWIcm97QB1bvJU6HcAUSiUY3 hMOpaGQErOFSWccJaABxxRJnmpTrLO9/DpylQXodxwnCbIEFHPRCB2kkGnsiiEsGEmAEYr0SjAEH 84vA/J2piNMu7hAUKDM2OoyZRtOWrf07dzEs2+gjvVIAAzYdi8ELWkUvnhoUcdykGbFUxObnsSXn OFBZUNxoNAo/HyhxOByGX7A+co+4okACjECsVzwPW8s6PDH5/JlR2nVUjLAtw1iYpyw7FYtt2XN1 qrkZmVMNAST26k0Dc8XibKFUSSRtlsVJylEUafAk7thQ6nVTM0wsFvNzJFpIgK9MkAAjEGuUFfN6 V1TQQf/z8HzupfEp+MCAKSzV8Go1wzAdmzd0b9yIhnsbS5jn+9vbW1LpsVzO1PX5fN5KpcjmVnls OLB9vYCghhE4rgedGcCKnSzP7rB8AXF5gB5RBGLNEaQqcpZxbvKivCienpo+NDwq6/rmSNgs5lnM SW7a2NLVLUQijTryNYJpKC7ux2FutGKFeW5bV6dpGs3RyLHpmXBHh2tbjlg1LTuYPAYyrPoQBBGE 71iusn7GqUWCZTRd+HICCTACsbYItBbq4nr+onqQjboGg9H0nedeXKiKYEBtTMSitmm3tXZmmlhB uNyjSJoTp37w0OlXOL69KZQCjfWmXGEOTrICGxNoIdW8ISI+/41DP8Rw0KpQKnbVNVvv3NTa3MAj Br1kGLa1pYUPh18cPIP19HmxOSbHQH1Bd2VZrtVq0FaAXznwl15u7wbBOoKkDii1w+UHmoaEQKwt AvUNzKPANgr6KoNhwuCB/eErJxdqUpzj2sJChuf4dIa6QjytnPLjj/zVExMvm6+1AfP2a8nnXlRr y9cl2r7w2bffFV0D5sZCpTqeyxXFGpi+5PBQcybd1NSUzWbj8TjP8yv0NcjuALorCALHcbBB4Cx9 bg5ExDplDdySCARiGUHnMwiwoijValUURUmSQIaDMFe6484paq4mRSlyWzIaisXpSBS/PCePuo5t uThBEos2PVwYyybbmne3K4pqm46t1aQCLAihtihDO37TBI+28DUSU3GGbUpFBEuXq1K+PPO1f/ph /oNv+0h7mMPq+wq2J4hLKWXZeCwdjQxOz4zO56yO7qpYIipV+LnhJwZxrecPDjYOMhuC+kZ9sKUQ WkEoj0t41IiLBRJgBGLNUU8gWKlUCoVCuVz2NFjXyzhZwAkwhEnbaQvxfDLFhC/b4V5DXzhy7Gci 2bJlw3WtID+OOT974PDYMTZz83951/sp3NGqIw8//78OzI5u2/2luzZ0mLbluBjFkEd++hMMZ1pb P/Mbt1+vlceODv34mWM/WSg//vzJLe++5jpMmR2aPlrWJMs2XZcg6Q17t1/NX0IRBgXta23RTXMG w9SQYOi6ms/zxWIQOxpb5mkFAgxWL0ivpmlBRod60MpLd7iIiwkSYARibRFYwJZlgdUbRNjI5/Ne lCucUBJpR1ewcqm5vb2tu4u7fNUX8xyp8sde/vYwlhjMVe+59V3K5EMPHn1gojTbsanj2t5NHE3z QkwIxWHLoqjSDL8UZ8Sod+DiBBVJ9d+w667jx35SsTVDL1lG/on9//Dy+EuiqS39nZ19m69uv7RB SkBFB9rbMvFYUayNz8+XMaKazxPQHDhbWYN4HaC+wdThetBKzL9JUC/0ZQASYARizRFMMQqM4Fqt tqBptVDEpmjHsbWpiZ62tm07drA83+jDvLjwQu8t131U2v/tqanv/uuPHrXVPJit6ewtb920V6B9 S9FLJOQppyQrK7/sOqo0OTx6uJw/eWT66TlvFcsScUweOT5zTDTNTPKdb9t33dTJHxwutNCNsCdB SOEVD4UkTSs4jgE/riKrYyPLZRUEWNd1WAPSG4/HAz+AFdmuEOsaJMAIxNqiPgcp0OCabkihqE16 0SW16an2pqZdN97Ectwv3tE6hyCFgS3vF5XqT448WCjXQI9amj/0a7d9vD3MLG5AR1J8+jUyOpm5 3L/e+2j9I9WUuf3GXXsFfJzDodKz8+VnnjyaufvGP3lHItJAQzLEcRvb21Rdl0mKjMWlYkGZma6X gtUL6svzfJBjY3meq8YdMmI1QWMJCMRaJNBg1bKKDGsRpD47XXz2qRae23PzLVeC+nq4jlybnxdz gcMzTvKp5j1p7jw2g6qJ51qFnnVMLko1Q2/71VveneYpTOj/zJ1/tCnVmxSo3Py3vvr9j3/v0LN6 Q03KVCTylh3b9w5soEgy0tcPMmyaXsMroJ5iMrB9kfl7mYEEGIFYo5iOM6tbkotjYtWYmtxy1e59 b72Nv2KS+JbnDv70+b97ZuQAxnf1JDtduzo2/NUXx05o9koREkvT+spvk8nEtTdvf89App8iSMM8 9u8P/7/7R49KcrHoJN9+619+8PrP7WjeQmG1Iy999WT1Nec0XRpIgmhOJgfaWrlwODawiQyFAq1d rrvuMhp7tIhVBHVBIxBrDqhuD46OzeYLs4pCGDpZKe26/oaBnTtphmn0oV0qnPLTz331UGmWFTbu 2/HxvU3c48/8zyOl8ecP35eO/PaW5ubAdHBc7Fw58vQZp8Kx2996zbVS700nxp945vB/lGv7f37Q dTq6T86fcph4JhqRbA0P9rE2FK2vpdkwrRHLTmzcpFcq1bHR5YqLdPeyBAkwAnFJWV6lnrduBaPn xcGhJ06etmyHdZ24a3dde222o/PKmnyCs33Znne87yv7R3J7e/pu3rqZJg3jkT/etmvXQHunaxoU RW7s7Bs6zgsU9je/+amy7H2pK5uVtRpF4iGW+R/3vHeykI9nNv3udXf0tWz66c//qn/LxmtbO54Z +bEtE59621//2dd/G77y9797b15eE4kacRzva202bXscw0LNrWw8UTn2MrY0GBEYxNYSK7yg6yGj Vywg1jgoEhYCcelYXpkGvYvndiqemZm977kXq4pyQ1uLJYlCJhtOpa/A+lSYm7vtG/cO/d1XowLf vHu3cvrUiYmRa757P7Zz5+Pdvbd1d2K//uv1UnN4+ODQmeu//z2vtDN7W+8W7D3vGfr2d84qffgh rLv70db4HQO7oPTQP/xDLBTqv/HGB+/7fqPP9VXgZlB148DgkKiq8tSkOTGaTqc7fNrb27PZbCwW 4ziOJMkVDbIgRgfpUw8ZfQXeNusLJMAIxCVieYTnuovN8okl8CguiOIjr5zMVcUtmVSHwJkcz0Zj l74aDZoFDa/B0y+9tHtm2p4Yf+6eD1/71/8H94lPnBoZDU9MdH/y1yt/+IeDn/6v9dJ9f/Il4Q/+ 4OSxV+qlJ37ni3vPDC0vHXpxP5fP10uvOXrEyeehVEtnGniO56Uqy/sHzyiyrE+Oc5rS0tTU1tbW 0tKSSqUikUgQM6suwMHPBGuYJVDU6PUCEmAE4hIRzCwKst/IsqwoShBgsq7Bum0fnsuNF8td4dDG VNwVwowfgHC1MWemDi1omMBEWIqBOtpxbX9WLc2QDEFQkUiskj82Uc4RFE0SoXikszXdJjCN6adt fvoptam5unEjU6m0PfLw2Ac+CCu3fOXLJ3/7C8tLSU3r+f73hj/+iQsvzezfb8TjUNqQ8/qF5Kvi 4eFhpVrFZqYSLJPxicfjoVAIJHZFyOhAfQUf2IDnefhYN4UbeyKI1wEJMAJxiQCh1XU9iPBc8QmC PNeTHc1ZzoSihjF3IBFPtrayFynQlT33b9/9/HEVD7MxjmZxDATY8qNaMKDHJEFn0re6uXsPFBf8 rYVktK+nY+9VA3f0ZtIkqswvIaNz86emptSxUVYSE4lELBYLh8Ng/oKBu7z/GYQW1oDugnEc94lG o6DBQWxLJMBrGeSEhbisWO7WdInnbPxCF5igCxo0GMzfcrmcz+fhHZaDCEcqzZaFMGHoEcKNZDIX S30xL4AFTXC2k6uqlap6nvK81d+p+OoLlbyjlMRXyqdGxmYm33nLJ7c0Z1B1fsloSiSmC0Uz22yF wqX5GU3ToOlWl9XlFjDHcaC+qVQK8+NngUgHUaNRxMo1DhJgxGVF4OX0zPETkqoF/boMTSVCofly BSqiQI4JAudZhsSImqa5QVhdfy5mPByqKYrpxRvyhmMJHF5ENhZdEGteECJfjzKx6LauznP/bn0c Luj3O2/i9ECAgwCT9SDPtRochWaznNPZg4EpvJCLb94kxOKrcjVsUypVpXi6ud59rIkzE/na7e/5 x19xVdO25k999ztHH6KF1jtv+PMNUVwzDBynMbz65EPfweh9H7nzM30xeujEfz549Aelys+/+3T2 D97zsRjtVxquY1gaHC+G0yzHotQ8FwOKJMI8J4ZCDsfpuqbOTge5CFe4XwU5G1RVhfsNlDjsszx7 NGLNggQYsT4IlNU9m6BIVFTNNIJlULyXR8d+dOAllqJ8/QNxxUkCt/zoDfUKifClcfkMUFhB4oRz jtEMlaAFQu6vs13YCX7X7l1Nsajjp7ODb/E0zflGSZCspu4Cc25FWU/0C4oLhi9ocKVSAZvGxAm2 oxs2VSZGW8Lhps6u1Zlx5MqHD37tZ688IrNv/9Rdn+mNMoWZZ+57/l/mxMLO67/14e0tsAnbuY14 5VEMp5hQNp1cDC4tlU/4V4SmaEGIZK7a9+lwOPQfz32rXD44q31IcCovHPjnZ848J5qB+cz3df3G R952dwgZWqsNS9O7N/RtUJTDwyPV1naxUpYWcue6N8PNJvjhWeAd2nb1kNFIgNc+SIAR64DlU3fq 8yADA1fS9B8ePDyZz4PS0gTJM/RCVQyxzI7WFsJzL3LAihVYpqrpOE64i7UWDvoI74ZlYb5VTGA4 2LsCTWum5Tq2J62Oi3slbphhZE0LqjPFNE8Xyz8+chRW6t5BOPDFvnRye3OW9/v9eB+wQoIOwBXZ 5aBmDDywAGUZdEcXwXLS5ISZm+/d9+5QZJU6n3GmtWlL+/j+wdpD9z+GXd+XPD70CKhvKn39rtZY sAnFcHB8hmkWS1UssyK7g6Eq1UpJr9RmT+eG/eRBUY4gxIVnHz75mIVFO1p2pnh8auokTiqO67d9 EBeBqCBsaG05NjrOt3dWJ8bP7VKGOw3e4cbTdb3u04fUd12ABBix1gmM3SAzAVQxZ2bmBufmXD+h OiCq2nBuoTUazoYjtuuaOB4LhSM815qI2c7iZBrQGD4SxfyF1/9bEa/32fX/pOOHWYKXI4QEUHuw Xk1dB83WdN3WVdo3qSsYNriQr0gSR4HV6/vCcNzm1pamRPzcsTqoHGu1miRJYP6CBoMYezWmbYOl CXZx8eQre295S3tv7+pdObqt7853EHbhka8Uyw/97BCsiff2vOfWqz7an1qMZ0lyqSSO58/7bXP4 +aP3HsONojibV3IYltrYd1OGpXTH8osJiund3Ltve8ccGdnEX0kxQi49ben0bKE0VRMxhjUVeUUp 3Kxwa1lnE7RWCYIAMX5zw8D1bzV8NtplDBJgxFonMHZnCoUz07OSqhyfmpktV2Ic69mgjmfTCiSx MZkMxaIYRUNl4/pVhhfe902owpJI49hZw5q4fxiMYG+IRsESdyzbAAmt1UK12oSqz1Rr8C3K78Q2 cHyuUumIx0GPe1NJsIWXCzBIb+ACDTIMAuxwPJfKsMmUpWmpTHbXddevdrgrJtu0pf6QU9Grb9zx oYFMrF5MePOc8AVo3zj2yq+6penc/qUP0R2b33/HnltDFMlmb7ip9/BzowfGJn9YKu1vSm17y77r UT1yUYEbKBYOzfF8escurVyyFMV17GAExCt0bJKk7EhMJKhZRdUX8guGlRUlhmV0yyb8JwLDFhuf sVBIhXafZWGBf9ZSLE+KJNrTqfRS7wsUEWeDZPhigB4cRIOpdya/VmhGKJUV5Z8f/XlFVnzD12nj 2TaKMDHcwXAuFo9ksnwo5NQb7BfnOL3qh6IIavGR4SKRaCaTdd0Bf2RXEUVVrOqKMq7qE+XKVLkK x3F6Zm5PJlmvtjxXZ1UF6S2XyyJsr6pURw8Xj7u2VTx1/GOf+g1utRMtaKXj337qywtLH63aU0em btjafNOKzSxTq5RnTaxtxVTfvqad4/kTtmfy1k4OPZHNbn/rxgGab77j1j/bs/3U/sP3Pz99UJSm bSyUuu2TcVSXXEw2tDTnq9USTvBe2JDzhMCG26yG45LpTOYK2EIx8HJYsRXub7bczQFf2gYW4oLw li0bN7Y0B3IbuDUAQV/OeacUB2uCViOKvfUmQA8NopE4SwSdZitCM85XKg8dOTpXqtiuI6lamuej NKlrWlTXqpoTzTQlWloalZce921l3DezaYriMhks4wVUyqrq5ELeMs1CTZqTlYdlr8MQTM4M5uCO 5wIdaLAnwLrOwulUyrWxkZtuuSW0yjE3XHH+8A+f+dszpVmSTmzb9JtZ/cknhw+8cvgvHox/41c2 tNVn9Lr+ySy6pWHLVnI333r9Z/vj+P4Xv/HIyJOKMfjYU58ran93Y2jwxUmps33Lnj2/NjN/dNTU q+p4VTPj4TURUflyBSRwZ2/PyyOjZRFurDlDqnlDJN4Ph7mGSbqukEzyHCeEBCEUFjgOLF2SJrXA AoYNfW9E+C/Kc6phGn5q4cBJ0R9owaqqtiDJ9+8/FGbZYL5AoLiw2dt2btvW2VEPrbVCYuvxL1/H /x/xWiABRjSMQHqDuIy6rgehGUGJ56tiRdXgyR9ZyA/P59IhgSaoNE33xSOWaek8x4Qj4WRybSYn CPP8Fn+ekqgoZ2ZmoVEh1mpF0wQjnrQM27KMakUTRU3TqI5ughfkydPZWLS7f2CVj8O1y9JMoVaK RLfs2/V7t2/u0qo9tiE+N3ni2Z//y76eP8sGjz7O8DROuWSEX+bF7LUtwC62Ta/bPb33xi+0d2x/ 4qVvDZZmTw8d70k/e3D4+MHhxW1JMtTVdEOGR+p70Ynw/NauzolcXmOoyoj/A/g/FO7H3GBZVhCE YA4SLHjhKimSwM9jtsZZtm4b+z1OcLPYBksnSXxWlCxd935/Ag+UtWxYPz1yrFgVefiWr+FeZ3U8 Fswy8HuFqOCvLw+B+VrP5vJx5Yt0ldYXKBIWomEELs3BnBwwCueKpWKtphnmydwCNMbDNGXYTlOI 35xO0hTtkKQLzzxFk14LfX08vWDR25ZdrJTPzOUqomibBsFyVjGvLeTARI5u22FUq/bM1E23397e 27fqJ6XL8yPTR+zQpu3tPf4Kt1o4/PLwYZnafuvua5fcpszpMz+bNLjezluaI+ziKr04OPjTOatj 98Z9qZDfweBapYWjZ3KjTPLmPn7u4PCholgxLYcV4plUx6buW5vC3OoePOK8BD1Ensv+Ur0dRH45 d/kXEIz11HdrWbahe16Omq5Kkq7IlqaCNrAcV3KwKdOGnTIkAVaz7Xgjx5uy6YzAw0I2JHAsbMUF UTBh4bX6q+sT5eujyxiSYSTAiAYC6huEhapUKvP5/EOnhhTDdFxHt50k5qZJHGqbEM+nmpu5aBQn KZxcl/Ee4BGTNU3V9MkzQxPlChmOOKYBK0mOV+dm2kP8tW+9HYyIS3MspqG7JMucHVLynHhJruNY jusZQPh5NnNtS/dcweEUKJZj+QuJT/nqyIL/v0tT7dQjk2GXkSuvEyTJxdrFpwAAIABJREFUuDg7 96aqWya0Dv3p6rpaEzVJEhUFChho/hKE42LjXtc3QYN1jeFtLN0Z9qJPg9kdiURgIUgUsSIEZiC6 ga0cjCvX+6svznmsG5AAIxoGPOOqqs7kFn7y0pHZckUyDNp1aMt0LSss16AJne3sau3vp1nuMqk6 bTtfKh06dqwmyWwyRYLoWtbGzg54NfrQ3iTnZow/b32im+axsQkZNNuxCT/aCR4MMy7+rK6/CHWR N2nbnwSG+XO4vbWeseebfVBj2/6MmgjHbWlvoy+gNRaI7uLA5OUyPGnZNnlpUiy8GvDG0aCVvLAg FgpSqajgpMbz8NuYLIcRBAe/Gkm0CPxAKhn1MzUFoaqX9zYH6htMlOd8gonyKFcEEmDERWF5vKq6 k/OKbRRNmy8Unz81eHBsnHAd3DTDpYIm1aB6jmeyW6+9TgiHG3HsFxe4GsWqODQ7VxarLMt1ZjMb 29safVBvhsXYZPUgKfDm2KbtBI61xZo0mlvwzRwcyqG67UolLccLXQLfIQkSvg0VM2wK1Tfmjyza rhc3FPM7WqFiNm3LC4eCY960L8emMNywvandc6Loee3587Dhb7XGolGO9QdDg+ihy2avErBvAswu b5I2RZOvOzyJuBDgylcLhWJuvjg3W8NJMxp3fM9JMHi7GDIlCF4kaoqkzlbWYJA4SBcRjYJMR5bn a2rg6TQcJMCI1cddSjtfjwkQfKxvACYR2EPHxicfPXYcHtMIRTbbRjmfVzVNiMV7t25LNTdf3k1j uBqjg4MdfX1ed9w6rINe/YlNU1JUVdct2yorSqEmUb6sgsrGOC7q+weBEIag/uW5wDYifok0efAX S7Wa5zqgex5tNU0ryjIskN5UZjfE0CGva9RTYwbHvHk0UPVzHOsPVNI0QwZX+5zhydf5iHgtdE0r l4q1cqWm6UUM10wT88OqZzE75AdtJW0rmPgEv7sgCPF4PJlMptNpeAcNBju4Hi3uigUJMGKVCarm IOtAEHxxReZ5MIOOTc9OlsozpTJPkU1QOcJWokgKQiSVTre20QzT6JO40nm1WniNCgJ+46osV2XF tZ25clk3fevUsQUcC/E8xwthgQ/7PY3wa1Jnp89bReCmKoqiputgESu6lhdriqo5lgFmL2cYJE1x JBniOCEc4gVhUYP97ujlGlwfIiZ8o/lSzmdla6VwVaIMy+Gj1ea04c/dZcVCrKTbrCXMzNOSTJi2 y0b01s5SZ4vCrMW2GjSx89UqtMPgZhmbz8HzTlleIBxKEvFqBa4kmL/hcBikt6mpqaWlJZvNBomN V3RWX4GgaUiI1SeIHAnSKy0By4sa7LoTonSyUAKNTjBME5gsru2GI+nOLj4cuVS+SIjXo573Iuhh XpHVEZbB7gTpzVWrhmkxBA4VboqhhWgkFo0KHBf098JPeQkqVrCfsolEsAx3V6cfKxQM4pOT0yqG mY5T0w14hXQtoes8LzC+i9BZ+rokvZ5xDPYYRdf7RVf9+EMLo52HTzCKzB4/Qfbcsf+e/j1f/GNe Mwh4LChGDw/M/OHnR7vozu9+o+upwy7l0qJEGgZuu1BqR2KVLe8/8aV319aexQiXrSWZxJLeckQQ RufmxHLZwAkzlrRd3JFqeD4PNQBcT57no9GoqqqC31kdDA+f118aW7r+l7c8IwFGrD7B7F54zERR LJVK9ciLoMqS7UzYru66/QTGGCpUhkJHhxCN4WuyG1bXarZLMxxD4Wvx8C4G9b5lb4qY32YCQfNk 2HFVw6yoKtSYuZpkuw5ckw6Bg8o30dkBtSreaBcnEM7wUiixG2JeuM18uXxqfFJWFNV2tVKZZJQ4 x9YnsAZbBmav12QI0uhyDkYz2Or7B2kbHvhK/9/9hDS9/B+4ZWNkpWfvbanjJ+tb8NhQ+I/P0H/y 5+R8jh0dXn7DefFeigsR6iRrr0UBXk5zMpFNxOHmOXF6cFpRyVQaE0KaLNdqNVDfIBY6wPqTCaGW OHdUPlhTd5O+vE1kJMCIVSaowYOke0HW24V8viKKiqYtROIOKJnrCNWK6Nqtff1t/f0Nkl5rYvCB H7z4I5Vsagk3cQzjuJ4XEUbSPBsPM6FYsrcZG/23A98UDTCl6Iiw9Zptd+/esDMVjhKXbW3gEXjN WX50FEPT/AgpumKY0Hoq6Z4gg3wJDN0cBos3mkyn1+Z4AeWPLLak0/CChuCLp4dMy5RtR65JrONQ rk04jp/tCgTYzyMJyutNZA25oI6+w7TrB4FalaqfMMTef//L/nufpGTMTmZs3KSqImFauB9/29x9 4+hn/gv3yiMt3/kxMz7S/J37LMxzZMO4u4e/+sF8NmESDl+eSk2UtI5tpbV4sc/Cm+wLL4a5asf2 vlrt8JEjkiAQW7a5pinnZkRZrooiKDFcYagiVnRBB8tBWk8oCjyl6+sbeloXCyTAiNWnPgYcZJ5f EMWC5eis4GC4XSnhqgr1XffOXdn29oYdomvX5LJm5KvOXHVldhkfZud2WjSClLe4WVNe/vmBl589 dctd1350R3cPe/naw95MUF+ANVVVJAlqzJquS7bXogJNa2LpaCSSSKcTydR6GS+A6v7Wq3bqmjY1 N5cTa2KtZro4JlUdRXYMAyp3qOlhm3AkCi0PP/yxn8ZqldqFuKW3/Pz73d/bT0m8es2esc//foma 7bz/P0PznRLl/QkrHC71bSns2lHI2Hv+/D8YbX7RxL1m6/DWDSbmQltBjsaKXaRJr23j9xzgVrnh +uvPTE0XoRbQCC3dtAD6WqnCNYd2HbR3VsxEqs9WEpbgOO7yDjGNBBix+tSNYHjMappWImiNp2xF Mcrz1sxU78DA1quviSaTl+x4bFPSLRIqWXzp+FRZjKZ237QnLJkKyM3M+M+HxVKm6bqN2Q7MtRzH JflObuGJYRWj2H03beu3agtDkwcWak898ERRufUPbuptW6yeXcfroXUx3J/jcsnO6KICrSf47SRZ zou1qmGAdJGGngmHU8lEKpOJJ1PrceoIy3EbenraFCWXy5V0Y9ZxDJKyJEnNzVEkIYQjcMcSJMmw HLQOA2HAzhe+46zIUxegCtzs6e7vPsgvqNotHz7+3z83H4NWS4v8hc0kzlCnvwcbELbNyGJmcqjl yUFo91ls1sQKXk/65NO9D2FuaYGqWaRlES6V+9An59PrLOIYTVFberplWRmen88VccW2ZyxbKZWT NSnMeM4Cy69hXX2j0Wg8Hg8iZ13eU5WQACMuCotxni2raLsqRZv5nDQ5AY/Rrr17N2zdxodCl+5Q 3NJjj/5fk1hm+6b37unppXGsMvvE/S/9hIxff+eu97SEacfWjzrzw8efzbbd8tYdNzOEF/iBIPHT z3vJ+ECA37L7XaQu7urd87Mn/m5YO33s9NO7uu7h1KmDx38yWpm1XduPXD/w1uvf07nKCRUagd94 kjVtTpKh8WSK1XQ43L1hC9SIQii03qtCXhC6e3padL0lkZhdWJgpV2wMEydGbcuLbsH4pjDNwD2C O45NkNSK861H9ljuLP36Mpw48kRicM7ddMvQb9zjq6+3G4P37v+2qSF4p0+93P+Xf0pW5kLD006q rXzLTfRT3/X2OPFs/5eP4nIN0xd3Rd34gXUnwAGhkLCxo709lZxYyE+XyprjViQ5JtVI4qyrR9N0 4KVlGAasZ/xR+SC25WoNB6w1kAAjLhZQjxc0fR7kSZGN2WmeIt9y97tTmSxJXdq7Dnel2ZeGbXKq JAvcp9Pi0/fuv0/UpBZ2g+/vQeGYK0Q9c3yhKDoYQdPB4VmLj7vfSqe4WFt2QCChAlUdU7WN4pOH v/7c0PO6bS79memtu25f+wIcuDfXP547yci2rOOTUxVFcS1LsM3+7dvSmSxUhRcaZHg9ANV6S1M2 nUwkcwsnSZJNJG2ppuRzrCSzfM2r7sE+NljCn7G0lHQX88Ny4YTnKE3781cpwh9pfn1hCE+fgWLx xmvznZmVZYZ38YlSPlrKw4JzzfvOfPqDkx3uticMr7Rru9nbpicSRjatZhJqpHlmS+JiXI1LA8cw 8IqEw62p5PDsXEnC1CiFqwo2NV7fBm4zMH91XYfHEpQ4EomYprnijr3MQAKMePOc98EIBhGH5nIn xieP50uYYzO1asvAwK4bb26Qw07q7o/da/7gC0fFZ77z4DOYV2OyTdlr37H7w61h1v+I0RRH+PNY ziNI0rEXjpFK4fRLk89U9QqORyJCN2uXKtI8qC9D3/qRX/2Ymz/w4mg+wa3puF31sGS2P0Tv12tO EJcZ8yMMw8mLijo0Nw9laY7JpJItra0Myzb6wC8WYFr1tLd1trYcHRycr/B6JKJVK7WaBFdG01Sa ZryAIctmKwWuuV5IJ89Z2nsnfdfr1zXO1PjQUQyLquG444fMxh2LLS3EcmWttduXdUF6y4eHP39X LRqrRL28F2RtIrgFjfd/6eFf6734l+GSwlBUcyrF0PSpyclSRbRDYTPbYizMm6US5jogwIH6hkIh VVWDiYuXsfpiSIARb5R6yt76woonBJ6ZwamZh4+9IsoKg+NRimzbtq25q4uiG+bBSTGt1+y5Z+SJ fxT9j1z07vff/omOpeQ/GE4K4baYJ0LOud819cd+/MJjS58iAz0f+dUbbgrRcmd60+DsiGw+/f1H 1as33XjrDTe1r23zdzFAije3yLQMww9RZrnO4s9Y1vSyqmpg9ZJkUzLZkkqFIpHLstNvBWDlXrVp U75SHZ2bKzGMbNmGIkuiSFE0sayD1B+PpGiW4XlBCIcEJwyKzAb+0q8nwHzhqhua9j+ReuGp5u50 LcPzg8d6fvRA/OUz5q//9StpzHOR5mKllma57l8VxPHy+qmDsByetzbuBcEmLXJ99//XSUaj12/d evKVVyYkxY3F4anTFEUrFoJZSaC+IMNBBL3z1jCXE0iAEW+A5QEmzxtjElioio8fe6UqKwOJGNRh 8Xgskmhw7l6peOLAyIvq0keC0Vccc4Aql3RvZshZzr0ETiRCTUVpzv/EpZJNFNSLdPyabR+g2cxE 7sTI7ImnXnrp1PRb3n3Lf+1LxC/yqbx5vJ4J2zb92GSaquqaahheNEfLcVQMFy2bAcM3FOpoyiaS yfXi4bwqgHxmE/GwwBeSiUJVnMotKAvzbrXqWtZyAYZrwnEctEu84WE/xDRNU677C6rQ4jV3SD99 Kbz/oW2Tg0aKpY+fhifB7diS29iKFf09LwruIi5OuP6kc/KF+zcqWdyfLkVY3oD0zMc+UwxdJhoM 13Prjh3c+Njw9CyeSJIcZx0/ZlYr9YrFXuykuWylNwAJMOJCqfs2BwEml8eYrD8nhmU/PTwyWSh2 RcPtiTgdiZKN7sMsj/7s34/cP1KYYEOb96TTJ2f2K4UfP3yIuvu6TzcJZ93/ui5Zrr3i63Tkrg/c ctPs1AvPnH6kpOVfPPy1snjy5q3vNKuTVPiqG1v2daUef+jQfQu5p08s3L1mBXix89nyUr6qsizV arIkaariTfYVIhYYd47dkk62t3dcIYbvuQgs29ncDNY/RpDT0GjLzdUWJkGDg1I8mK0kCCALFEkx LMfxAmgEBS251+2FrvVff/qzvznwj/8WHR1j5zCXD9duv3vyzjtmd/YnH2UwmrYSKWuZqjpcqtaX sl/EyIM/6j941q6cX/lEMUjPfLnQ09kVCoUHR8fKDJPcsr145KB9NnU9Po87+tnRstbpTYsEGHGh 1AVYUZSajyzLQWdRvTt6qCKeKVeTDJXlWCaeIC6xv9W52IWfH7pvpDzDCgO3Xv3b1/W0bn7xf377 9HNjo08cTO66fdd1nP/YQi1qYUG681e/GtjION7V0rqjI7txY/eeHz78fw6q+cGRZ91yzTRemlEt lqYdR/MnEkfTvHDpz+/C8X4+3wJWFLkmVsVyRdZUm+W9eR6lwvarrmpqaaEa/ns1GpZhtvd0t6QS R2hKU5Ti8Jmgs4TAcYZlQRDgEgmCAK1Q77a/gBFKhxHmb7y7tO3GSFn2Et+HomoibvKcQ+C5t372 hY0f1jJt+nLtIIWxe75odl/T+/QT3JzmYpxLY04iYrTtmM+sSxfo14EgiKZ0OiIIR04PlmgmuX2X OnQ66GPzWoo+DMP4yShXTkZaETBrnU4XvtKfN8QbApqioLigu5VKJYgxCWKse3lePe2SXWzUwXjX TThEOJVuvPoCZHxHx46v/W9P/9UT+6/vab66tSUb+4uqeHctsfszt79rpFikSOL23t77S9nOWOTz H/gwJqRETWsKh7Mh7gwrRITYo3/6uz8dHaMI/h173t3TNvD9+z7hNm/93Tt/468emFkwJh750jO3 /Y/rWTb8v7//T8PJflHXf/EhNYjFLmjTm9er1CQwgZ14ggxFjIX5d9xxeziypgewLyU0RTYlEhu7 uzGKBgt16tABuHRQxXvJjEnS6/UxTNsC6V0axXg1sfH5cSlaTzfr6ZXrbT5Z2HCe2fBWuGn8jvfB a3XOZ20DkhkKha7btfPpo8fcRALv6bWK+aCSkSSpWq1C1QKVTDAhuP6tQHSDaFlBwKyg7bjuBBhl Q0JcKFB9a5oGj0ShUJj3gQWwgzVd11hOC0UtisRsJ6YpWzZuTLe1rZ3wznv/7E+YP/wjleP4f/2X 6C23HN171bbHnjKmp+ff/4GO3Hzlb/9W+P3frwmhpdJ92x57VBsZWfjIBztyxcqXvwyl5Ug08k// uLy08IH3tpWqlS9/hfzCF2ZZpusHDxy6421Ka2ujz/X8wGMedD5Xy6V8LpcvV1ScsEmSk2u33HZb NLZGe84bS1WWXzozcvrF58X5OaVUAgs4HIkkM5lsc3O2pSWVzcbiCV4QgnyL667qX2uoun5waLhc q2GmGalVsgKfyWSSySTIM0js8pDRQYCOYNK2Fz40FFqeXXh9/RBIgBEXimVZqqqWy2WQ3pmZmenp 6VwuB0awhhN4a7tDUkYxT1rWtv4Nfdu2rykvHsIwrvr377E0fWzftdkXX9wcCR9zMaWldcfE2EKl euojH93xvfsEllleKnV17zozWC8Nc9zLe/cuL90xeLogivXSY7t2if0DjT7R18QTYF1XZLlSLs3P 5/KWY6hKnKZ279qVTJ9jmiGWmC4U54ql4eEzEwf3m7VaKBJJgQC3tDR5AtwUSyABXk2qsjI8O5sr V1yxIthWmiKDtMG0n1lrecTKIMEwlMZ9YEHwf4gg1VVjz+INsQY6CRHrh6VuTC/RgqIokiSBBWzy IY4kpbERbW5mw5at3Zs2ryn1xbxxOObE295ByRIIJ7zk557L3XADrH+ZZcW+Pig9+a67mGplZSmO 10u5YmFlKU1LXV31UrFvQ4NP8sKwbadKkK5tpCjyqt27Y4l1HNvhEtCWSiYjYdextZqYO3Hc9adO +47/i0mvAc/qOscJqx6xcj0OTDaKWEjobW6WVK1qRyTHNgt5URTrslq/jPAxSDCc9MPZwgbezOz1 aQEjAUa8MYJ6x09V54V61g0DT6RwklRLxUg0et0dd7L8WnTU1MDOWzL1AgUFylu3BgtGPA6vN1Ra 3bjx3NI1TklWJiXZxPA02L5X7+OFSxgQdH0CtbnAsgMdHZKmCbF4/uSJ4O73pgJ4aaJ0qPMXNfgc H91F56BlLkKNOot1RCwcunbzxlNDZ6ZrkswJ0tiZc2UV1gQRK6E95E0MC4VAjNfpnCUkwIg3zGJI ByAUFrr6CJY1RBEaoe/62Mc5YU17Al+uvBqvYKkSWlEZeaE2JGmqVAYLuIki9uy7YblLC+L1iYdD 23p7ThIkxTClYy+D7qqqqigySAO0RFcoRKC1ZBCxkqbg/xchu/BlC1wmlqZ3btlceOmIybFWU4s4 NoItm5CN+cFhQYChCoJ3RfGm0q3fScNIgBFvhuBed3kB1Fcvl6yF+ZtvvyMUiTT6uK5EFqOS+U0i /5+DwYez6yLTsiYX8q5tdyeifb19BFLfN0g2FgtvGjgyQlmKrM/PyaIIqguGMMvIBEXWQ0ZjgYMu SXr9ohzHciy8Ly9q3BmsJ0BuE7EYThA1gjQUpTY26lr1oOueAMM9Dy1+TdOCOATrVH0xJMCIN40J TXuesw1dOn1y57597T09qI1/4dTri1+y4qiHdwYx8EYF/Pcg3vPyHRcUrSrJnclEZ3sbUt83h8Cy m9rbxZpUFL1J8FDvK7JM+w66Z3eQUjRDc56DbsiJRHAvhocXU9pFT8cbYWdvd6VSOTwy6rZ3GrIs TU24S9Hr4N6G9k09YBYSYMQVBzRHJSGMkZQ9Pblh86Ytu3c3KNHC2mJ53NrXqhFgvarrumliXhJD HGoRvzMBo0nC8usR3A9QbC/1J5M4AUuO7+bD+R4pK/bm+EPyhuENSeqq5oVGAbPAsV3PCvb2reFk 1XGzAt/R0uwZZKsNVIxgdC9LXHDBuO54Qfthzrm9m9saPn+zwPYaEjhFvPrRsl2SJKhGGJOpaCQR iagtLbXJiVIhD0q7GCBimQKTFAUXWQiFzJgJ6+EjxTAkWMnu60eNRpwFRZKpZHJA1U5NTkW6e6TZ adtcNILhGtaD4C52xa1P9cWQACPeBJbj5mxXISlXrgmGds073oHcebClrmDMTwblLobIfrVmgI+G bUPtW9O0sYWCangp50Cz6oYqCdXK0vLy9V6N7WLBhwTPtceiwQZB5AG/59myTEvTVM8xXVF0TQMl DiJFeIdEUk62ida0THOWX40R+vEZ6a8mnXf38W/P0qCZluk8MVj7Xo34wjZhe4Q8S14cZ6pkFjSX Y8nWGBVlVoqPbjjPnFGfVLDOFLMZBNh2XxiXvp53P7kptC/uZR5QZev+Ifkpnfzzq0LtLK6r1gPD 8mMVzxKiCeLOLHNzB5fiLqmkXdXfl45HX9L1Qqlki0Wc8P5bvgHlz0+1/LwCfsBK3rYF76dA/Q5v EBDaztYW2TSHJo3snmtmn3smWL/eRXc5SIARbwyoSWYleVZWccukZmdvetc7+RBS36WBWNf1uoIt C1rrltdIBx10gnx/Y6VySVH8lLJ4JhTamE55OWX98UKQUu9fkHjcj8Nn+nsI+pMt37yFvamWNSUr eUnG/CBM3SGe8VPxOL5TrqaqqiQriqwqill3S3EcoaOTVFVOrrV3da2C+WVb953UFzDs5QK1L0Gl aVzSzZ/NWXkMO1Rit4RJajG0pzs2rfz3M5q2LOfF+/qiH+ullx+BWFOflF2cItO+Ntc086ejBuz8 QMHaGSEF0p2oGc8VYOfWCyX+/S1kRbbP5K38Yrhu5+vj1gOz+ic2hW7O0vSlUmGWptvT6Upvb3F0 RMrNe8d99mWlaQZ+O5wgOJ43DB1+SS9i5fmSfyB+IV5iYI5jeYFgWHh23PPlK1vXIAFGvDFU0xwp lnDXiUli+9V7onE0kXQJX30Nw4v1CHIo+f3Ms7LiddFiOEVTGxLxVDwejkRYln0tfxycJBl4nZPB AoQW9tksSbIsq6pSMO2cbnrZFWyHsgxS96JsKOWKqsq65vVFgwDDt+hQiKMZq5C/7Y47VsUDSCnp L/gLE1WnorsgwOWSMeKvGS7bdjvmBUOznEPj8j9OGJqLNbNEmMahEaLb7uEF44O99Ksn5jiHRo0C hl2TZTb6pnO5rB/3S4aKltrJcJg7L1pBFqqTBQtrIUHoCF/w+uMk42JVxV4w7C8fk8RtkbtbXu2T dtzF6JDe65c/53PgGCYdj4XTGU2qOf51rptjuN/njHOcy7AmQSqmTUMjRJIUy6YolSC9zmr4xzE0 A5udnUngAqN5XGmd2F1NWWiCnpmdi/VtqI6NuPbKdCnrGiTAiDeGblqKYSZwLBwOtff2Nfpw1gqB BQw1haIoC9WqpGoVTXdMg3KctMBHE/FINJpJpd90tgOodnlBgFcwl9mLCVqTQOoVXS9quqpqBkGa iqrJXvxcaAWA8U3zoURHl6lr2zdsWK2AG1P5xXG4nGoVTLcPc0/PLa6ZV2wdc1kML4rmYzNmwcG2 NfMfbKJbBcI0Qa2dWIRe3qwo59UHq65AkzvjdJLxRGWmsJh6aFq2yrYbdt2JZWssbOnbJPWFbZF2 yh1Z0H86pb8g2l8fVG5uiiYwd65inpKcmu3avgAPJJgt8YvichYLhfq2bYu1d1TnvRZC0A9BUGTQ wwEnQ9G0zXEijqmywhgmQZCLbQF/cCHM81GO8xUXowkyHhKY5VOVzhfTI1Bowp9ffEXNKiYJIpOI z5bLyU1bbF2rTU81+ohWEyTAiDfGgdExUdNacLy5u4e6YhyvVmQFP3f8CdRX1bTR+QXN0MuS7Jom VL1N8Xhzc1M0EgWrl1zV1BScT3AksuY5Xo3lFvIcj0eiINS6ohSGh7iklw8jirvbd+1apT/rDJX8 PkDc84aa111HM35SW7wURdUq2liUdGXTKRneSsN0hivGnIhzFNEep5uFZSa4af/HqDGDYZsi9DWZ 4NLYw2VnUaVse1rDkrjxnLK48wXZqtR7H8EOxjCCIvqb2b2SdUy0VdMWbcyU9HtPq68ojrY0ev72 HrwvRgoXQarioVB/a2uE50um7pqW52NFgO3rx2zyRhW8bMGelcswXtpgMHaJYJ6SC00DSVUKtdps TYLTABMdzjnEsTxNw/lFWCYh8IFRXP9bgdx6GYi9oQqSIKklIb5SJjXFw+FNHe2HzgzHNwxAC9eo lBt9RKsGEmDEG+PMfC7JMR3RaDSdvkKa4fXx3SD93LlzHkRFnS6VwOrVTZPDMcEym1KJtvbtoJGU H8b24h0b7BzMKc+iCkf0jvYzU1OnTCMzsCnc1MQIIa2Q337DDatVU9uK8Z8G5qmfp4XucM2eELWp +pVw7FHZ7WGIbJjqS5LDJXuoqI+XvM3hIBkKZyPs/9odeOu5JyeUn8uOQBNv6+aafPPXkoyfWq/u /GTVjita7tWdW+OK27l4HM5Q0aiY9vNF81nRrnmriBjpTojGS7LWqVnCAAAgAElEQVTjYMTntoU2 MM6PTqgJCr9IGuUN5MdjiUgY7+wIHNdxv8u7Hoxj8f/LP9ZjpDhOt22rqlotl2uiWFW1mmXqBG44 2DyO8xQZp+kwTb0a1wOk3Y8B4oVbZEHWWbipCOIK8qmGk4S27O6+3gOnBplYHAkw4jKkriuv5dxv WdZ0Pm+YVnMklEilKPZyy056Xl4N++WH3wxmHy45OXsuaUVFmavWvJSlON7BMQxNtW7eJFxyxzSa ImlKuGrjxu29vU/sP2DF43Qo0tbWllq9BE1zOVN2XcbF+lliWneemZRH/XgfvQIVIZ2jNedEwb4t QYRC9Gd3x95fNk8VDMnCZN05UrNPG061qH5rlPnNXkqqGN/Lw66wjiR/S2rRcXpiSlcxLIbjbTQ2 YboPj0jH/LHzvTGyYNijqnuqZHcGF9Wx//akVD8qhiR/Z0coieMVlkrhZsF1vnpS/vVu4RPXxWMg wBdNobzJMI7DXXgn0LJkAt5UJZaN+xFM4aYqF4ulQkGsVioErdqWpOmkY7OuwzveeCeoL80ynOdQ HeIdIeiK9iYWXzECjPkXLxuPe5kHeWF5ntN611T9fX1dFiTACI9gUl2gMsHc9hWdrkCuXPnmU8/A kx+CZ2BZfJ/Lm8XBXS+Prq5rmjfJxzRsb6Kta7luybQU02JxLC3wEY7LNDWFo9HGPv9gHt1x4w01 WR6ZnXP9wLmrslsw/18sOaaDhVnqnZ3Mj0eUquPOePsnNrRyMVU/UXMez+mf7CVLou0yRGuCuTm5 KE7vqOp/cVweUtxDZUOziBfmjDHJjbH0H23igoNzbfvRBa9B0xqj3xEm7p/SwJSd83rayW3t3Ni8 Oq7aTy0Yt3YvnkuSxkvmotvTnV3cxqg3wtqV5j7d6z60YM6ozr2j0oNz1Ge2hK9OkORF+zXegPq+ NvB7ZZqb4QV3mlSrFYvFvCx7neq6LskSZhqkpjEU6A4fieiez5cfcZSmmSDQ9MoI1Eu2+OUXgBrO JRoSjO4eR5XtYiFIDBMEpfc8H3Wdoih4VFecdb0DH/N9qtfaNUECjHg1v4KuB+kVjHPDq0q68fTg mZKsdEcjrckEcSWN/nozbU3Ti/5bk2RZ0lTVu0AkrVM0PPysbWaTiaZMJpnJvGkfq1UnEgrt3OC5 yK1WdWNr9mHTsby5yPTmBHkghJ/wR3/DFHFnCyNNm0/jWE419y9oPzqh2mH6I338rjhpmm5esk4U jKLubZxhiVLVeDFvVjH84xuEjqWbyFbNp20XascMT29JYbE8jqne9p0CeXWaTpX0A7htKOa47vco E8Q93eyEYp8umMO6++NRpaI57+vm0pidjjOfStDzZfOfR7Q51XoqZ2yI8qm18pv8AuCXikSj8OrG sGBQ3zDNhVJJLFdM29IqFT/GmTe3zLZshmUJb7z5VUfvRd31w1CTFOledkPFJEEMtLXppmX39UuW Ffg8eu7/iiLLMk3TsIY6O+z2q3G5fUifNXVN1sm9ibiYBG3J4Fau1Wr+RBc10OC6HTxTkyYKxQxD t3IMtSbzHV0sfAGGNramqFLN6yaUJckkKTeW0OdnIyy7cdPGTHOLEAqtqZY1ttrzVTQV6jvvTuiI 0LEQ0RmmuJqpgUZGmS4Wr4aIMI3lDOelgheGeqpmfnPIeTpE2pZTVJxZw/G8qWjqfW300Lx0Unc7 o+yt2VdNc1n24o5QBN4SopIxrIsnTqqeIPdE6CaGwKMEs4CptnOq7Hd5k+TmZv4O2h1OGY9Nac+W 7Wdn1aKO3UabD4lunCfDlBtMVSH813qEZdlNnR3QBG5Lpwvl8uj8vMYwoqo45TI8lWDuMQwbxKCu /8a4bxD788lp2h8u9tSIJNdXl+zrk4xE+lqahxzHSGetuWlN06CyEv1MMHBZYDkQ4GDjQGhJPy43 x3GsF5bbGzUj19I1QQKM8AQ4aEuC+pZKpXK5LEkSaPDieKcvwDnLMWwnblk4nSLWWLrfi4rrOf04 JlwfeNoluVat6ixPxhO1uZmOROKqvdeEI9G106C+eFi2+w+/su1dD57akSFbMslf0UI/X5iZsonv vHvH2PiZZIz61nt3vO0HJ0dV/P+5uflpif6Hw1Oziv2TD+351ftegrrwn965tVaZa8KtGT72sd0h SS3HSHzfxoH9g0Ow8727BujBE4Tr7OuM9zTx142OPlWxf/Kxq58/MwI11Fuv3RSePV2RDCwau7E1 ffDoPPwoN27fgp843RKl/rC146M/OyOQxHVdUdMMwd+FHT718X3v/f6hm7NMbD3XcGDzpWLReDjU kkm/cupUgeVkTbVKJRUMPn8q+fLuVD8FBMV4MuPFoQ5ip9F+DOo1Ija/PNDk6Mik58vlCk1rXqeU Wq1WQV+hmoIqq54SONg4sH1Bd3meD4fDET9VTKDKSIARa4i6BQw3MQjwwsJCBew8Wa4bwSbNSNG4 TVLFfH7gmn2NPt5Ljhfv0Qu2rOia1drh6nph8OS2jZuuvv76KyepXzzDbv3oXdXHH390fHLv88/t rVSIm297597N7EB/+vBhRTd67/lQ9YEHvnJ0/J7S+D1Hj+658d0fvWkrt7F/9MDhkqTs/uRHsQce eHx88p7yKHbw6MF7PrKrr4fesOGaw4dFRR34/GfL9977p08N/+78IPbwUf1D93zhg13Cpk19fmn/ 5z878Td/89lnZr9Gj2MHjt71wY9c3dMRam6+ZnTU/+7npv/mbx4qlN4uifc8/7Prbv21d+3pS7S3 nJ6YfP7U6UZftlUA7rFoKHTD1VdPz8+/PDKmgAzPzZCOg5+lv95mjCc2QigS8SKQ+h2vwbSoBh78 qkP6+ZXjLa3zCzlFUUCAveDqqgpCGwhwfUu4OKDNQebghD8PPrCGg17oxp3BWeCXR0RNxC8DSC/I LUjv3Nzc9PT07OxsoVAAa9gL629ZXmsxkSLbO+25mW39/QOrNql0fWBCQ1tRxEo5t7AwZ1i6VHOK xa1bt2zctv3KUd86e3/vv2V+778NPva4JYA+bqzde++h//4n133vu0QyeWjP1Zv+/u+hdOTBH8vt 7Vu7OuulZFvbwS1bl5duyWak++6rlx7p7t3wzW8sL5V/+MODX/y9emnP/d9v/q3fWl764pf+9MZ7 /6Ve2vLFL45985ti/0C99IavfXX+d35nkLp8emvgSRQlaXh2br5UlvM5vZA3ZRlbqsApPwEiqG8s Hk8kU4lUKhSNgDVM/dKSQxoao+mE7bgUo4cF298VaaicYjqkQ9dk0jBwv9QOR9V41Lx4bm8+R0ZG Z4slS1WKLzzL+3jz/fzWRmD+1iOMgSSD7ZtMJrPZbHNzcyaTASUWBIH253GtBRlGAozAgs5nEN2Z mZnx8XHQYDCCRVHUNA0EGCdJoauHyTbbk2O/+t738eFwo4/3kgICrMjyfKEwXSormhrWtQ39A6sT V3l9MvCv/zL0yU/BQvf9/z71rrtslo2ODNOiWLxq92uVcvn8wrXXLS/tfPBHM3e+7XVK5255iwmW ywWXbv7/vnrqtz63vDQ0PR2angpKLyd0w5xeyJ2Znq2J1erEuFIoWLqGeTGovRyIkVgskU6ns9lU JhuNx3kQG98uvPDblZGKyclZyjDI3DwR7Zu8uqXv699OlKqUbjpCrNLSX7jz1nyaan7yoZ7nTzis HZqaZcQaoVsuF9Xbu3Pbbx953zXaxbS6C6J4fGxClqTJxx6ifQL1XeHh7CXDgBvMC1iQbmtra29v Bw2GZZBk5pwkko0CCTDCi2sIApzP56empsbGxiYnJ3O5XLVaDQSYicfTu/caYrUnEdtz3RXU6Rpg GEaxUjk9PaMbRkc82tnSCnVcow8KcaWTKxRPj4/N5fPV6eni6IhtGgzNcCEhGk+kM9lMS3OmqTkG 1l4o5HXM+nGnL2CvZvbwY50/eDwxNU+aBlko4OHrX/6/b9350T/+/9l7DwBJrupcuG7l6pymw+S4 cTZogzZLKCEhEBIgEDwJy2R42Ca9HzDYgMH4JxgMfmALDAYRjECACIoorLQKq7A5p5mdHDt3VVeu ++6tmpmd3Z1Z7c5O6Bn1x7Dq7qrqvlV1637nnHvud8bxqVe67rqT7/9r1+9/0Hz/I+fzrBa/Zc/9 /zg8w3GH5w4fKRTEjscfMXV9vON7DgEjz9jv9yP3t6ampq6uDtEwcoK9o2LspUDA5TngMkbgJDw7 i4CNcaAp2jJNbWiwakXrAmPfM2udx1SKzrNH0RVoGxqiALGqvi4SDjOvpQS0MkoWsUiYYxlIAIpm i/lcprMDS8EwzIhWjDGFGvVG7PmfL73nPu+p3FhYm8gPenJJRG5mw5KBt7+NObGj4sEX3E8/Ws94 FdbZZ8PA39+cqghqFORz/cGelFG1LjfzrAIIQFJkIBQe7O1B49VYzPmsfWytEsTByIbW7ctSgvWD ywRcxhnAs+Goc/ibWixNjUTCPlu4ZyEBjgpLWiOLnq3zH8yjPb1FRV1WmYhFo6+FbOcy5gsCPt+W VSv3nzgJSDLd0TFahBr/BzMotIhLoBkYPLJjyQ/u857MojeD3/x5V6Cn5dv/FjjK6fZCJyMc6b3u jYNvvTWx/tvrPn+f0H+ACYfxhk3b9t36Bn2mTnHy5kKomaa3srK/u2syRxY9rWPKQiNSspdslMw4 ygRcxoUQWtYqBENSX0+8tsbt8811c6YTI+JfjsCkbSFbZ2uPyLqeLiqDotgQDsUikTL7llFqYBhm 5aIWiyTl625InjqhZdLW+ACWrRGF+AnrZ43rvWe8xVGVKDbdVXvfL30nsmZ0dft3vnGsEZnaLbnv rmUIVh94fBna0YKUrvO5LD9QxBOXtKAzJHpOgNTv7e0yVZlWVFZVKciml7UW+RmPk8WCgWxRklis xzcZp46YI2drVZYaygRcxoVAu9xGUYKp4fDq1bPMQKahEViFnpyJoq4j8XY0RmERO0WRscakrqmO sUxA/L9hAy//DfJcbSzKTFX5y7SgXXTu0luoGy8mzZCXbvFQE153iIcYPK6Csbd2Eb6J9y5jgYJl mOUN9aibsYIwfPSwZa9cwDWpZUXmi4hd0Vt75c64bmELZpG2LJSj1OHbv736LweJSF3vp/7uRL2T 4kDKvoBMENFdp9Ebarg//uffVPfsjz62E3KewrKr9dzLeL8Dv9z0mWfAcA/IjXz34D0Pv7w6MtNn 3VyZGM7l5VSKomlTn30PfNpQJuAyLgiIRSi8gquiMjF9X6r3tT/5YneXi48FeC9D0SY0cLiMYnnG zdF8MFLDF/Y8dPQ5TMCkEPAsXta0qSY0zalPjgAnol9JlKRCQRJFRS4ip8FZ+mxRtObx8rK0ZNFa j72E/1UhF9QfdumVAfa2KtaZKO7tLf4mA1fFuKsr6LOcAghzkpmULYohAwLlZcF5CzfgsVPid3ut DbXCB5sFN0lIWeVHfebiMHtDjHG+6kRX8eEC3FrJrwviozv6iw8Mm0652MUuak2cjQplKn5NwM3z V7Q0uXnO0vRc+0nUpeViUSzkEc0i+5K2VaPPGIG2PKWzItaurYQYnPUf34v6SnHrDZ2rF1lny0vT Ii43RXW3V/3g++gFbN7Yd8vrO69aUf3Dp/B+FbWWq0Jf3mT4farfq7kC/VWzUYYEnYPf7RpiWbfX m0+nZ+EXZwhlAi5jUpAMy4cjpGVFEglBcE3b91rikWOP7eo+BiiOIZ38TDxnBfCsDXJ4KcZz01rz kX3pIacVNPXM3lP3V9e99y0btrinMbhle8CapslFCa/oyGSKoogGL8M0SY7ja+p1UVzW0hwMhy/u 26ztJ5WnUka1ZK0OMS0CQA7pb08qT+tQJEBrgI6OJm8VCvp97fL+gqlZuJ4FTYF1Uf72es5Ljxv4 VO1/+kyZACwADImLFfzhYPEpBQ5ocFWQTrDoy40H2uSdJjJaqGU+yk1Zu9qUZ+SRINvLFHh4QL22 WnhDNcvNfaZnGTMOnmXr4rHe4WFoGXJPt5jPI4pF1mSR4yiaASQgz8gj2+yLyysJvMsluCyC0ILH 9yEel2IJzT0S6QGm5ioUdbcH2cUEwSjLru+5+wbR7c0nKpWKkKEPVttSW/rNH33+LcsgTVs0DRka WZQaP3sq8egcvP5AmYDLWJgILW9lBBdZLNY0NE5n7SOSj3irSHBYN0XDnGgHXjYsO6SFa7tYhpnP 5POZg1+Tch941+vf7JsmDrbslG9d1xRZlgpiPptFw5aCBTh1PhSB+VzCJVTX1lzkWgWzqD8m43o+ ednqyFotAmUUtKfsij39ojlctKJ+7I+m8+qP9orPa2cd23Na3RBjl3nP/FBXl3rAIoI8uSmOY9/o q35jV5kfEq3hIkQErGfVnQbesyNnSgZEdolhyyRj7WNIiCYUReMnx6S8Ae+o58oc/FqAVxCW1FQf g4ReKEjJIcuyZEnCKhxnr0FCRi5tayO7vT4vsjWxXqMnW7e48sV9/s4uLq8UQzwt9q/67jcq//y8 dtcXjiZQr6bUcEPP1q2F0UePNElol1qGrmAhHpuT8wW2YjYxz9cElgm4jElBMaypaeKJo/EtU1Qz MA2xp/ewSoeronVuhkFuYiHfdarnFN/yV1/e8jHkfxYzJx974bt7hro3Xf3jN9QFFUOzLMC6+D1/ fAi5f0taPn3XVWsLA/sffum/jg+3t/f/6dkjTTeuWA50MSsmZV3R0f6QZLiKykjskruynQONU1VU VZGLaLSSsAJ2keKFioZGVlWWLF3KstxFflk6j7jcJmADnioa1xBUx+DI1JSkW5IxssrpySMSYl8v T70pxm1GTrFu9YuG4GaaXGfCxbqs/WEIGyYJF7vUiz8fTBnOpqRq9ShWK0Ee7xnh8JxqaeZodglJ 3b3YfWuC6h+Qf9mh7Slav+tUlgTpKwOUplspBSJi1i08v+3mqWo3uaCWlL3mgZi1oarKsLN+u4eH tEymyDCks0Z2vGQ0RbEsK7jdyPrE6VcIPD+0cmPLQ0fYR+/d0nZAqg8Ij2/HfcPl0wUBjqUYjM9h Qk+pU6t4oC14wgVMHUCItTsoLr10mULPhsWHq3twHBMIgMnzsEofZQIuY1KgoVqXxHA4jDr61L5B KbY//NjnO8i69ave98a1G+TBPU/u+8WursPxxZ9prLiOY92UN+L1RYih7qIOOME3+jPqyICB7XM2 VLX+zpsD99z7kQ49Wyz2q3rt4X0/23HkiWGlMPo7mz7x/q/EL5FP8JCCVx5Zpl3XDFcYVBWLAInW lYSiNNVWRxMXP+0N+wuWYtpmuWWJqilpxjOZEe8+q1kDGhquKMoyThacgkJ0lZcsaBZNguoIV+Gi 2LHGW/Bgr7ZXRVxO3trI22WnIHKp8X/tL89olq7rfxq2nN2Tipk0YbWTiQXsBZIUWV3lfq9AZnYX j+pmBnnhpvnoCenRQb13NN5Q7eG+ssETKs8RLzg0VlcnRUlavLTzuR0O+46qU4yQIvqQY1lkdtI0 zQuCpnlQ50+2Xnf8zv6m3+8QTu71nES8Smstremrbmp7y0Zu5y7E7dDlhuN6C+Q8cjRksgT1wNe3 PnBWAzru33Gwhp+FMwW2zeEJBJABocryLPziTKBMwGVMDIrnKZZDdNGyYuWUv4TjK9csfV3m2NOv 7P+JpeyWhnYfS/YEgldsbmxh7FwPgMYIW613MJkhiNqzj7ZUJTkw2Cbmuk8N7EzhT3iG9IDiqccO PizqVsi/aVVT43D3S20FlpiSBQydcr92OhYu+muYfKQCWRtUOrlo8ZKLF8qBhnVYMcXRNqQ0q2dY 26eOvrdgCvmpFiEAqj5IvZQxjwyrfWnNTRLoIvh4Kh5k31rH4ZldgsjktSeH9ZxJrK8U1gTxmGfp xouy5cSW0f97i+bAoPmSNXaRrH4FrnbC1xDmZbMvBYck87m0NoA/AjxJGKJyX58uEaA1xKzyk0d7 VIWe2gW74EUYUzUZfTvdvzABzi+9Pgs/WsqgKKouFk3mcqzfXxgaGrke464L2sHkeawv61J0TTNM A1qm7g623/YBqX5dsGuARO8Fj7RyXaqxRuFoV+t1Jz9cIy3fKI8nYNrbf+MtrOVKHDjCphVIICom oJszgjUF1ywFVpzuxbuw1FeZgMtYUMDPZ00d4/MXuruqGxqm/D00G15z5QcKmrzj1Eu7j5wmCKYi ctObtt7VXBF1skJI2h3gghP711Du6f3ZL5IsFmNWkefIxiq2rmpazlPdNDZ/TVEezBQ3bdr46RsE f2TKHRme0R8BJBmqb9QkafOatRx/CVa8JBodkokIt4klkb/bltF/mieSGmQAudlPPJO1ekRLNqDA km9u9a7M6adTelqDmgHbRfNATj9QMAyC/FgLaxrW873KLgmNgOyHF3NONks2rbfrOG7cSIO0DvcM qvlBTL8BmmpxwVfy1sms9YYKe3S0rCd65J19hGrADI5Lgy0JbrmXolQSedISAbslc5WP+cBaP0WD wLS6v2eEDsYWX9prucbDMK3eTBptHONJE0JbDxBn4ZnQohE34K0ER9NRn58iX51NwehKVkCSo97e ZdGwphg9eVPUIEmR8SAd5i+iEfZiM92AFE0yJRBUiIfDtfFCoXVl8fnnlEL+nIuBPGB01TgeL35H Fqe99h3bSoY7MHDV9Un7XqCTh6NHFWvXnrjzCkhRZ99MUGjacPx9rR2FPKnhaA3enyIh65KDsykV Z996UAIXfaooE3AZE4EkKV7QxQKXz7JTjT/bABTJQpJ2HDZAe2ua7lgSi4/bTtIknjLSTOW8Yy1d T2dG1/j5PFvvvvXDYWxeL/vbGz7+vYe/ltHa9x379r5jwa1Xf/WW4MXlKl8QNM8zgpA+uLf+1jdf ynGwt2AOSpjwbl/ufmVv4SnDOmFP2rrDwusSxjNZdVfGyBgwxAIPT7Wiv9gIuxua+bvjhf8ZMJ8a 1D7UwuYl7ak+QyHA3yxxRUYm0uCJtClhAgZvaXE9d0R6STMP2hsCEX69R38Fe8za37SMPMgF3RqL y29IcB9Z7sK+MSv8/SLz306oPar5yw7plx3g02sDMeHyL9gIrBFNE1t1yFaAsOP6iIxhSiqqhiFq GnqP9kz4fG6Oc8R7SXvBMkVSqIvYa7Lx+hfECQS0BnP5oUwWeWcMRboYJiDwronWYY9wL0niGnM0 RdPMWNB1qmdi/vCVwuPKWHgB3NHkeUcddf+u/ONFYoVARjmAGqnZcw08A/wMyVOgOco+0y7+JunE 98FtCf6mRj7hmjNWQOe/qrGhu7fXFQ4Xs5nztgN0X9DNgqOaWWdiFQBYE6z1B9bEArRAFzzob1rb fkmYr/O+41Em4DImAywOD61Zs+ZyvkLOnX5u70+fOPE8xQRDtJmW06eOf3Nf9O9XJOLU2aNkuu+E TGw4mxSoisDiRCDUO3QkXczkxed++ofv3rztHU3BgBlY+7/v/E1/544dh/7Unu167pmvtlT/ZInn soY8NJQH6xosXbv1jndd0ggODetIUT8NCUQCy4NMLgieyjhDA/hgI5eAoBWohxSjXdQe2ikd4On3 LHavDVAUGsd1OJA3ugt4uOcp5ETAXSeLbQRxRUxY6xs5F0s1diom+j6WYlpDTI8PvJQf+fL/VceF JNgItHZJP6o6n4GNQapowkHJGjTgS/0qou07m/hqjohEXV8J8yf6lft6tdM6/NkxsXqdr26aFoxA W8tT13VVwcCZbKoq6TpB0jxDuVk2GoiG/D7WVsC/mC+sjOHEWtM0hzPZQlFKFeUhUYK6zgCCxeVt IXDmu3ENeopm0RdzHM+xHGRtnp6yE6zLxj4Lf3mQIxkIszr8dVuhS+IN0UpZxNPoThUmOCrRb9SZ Y9n88A/98uNJ9c31rpurWd+spCNNiEQ8nqyuyfZ268pZpi3WWx2vDzVHzbt8OIGT+XwGGGUCLmNS AIgG7ujUj7fEF3Z844m+kwxf07rk3dui5p9e+EFH9sj23b8KXvX+Wr9vLL8Sgzwr1oc/JN2RxJ3v 3Lo61bP3mWN/Onr65aHkn//8nHJtQ+OBziO8t7o6Egh4Q3S2SyNyeUUnPJfjqRN8KEz7/Lwixysr L+lANPZq9nRvlY/xk0RNjHFnNIkgvByzxg9IiaxxgUOStXdQP20Rw0XjF8fF0xWsC8ChnLEva/RD fO7Xx1k1LT+YgW6G2hZn/OzIxdB1aNhrmRpDbJAFVWGaz+toQA0K7HIv0A0S+dLtsvX8gOmxr+HS uOvWONXep/xmQDuaNV8akCWT+EDQvG/QCnvoSjcVYwAiYBPCooFY/aLo4ZzZ3PMnd3GtDk3LFsSc WEAErFnQ7RKqA/5oKMzx/JQF1BC5xiPhOBF2fqJ7eFiS5XyhIOfzhGEA06QhpFm8okZwu92GB0K7 Brt97Dk/er5M/wV+lybBO5o9SyjrmT7l4bSxa0i9JcZ57HVrkmjsEi2BBov9jJcisPIYQfhYqjCk I3NgbZT2A2Iob7QVrV+dLOYheF/DuOw6HBHAvEFNSRntUtFSWZnN5bK9PUNtJy9FFHreYGGcUpmA y5gMeJTwBoKX8Q26WCzwQuX6FR+4etl6REi3GuIDO7/f1XdiMJ+pcQgY0C6GZUgiFKsZ1xdJPK2D 45KWRXLR2o1vjTbuDfz6uUN/TMtKURw+ndypDRr7T43sXVv31qWBy2JfNCSzPp+UTm29etulOk+m CTfGA6cow89ZiDM2Ntcsb2t7WQef2VznA2mTJd+2IpLq0g7nlf9dy+ai8e/v6rq/U/4/mxru7cAi f1fXhdZE2eUu9cBe8V2bGp5s61/upxYl4m39OIkqEgyEAhSRy7ZG6Obqyu7k6WpKv+3KhmQh4wGE Jx5oyrM7T6ZfHNT/ZX3Dr1/oQpTQWF0JqIG/DTEdMvuXtHUsJelua8uymn/diX/uo+tqX9zVta6C q+Mv6jTHq9hDO4x8DgGjDZlCIV0QDVwRj6uoqPAJgtfjoegcGacAACAASURBVOjpHFuQq1sXxzMX eUnK5gvpTLq3f9BUi5Qo8gztURTLMEcqiNghbkBR51Pu2GzxZFPFoxlLRMBDN/iAnzB3ZI0CJFqq XRv9AJ13sk/adVT189Rbm91LXYRhYT9MLOr3DuFg+tsb3UtcoD+jPdmlPJ40HuqQ31zLRgHsSqmv ZKyMadf6AGBpmNscpWd6ptTjEhqqqk64PeiULXPC5fbzG2fy/uczygRcxoXAC5cxVUgGrrn+S6tN UBGoc7G4p8Ubb7qVj/SJXHM4OuKhAK5p0VvvrNjs8i8Z1xfplVv/wZUshqPLnQ8pPrpmzXuqa7bJ ZDDq8VTXrewb7MvKEsP6IpHqmvhy7+V1ZJLjSLc74XKFIxWXeizDkdtefPr62sY9Lc0bq2Our/zz p+/+uwJJve17/yx999+OdffcsG/vZs71o8UNf7exif3c55f8r79lGepd//nVN375WztPdt5++mBM 9r0cb9xyW0vVP37qms98ocbLLPriF2Lf+e7+06fXH9r3NZKvWFTzmWuW1v+fj5mf/2JjvbntW1/J fPffT3aeXn/6VE0+r1U3f+S6ZWv/4ROeT34xzBFLvvTFhH3sLe1tb1cKz25YfXNLrftTn2j+yOc1 3bzrf/7v7Z/9cmfXqYuZozxnctcW6cRcPOZR6aaZLsqiosSQoeCP8QxHMxdZenaK8Lnd6C8eDtVU VvYNDZ3u6Mgh7jcydikrW1uUQ21gADij/TRScgAAZBOM/I2rIDv+yzV1xLooqmbvsPmnbi2PV4+R McGOzwDCb09zKAaRVSHro5wQviKP/AqFo+KgMsgsz+rPJY2cYUkWkZLUHx4rnlShNnLNQJEg10To mU7XQufLMky0qTnd3Yksy5n9sblA2QMuY2EDkjR5eX4M8IWbx1dQIimhqnprpT06jO3DuxMN7sS5 B1asuyIC8Xg2diztiSdWO68b3Vvqq+2yRcBR2bvsEZ+kdElubl02BYODpMierZtXf/tb7/jiF+D6 dXs//Zlbf//fRD734rZtW1avDv/sZz2P/cUrSf/yxS+wjfUv/9OXP/TgT0AOb716ddPmP/yx95nH kVd39Re/QK9qev6b37rxZz8gcrmdm7duqau9avv2nkceRcf+3y98gW+qRVs3/evXlhPETvTNDbWJ 7dsH7/0Z7Xb/5JMrhZUNaOsd93yd8PvHjh382c/R1ncvrqdbrkZb3/fTb0G/f8/Sxeh3011dzx85 duHzGqtXgRdJK4qmqpquGbo+6hPDomGmVC3gEpbX17lcrtlcAsSybJhlgz5fZTR2uK0tnUqamYxp R8JZFhsB43uF/ZKkaZpB2/BUMUcwLEHT56drSQpOCdZM4gcH8yRODITIc3xzk7thNLxC2/0R72Oc 1ybTOpHS1GHr+WFte8G0J+XJIEMMF7QjCuqp5Edb3Ws98Df7im6GnJ2pYb/blahMnJxqHZFSx4Jg 4DIBlzEpBNf066pfdHrMhXfE+TfT1CL8U9DrC5JkwOefGotYLLvns3+/9v/79O7fYVWC/Y89alRU pFeseOQn9y7/1rcPfu7z6EO89dG/oBcHRrf++dG/rPqXr56zdV9frxEZ2Yo+PPjPX8VbPz2ydZed 1Dq2dY+9lf3Mp58Y3UoXi+dsJf/lq/vtrbvtrYMbNuKtb30bYW+9AJzIM2I1VVEkUSxKoiLL6DWu dwcJlWY4QWitqYrGYnO1+hYxaDjgv2rtmo6+/u6BgXwyKQ8P2/nQ1LniizSNeFdAZoLbg9ebgZEo tP163J6jlfpwEhYgwix1W4NwRfjMIEl76M0EcXDCwd8y/+uENPYuyNPvX+IOEYTuYhoZo0O3vn9E uq2Sv361r8ZNXVz4/3LhFYSAxxMMhQqDg+hmzsZPziZsKcz5zsPzWMSrjOmCoiiFQmFoaKirq6ut rQ39O5hKEYlqQeDfeP31c926GQHq9qqqSoVCNpXqHxxMmlZdJLxi6VKamc1VjCUNxL7I30WkWxTF XDabz2XFfEEuSiZyJH3+yli0sbbW7Z6N0jcXA8M0j3Z09nZ2SAMD0NDPolW78g9iX4/X5w8GfX6/ 2+vleB7rJFNnUXWqr/h/jslFQH1pva+aJgSWpM8JFFv615/M76bJ25s9t9eMRJEzOe3HewvP6kSC Bf0jgWawqZK/o4FvcJGWCY8PKE8N6e0F45QKPSx19xL366LMxSXAXS6OdHUf3bd33xN/MY0Rnx2d Ms8LXr8/EovFEpXRykQoUuELBHiep+yowGw0azpwsKMjJ8kVlr7jwQcLuez5O6A7i04qGAzG4/F6 GzU1Neik/X4/y7Ln3Pq5QtkDLmNSXNYE8PyBSiJ3h/S73WX2PQcjHrCmFotSIZfPZdIGxzO8sLip sSoeZ0rpctEUtaSuzi0IxyAcPHVSKxTGTV7QHMepHuz72lFoHvnuzOgS2AlTsQIC6Z08wqJaRFqz znVcKOr2Rl42zL196u4i3Nmn5BXzjmZ3HWnoFPWmOrooG/91pNimmS8MaiuDTHxWAsM+l8uXqALz h1YvEoqmp/IisheQDa2p50sIzBuUCbiMyQAvT4Jj3sACwMUykYssO/jaApbKRn6wKiuyJOosZwKw ddXKWCRCTizOMJdgaKouHgt43C9Q1PGnn0b+u/M5ZRMwMiaQxeD2eAxdQ+6gsxZ2sq86j13HNhBj xd/huBc4vAvI6iC7xA2uDDI7upSHBvXDae0/jlJv47Xf5aELS3YQTioURwJ2tggx6PEIwmwoM88y jnf3FGQ57vOmhwY1VZ3r5kwdC80yKmP6AC6+FtD8BRqXVZJCbpHX53v1vV9LcKQaoIWLNhqGbnl8 lNvzhuuuS0SjJci+DiiSDPl8m9esabzqdcDtQo47+pMlSZaLeIGyphm6YZrWuSKZoyApYv+HtgCK 9tJEfSxaZdtkDEVdubjF2WHLyhXLOCLMkbcuqqwbtdg2Ll5kJ1XBa5YtIQCIBdhPXNv0z6sTQUBU uam7bl43oFrtovGft67NYokP6oNX1LTGZsnacxLAedf0FfMuDYiKwjNMfSiYGhic17OoZQ+4jEkx vUs5SxM4QRWQYY5ZGGE6OA4jK3ZHxyfrguPU+eIQyDTRcYkoTdd1jaRolty0amUgEJippk8fEAff tGXTI5pyePtTWlFCJ0IxtLOMysTSx86C3AmuRjDmEq7dln3ggf1Scemvf014PfLWbZtJoN111+pv fZsGwPWmN/3XT3+6p1Bc88hv0VZ921UbvB71o++55///VxaAxDvfvO7ee3eL0orf/maF17Pq5qs2 Bz3KXbcd+u49LAmq332bde+923Pitkd/uw/ZANdeOwuXwrmp1bW1x7ITzJLOX6BOTZFAV+Tk4MBc t+WysPBH2DKmjHmUkTFlIHeIJEHlJapflSbGyiGYo/Wd0Bvk8hU1HW2SNQ05iIh4sDKD5aSPArQD TVKImliaZmhKYBh69KbjVT24UjJyHlWL5VY2NYbnT5SeZ9krVq4Sk8m23bsgvhQjC5ptAWTnKo2Y KZZ1Jj0YeYvP3fPDDR/80Ipb33won6eHhjZ6PH3/86uTd9+95p7/hKr6/Mc/2frhD6++5ZbDhQI1 NLSGYQZ++ctjH/rwmv/+gbN1+V//9Yrbb3e2rre3Hv74J9ff+8OxrVvvvBNt7b/lksTGLwMA64ok amqPHTgwS784K3Ay2Ad7euZvHSQHZQIuYzLAko00TiOyus4BwuPxznVDpgEOndjrdjVZUYYLomEa uml6eMHtcbvdLhoTMHZ2Rx1A7B3jEghYydnIitKwrgN7aYSLpmkANVWTilJO1xPRWLwiUgpZoxcJ 1NSaWHTFunWKrhczGZz663KRXp9C0+iOm6KY101kcfAsE/J6x3v/6MAXPvPZxM4X+m9+I7JU9Af/ 3P2lf0If7jMMi2GLlZW7/vELsWefcxhUe+zR3q9/E70Y2/rK17+ZeOqpc7euWTu2tQp9OGvsSxC2 ZApwueewZML0o2toWFIUwjJPHz8+1225XJQJuIzJAMiLKsU2v6FZsM7nK31T40y13dGQ8oSazIh8 0/lCKp9HIxRDgmgI8YvXKwiYTy9InzjgbBiKhnU2hrOZ3mSSQB6zohRNi2C5hppqippnYwVNUU01 tbKmdx89yrCMgOBy8YKAFyCh2w2RbWIl5eJAOoNFrEjgZlgPzwksi3j39MZNlKqiXtF+402kYaAd Uo1N+Evxa7L7qquALe7YfcPr0YVDFza3aPHY7/aPxpZ7b7zJeTF+69iHswZ02+fxHOlEGMhmUV/l KbKvs2Ou23K5mGcPVRmzCWvSZNAFhWDAP9dNeBWMREptbewzBXfPI+CiLHelUnlZ8TNMa0O9y+2m Lro2H2IdjmU5WzXJ7/VUx2Jdfb0dvQMKZV3Z3OSanwvSfG7XypbmtYsXjYlejf+XsOfFHaWRvuHh TD7XmzY5igq7BR82WRhnoTCeiDlPOHqsDvE5pYhn/xxfm4iHgnQmNa/znx2UCbiMSWEa+qvvNP+B PKO5bsKFMFYLwdB1HF62/x3JJBrlYPSfvKIOFQpBQVjX1Ojxei+HDBCZuDhuSUNjS23dkfbTvHce BzA9FzQdSNtRRmaHz+dztFlO9fQOStKwWPTTtJvnWIaxK9jbIllj2pY29yJmRgyNaBpRNWEHGKiS j6MsAMiahh4AhuPaDh2a67ZMA8oEXMak0PXXBAEzpS+Wa7OvpmnIV1NlWdVUwy5xb9e3gwYBFOTJ AbIpFq2IRKZRHwMxSmtz02vEsXOEk9D5IiZO5XJdg0MDBZGxLI4kbPd5rLQDjhaQFM2wiAXQETwn YDOIomlkJ70W8hbnEKqun+rrz0lFN033nG6f6+ZMA8oEXMZkgJoy7yM8F4MSF8Aa0WS2KyIURVEs 5OViETEx9oMRCTO0RjHxeKw+Hg8GAsR0k+VrhH3HA51yJBAIeDxDmWxXf/9gJkOqMjDOlF+gbPbl BcHl9qA7g+uBYH+YhCV5rXCUZD6vlB0DehC6h5M9w8mQ12Omk+iJmHBaYQxOTMKZRADjMAdNnxxl Ai5jMgB1Pmu8XTxKP3Lo5DYj0kX0m8tkCjnEwRKOT3AcEwy1NtbWVlezpe/HzyvQNF1ZEQl4Pcls bv/hQ0oma+Tzjv4VxSDfl3N5PLqmI4eYGTdbPKG25RwiK0nIaxSTw3PdkGkAsjY7Bgc9glAfDm3f /sTYHDyOR4wKO4OzE9r5UaCngx5X/6p07lGZgMuYFPr8z3F4VcBSehong0PAOAJdLIp5rMksiaJJ AH99ZFlDQ2N9fTnyOUNw8XxNjHNxa3bu2zeYTiuZNPqQZllBEAzTROM+x/Oa282Z1gRJcSWAdEGs DAUfOnpkrhsyDXCKYFaGgz1Hj6QHB9HFx0WuWJaxQY6mwo3t7xCwz+fzer0ulwvZTM5uJfW8lwm4 jEmha9pcN6EMZ7kRHnywJrOqyjLyfiXFMP31DU11tS0tLSU1oCw84Ih0MLhh1ardFHXi5ZeKySQa 9E1DJykS0bCOlaVNR+Jjrls6MaAsFzLzXgYLub+HOrsMy8oMJ08eOmgaBmJTxK8uG+gFekufXc0J 3ThEum63OxgMIhpGLxw/uKSelzIBlzEZ4HxXmVkwGNFktmeCEQ2bBOFraKwKBlYtX1ZSo8kCRjQU umL5cuTnHtz+pFIsAorUNX0sI50YXaI91808C4qmy5rWf+yoaRqvvncJwzDNU/39ePbX7U63n0z2 9yOiRWyKqDcQCPj9fuTjOhw8vsggeoHLUAqCx+NBHOzsM7KurGTiXmUCLmMyAMhwmqou7JpIJfEU XgQcbWenPqAQi8fDoQ3r1s07cYx5jXg4vHrp0lwq1bVvrzUqLD0maVla3GsjXSgUinJvx2nTlg2Z v0jmCx0DQx5B8BPWyVMn0ek48WSHgCORCOJXxLLoQ8fBHSNXRLesPV/gsYFejAWr5/aMxlB+gMuY CLZCARepONbVtbKlZa5bUwaGE4qmfT6WF9auWDFfqzVbBFAAwaIzmeuWXDqqotH1a9fJ+ULq5HE4 IodiTaBJVhowLYsnoFIolGoDLwqZgtg9NIwMnisa6w9sfyo9POx4sQ6z+ny+cDhcUVGB/GDHCR7v ATv5WU6wGtHzWAi6RNxfokzAZUwIaJnF3m5kM/ansyvnujEzilJ5EC8OeKELx69ZtdI/H6oSYUCC 7AZ0jtCXQUjht9R+wN9Lwtdb8o32JzZABgjfIAGii3oIPQRhONlxBHoNXQQMQmM5tEpjsVh9ddXA ihWHxQJUZDsiYauk2ApljidcIoO7rGpdQ8Op/l5FEue6LZeFtCgO5XLo4lKadnTfXudDh1mdKLTX 6w3aGHNwx44dnyZN2ygp95coE/CCx/j6dE7hl/HmsG4YqGdrmpYTxedPnd7b1W2gXSpr2EQ1a0v/ qJb15xdfDno9KxvqfQuuqihhj/OlM2i+KiDNBF2ecDA01w25WJAngOufSVBBWB+3jFpImATZB8gU AdsArno/SsBkOyCHCKARxKkJbwSgPmXKq2ex3ZODoajWRS39nZ3p0+2GPSdvlxnGdYYp08SVpkaF Kue2ne0D/cg6UNNpqVCY25ZMGR2DQ73JFE1T6Jqvbqj/009/bIyTBkKXGtGt4wcjGsbFRlwu1pby nlA31JkeLoVbMx5lAl7IgKOzhnZNdcMuhmqN1V8rqtorbe2iLemQl4odySRLQM4wNFU1IRyxMFnO G/B7eJ5ZuLWB0QWaF5WPka1g0UxzQ8N8UWYGKZK/xx7thgkqQxi1zqcT7GnVQ2MNAVQCmAQYwGRM cIS5FBM2YWHFSLOUTA6PICxe3ro3k0bcq6q4ZKOiyIgKKMfZKoEhHj3qGVGCkjjQ2TF/J4BZms5I uJwzIuD2g/uzqdTYpjEt7jHX1iFjJw9r/JeMj0jP+X05H/Ng3CljahhjX80ZJlTVKa6uaNrJoSTa YTCfP9TTx9MU6pUmxN29LhTkLUNWNRzwQR2a4wW3OzB/qsBODeiyCPOBgBETCV5vyO8rwXFkAiiA +xWgkiPvkNcLrEnL8sAwVD4KEfsSOsE8QrJ/AsAHlb+zoAHwhyS0SsnkQMZoRTgkeDzS0KAsSZIo chyPHhdEBehvpIjY3K03RQ/+6YHBYlEudHYO9vbOSRumBdGAPx4MDGdzhmV1pTK+uvpictiQpLEd xjza8aHmUlvpe2HMg3GnjCkDPYqYcbGCEgYaK2RZ3jcwdCqVQVtRt3bT1KrKOOB4aIvpCaW3Tm6m gSghmc3UzIfoumJaXo/H43bPdUMuCszDgNlF4CCzlyCyBNUGiG3wwlPueEqYIiw/8n0IIg9I1EWF Ek0fYhk6EInk+/sw+2KhJQ75XzSLJbFIO9Q5h+JqRVVtHxiM8tzeA/usUl2dfDGgKWpZbU3a7zvR 1WNVVbtica63O3XkMGGd8enH/NqSFZu8MMoEvJBh4kLrOiLdfD6fTKUO9PV35sSiYdAQJmhS8Htj iUq/x41rss+zbKRXATx7bcj5WaDoE9PAU3g8IE4NDtdUVs16Gy8ZGgkaw+F5Mb6QJwG7ExAmATdC dTnB/xiAAwRpEObFJFIxmIlBkcDx59JIvDofAY8nWlnVtm+vVSiwnF2UQeA59MfZq1HnVJPySFc3 +vWOg/tzmcycNGAa4eI4oaKCBWDHE0/CYNBbU+eKxgpdHebgwFiEz5lc022cz8ElTs9lAl6wcDqo pusHOrr6k8ND2VxPQbIgpEmy3utuaGjg5slU4qVipH6fdQYQr9bEmxzBQNOyDnZ3i4qCV9ZC/HA+ feBga31dxOeb67ZfCJCkAoGSbqEDkAbsoyQ5YL9+BXBH7U+zgM4QZnRkH1hp1wKcCFaUgMhpLu3M IeScud1uJwWrKEmCy+XG0tCak2YxV157VpK6hoazorSoIvyj/352jloxzUCPZ7Si4q13vGPXC8/3 6TrFsMFFSyVeIHApZzy/pigKlocrIpMNTyedE4J23jr5z+MLM8zdCZ2FMgHPVzg1Ysdqs58vBqBo Ws9w8mRP7yP7D9IkrqfGskxDMFBXXT0vco6mBueaYPFk2yI2NA0byJapoJemNVgooBckRfIs2xKN AvshRs9lOBTylXZoV9I0D8ejMWSuG/JqMAj6FcC8jIPJMEJAzo5CIysnT9AHgfo6CAp47IPcuHC0 023PGxJJmSD42Wv4pYJmGOx+qaqmKpqqYva1NSlt3bK5oWCOYVATUI9//rnnXIFgMTvvPeAxIOJc v2Vrb0fHocOHFZfbVV2LHttiNi0Vi/l8nud59MhLkoSIdnwS1liWlrMI2FHqcD6cw3MZjwU7EC9s jHDMKM5JbybsNfhHe/ueOnQkXRAZkmwK+jk3FoIJ+31UKS2Dm3Y4hogjm6zKMrKNFVXJaXpexzws 8FxzIoYlZDne73aB+XMphkSxLhqb61a8OoAI6Gdtil0N1evsRb0UQT9GMjsI8hmS2mCSaXs3gwBF QIoEGCTIXgAMqN8ErbPrOZF5QARLcwoYA5m00HkGdTyXYT+Dpm0Fz1mbBZZtSsRJ05DCkfoNm/qP HCoMDRoLpaQKclurGxp8wWBXb+/xw0dAolL1+TNKkUvjLoU84MmUsNDz7raBbo4j1lE6Kw/LBDz/ 4Dh5us0xiqI4Gc4ODTtOcF82f7B/IC1JRUVt8HvdLldltIJmuWkvFluasOxpIVWRs/l8SpRkQ5ct wifwi6tjPo/H63aX1Er8i4RlQc98mDIAw4DuxJ6rdi3UW0fd3FZI7wWgm2CSANonAV4g+eMQKATI AZBFpwesbeYIAVvE3FHYJQA9as5EhxNygfZEBzaC57TxyKxcUlcb9Lh3Hz5StWKVmEwiGlbF0g7o Xwp8gcBSjyfodh/v6CgwbJblQTaHxkGn5uA5WtCIjx0dykAggG4NevAdF9lZFjy3J+KgTMDzD2ME jIy+gg30AjExIuC8omZU9UgqqxgGTZKNXldtLMb5fPORcqaIUQ84WxB7CqKs6yQgl9RU1cSi7DiZ unkISNIlMWRcGMBOULXWQLPxTJDZWAnNKKAL9nI3u8Y06Ceo/jP3wroSmqMzADAECQ8g3NBIlC4P j6YVwNF8P/tVaRgOiIrqqqp8bvfBY8cGBYF1u049+wxy1ee6XdMGiqar6utD0ejxru6uTDapafm8 yCdTLE2Nd3/RC0TJTjUkNGA6geixmg0l4gSXCXheAnEt8nolScpms+l0OpfLodearnfqZhqb4DAM YS3HhhMJwe9fSI6vM+eNX41W6Tt3B/vKdKdSfdkc2rklGm1uqC8Ra/fyMD9WN5qLLfGHgEDj2/h4 shsqn7VIGZoBguQgSQFSIaAPWjWEWQ/NxFnLfGEMFr9Q6toRuM5BLgtg6S7yCQYCW9at27VrVy8A VStW9uzfV7IFE6cGweVa0tign+4cIEnF4y1mUrC7c/wT4tQD9nq9aBxATIz8YM3OkispZewyAc8/ jPeAEQEPDw+nUinEwDmaLXI84ihGFIMBX7CuzhUIznVjpxNn0ppxDTg77nceBReKcn82O5gvBFi6 MR6PxWILxfuH88OQAgQUJhjgIA9NO6PKqrfkD8x2o6Ydhmn2trerduZtyQJ5ihs2bjzS1sa63Iaq ZXq6lXxurhs1ncCplFWVAkP3pzNyICTnC3LX6TE7Az34yOVFowT61+/3O/N0Zyz40kCZgOcfHAJG nUlRFMcJTiaTWYbXXLwhSbSp1wQCzauvYPkSTiG9dDiM6xTE1W1JL8M07ELoZ54n1TT7RUlU1Gqf tz4e8wUC88JrvBjgcyylgeO1DNOyZFXt6+5SFYVlS71Y59KmJprlffy2k0cOd+/ZZS6UnCwHAY87 4GkIe9z7O7rMWBwNDfLggFbIE3aE2fF9HRHA8VkypcPBZQKefxivMVmU5YyiZihG9/lRtxOkQuuq 1bWNjfMov/cicSb1TJFlqagoMjZpdd0yHZMWWgTIA1I3jMbKeH2ikltY9gcopVHjNQ7U8/p7+9Rc DkclSKyDCMhxOg8lZvKh5iyqqYr4vbqmMzzfs2cXVLW5btQ0IxGNEiS159QpsqEJDRDFTBoNFk4S 1vh1ImMFaUoHZQKer3A8QlnXU5yAHixL13i5uG7jpmgisfDYF8PWrjI0TS7KYj4vigVEw6qmog/x UwVIKxKFpr6kpqqhppaePwudX1W0yxH7cUyuWW9dGecC3YjeVKrvdHuyr4+kKJphKIaxc2tpXIih VEXlgl7viuZGAoDhkycUNTlWHg2a1lgiNzmfLbx4OHQl2bL/ZJsST+S7Oi3DcDzgsfWZ5ysllALm zThVxvkYLsoni6qCHvhigVXVtVdeGauaB5KKU8OYB6zIxUIhn8tkEA2rioI+QY+Ve9FiUlPrw6GG mpp5xL4jYx86NRxLx7Vlz6FgrOZtGEqxSEPY3te3oqlpoUxpz1ekRbG9vb3vONb3onEFHo6zk2sZ LARNU1hSnSzB2XrERhXBYGVUFDdvE1PJ4YP7bbtO1wzdNFAXM2i7liI2H+ZVMYMxoDYH/f5otEIm iMrNV+lFaXjPKyXIuOdg3gxVZZyDgqIcHU7ldIMyDN40V69fH4pGX/2weQto0xUeMlQV+b6IffPZ rFwsmhAGFy1BDBb1+ZYsWoTGxLlu6cXC8UEcMVtcUFbX7SSRkVlt9I9qWhLy+E0TuVcMLwCKLsiy v7QVuxY20B073t2jScV8QRwpgIfln3kstIRVIJiRorNz3c4JgdrVWJmAptlG00o6ZUgFXCUNl1JU OF4ZkWkksYx1qZ7BqwA9Jo2JuG6ag8hS93rNpa1S+0ln0zll0S/sDc/m6ZcJuORwfjTynL6COpCi qi+3d/Rmc0EAfRxds3RdiRQNNAyVAOhBIGdiKsx2FE1bgQTLvxaLEho7PNU1lMsVgHDV0qX8fJCq GMNIMp0jqCLL6P8jpd0tSyOADgnW5Yr4/Q0+LKVC2nexIQAAIABJREFUzs8xcYEBDc2rGxsO6rp4 xdpkZwdUFdsD5tE/uB6wU4sQTwOXKAtzDLOssSErFeXKqtyJY1hCWRIFQbCtB3qEg1HPnKb200rB kxNpVYcMXwwFZQ4bx5RW9KayJIBsOsWKElANgub0cKxQXVlwXa717OH51rraAEUe6e51RaNacmjU cHdyNzVHvAg9eudIRo+VNRz7d3Yko8sEXFoYkzIerSIwgcgz6klP7D+4r7M7xDG1blcoFhdmo4qA 3tf+5IvdXW4hHuC9NEmZ0MB5uRQrsG6W4oORGr6w56GjzxEAPceugHfJ0sYNNSH/dP38iNiBhUgY 50Kji2ARwJ2o9CQqeU1dv3WL2+udrt+aHeCKTLY9ochFsSBKYgHZFIppahQTDAbrEomA1+NaWKlk CwBuQVizfFllRcWRWKzz4AGKgBRmLkflH+9gd1RYIjoPE2J5Y31WktSKmCbmxUIBWRAMx9ohdIay pZKn1nguP5Q4cpyXFHK4j1X8bbdsqP/P/wgOZyldhzSn+GuTd7771JKw9+jLrT++nyIINpeli0VS MyDFmoGIGL/q0FfuzF32in1kZDQ1NIiqdjqZ8tQ3woFerIunqsViURRFRzX6fM0sRxuLtuEodThz PTN9E8sEXEIYW1/k2GsIpo1zCPilU20vnDjJAKIpHAqEwuzs1LK1xCPHHtvVfQxQHEM6NYPxSANs wXMSUIznprXmI/vSQ/beFEM/vefkr6vr3vuWDVvc0yqDAW0RIuQLM253oKHRzKQ2bN3q8wem8zdm B2dmtWXRntWWFMXy+JorK+trqoUy9ZYqWIapqUx4fV6SYYY7TpvomTVNZxLBFoU2HBfKGlettqTg d7tXNDbu0bRcR7uUz+NQuh1CR/91ahWgNl+iE2yGDz+9+D9/7uscogyT0BTSqtUSWvVTz9BFxdnD S+wKHn7R87lv9+YGPS+/co6rS/V1h45AzxengYAdVFcmUoqa1XV1aMBhX6dmA2GrRqNTHu8BO+UZ 0Ie8DRwSYM9ciulp0CQoE3AJYWxxkaIoqJfIsjy2eNxJ5ENUPCSKz506jZ7y1fFoMBRmZmZGEMKR 0WPsA4tgo4EG13Cnve5HMXQVNYamXTQJkIWA9tAAGnty6CiK5hmahIaay3dmDn6tkPnrd73+LQGG HPfleP/L6NmYuJC96orEpIH+TatXR2PxyzrbOQJ0ZKsRAaPbLUr5YhEEwsvraxsbGua6aWW8CnDK j9d73aaN21km09mJH1eOx1Foih5JhAYAj62lmtBUXRE2rJaXshkxl0UczPE8y2EtZRo9utRIFP1i 6QeaoQMPrvzaVz2nCcgLJnIdVZUwFKYo4XIVgcjAP3xNyu6u/uXvhI7O+Je/SrznKjwWUOt6v/7B vuYqhSZYcSjU2ce66vunb0112Odb1dSw84hqBMNqejhfKCB+RaMoulGIYsccXAeO1+tyuTwej9fr dQaoWWBfokzAJQUsYmxHS7DOXS6HTDYsMGkvIUddRzXNU3mpX1FRp6jhWb/XO0Psq6vp0137FTpa X9ni41hoGZnUiRO9bXzd7X+/4SOmpUvJQw+98L2Dyb71W7/3hrqgivOQAePidv/hDwRgVyz5/O0b VxQGDj619+eHeg93DDy8q631dUsWE2p2KNtX1IuaoeO4HVfZUFk9xTkfANhQhAn4Gz2V9U1NpTnG XQxwTN3CHIwzrUKR5prqMvvOI6BRfNuqVS8CMtXVBbIZ3A1t3sKpxE5UE7mSJRmLRk0KeT1VDY2n 8/liJsWLIvL7cDUhBtsQpL26mbg4EnJ37Vv2vXs8pxmtvmHg7/6xfZmv6r57orsJ0YdGJwAZOt+8 +GR85VCVf+MnvkWand68gr9xcf2xtcuLAgOgRQaD6eolJk1Nb8qyi+PiwUA/MtcrqwqnTxGpFBpa 0bjK2MvGiHE+AOJjR7TSUY1mRjHlaPzFo0zAJQSHgJE/hAg4nU4nk0nEwchkw/OddmJOluVpw+AN vboyLoRmKutKLJx4fPtXu8jqVcvfc/umq9Ldz/5l332HB9oql3x2WfxaFvVLX4XLEySSfQXF4ngv NxIrVUc6KnpmKS5Ute5tIf/wzz7SYeQlOWlosVf2/PfO4ztSqjj6O5s/8b4vx6fUASHDcpEAWcjX L1k8fwU3nMl9vJjbgpbLtayqur6+bq4bVcalgWPZ1UsWvyTL+Z4uIpPBpItXA5MUXpFEzcIIPmX4 3e7KcChdU5MUC2KhgKPQLCJgZiT0iv5o+tUD0Xqm+YffCx5MGY1r2z/7ubYVNRYgTr3v77vuskD/ 84sIiM6fkYu+3u7oK0eBaVlkXHHTHjRIpE9Uv7BdV1NU1qB1nYJk7ppbeuqmc0wTWLa5qpKm6N5U SmLY9GA/Gkud2d9z1vI57i9iX3SznPoNgiCYyCae+QWNZQIuITgTwE6VBWSpDQ8PIxpGr9EnWMkl GtcZnsxl4/FYqLp65prh8TauW/a6/NGn9x/+CaG+mBs80JEdDIWv3Na0mB6xi9HggntOMn2+tKxV LA729h7LZ04fH9g5jD/hONIFpeNPH31S1K1I8Or1ixf1tj11QnRPLVHaRNTlC5CW1VRVFZ//6541 05Ih0VJXX18978/ltQmPy9Xc1HQgl8unkrjgneM9sQxNjc6nlioHVwT8kUhErKiQOjsQ8TDoz2m5 DWRAgFdbR+s9vr36ycNEqGbwjnd3Lqu27LM0GN5giEiyF1gWKORi3/taSE36jp0kdTN/27vT1DFc 13rgwKLv9BDFNJBGvqoQuWJ6CRgh4HY3VyaGcjk2GkNDqpxJjabLnWVYoJP2eDzoNnEc5/P5ZrNm Q5mASwsjWTmKIooi4mBEwMgbRgRM+PyCx2sU8l7LrGpqnlGtK4arWLPuvQVV3nHqpf3HexCDJuJv vmnjO5oroqTdaUnWG2L9E8/XQLmj895f9SOjtihpIiTYWMXW5XWLOKqdxnxr5qXuocKGzZs/ex3n j0wp4cJC30PTTCG/aPnm0hzXLh7IJcirWmU0WpOYl9PYZRB2ILo2Fs00NR1NJfPZrONKOjRG0aPL gktyMtgrCNUVFalsLnu6HTnBeFkzoiCBx1PCPE9bFvFqHryv7SAaidS6mqFNazT6rN2AbmJBZlXx PL8dvYWN63s+/VcnNi0NP/Iy3i9SbTQ1a0G/Hg4p4aDiCw9ubJqJc3Tx3OKqyv2nNa66ppjLmqJ4 /umg83bYV5blsSm/sRUo5RD0awVjIs9OIBr1BuT+IibWKTrUssTUNLmvd9WGK33Bmc74BRTJQpJ2 VFNJNtLQdPuS8YlOANn2+GnTTOW8Yy1NT2n6yBufZ+vdt344jIl2xd/e8PHvPfy1jNa++/A3dh8O XXP9t24KhqbQOJmioa5uXLcWPTZTOLykoOiGSYDKigi9EAomvnaBbl9dZWK4oXHw4H7e5XJWBtNO ThYoXXUL1KS6aEVbf3948dL04YOIdAWXS/V6ddsFtKuNXRhqxe5nkMWuC7VyYHQmCFpCPk2TLjRy oF8wKq5r//e/SXncuaBPp0lgFB0n19j6zic+dbvBzLisGzJ86pB5JEldiGLjicyRQ+ffCCfyrDkl XsYJR8902wj7GpVRWnCWhzorRHGHAKR3yXL0qdjZUZeI1zW3zLTYbH744J+2f/2JE89DNpbwhi2t 9/DRf93d02Wc9zym+0/I5x5NVVVcuab52oQ3hjp6Xnzuvx/45uGBHlUtqJ4VH3zXfe+/6hNNgRqS SG9/4h+OFC5Z3FgzLQMSAYYORiJTPsHSARoXIkG/e3YWkpUxk4j4/VU1NYTLLebzhXwe/VssiMiI xmRWelXwxqMpkaDskkGqLCv4T9FUzRjj4AtVL+AGttxEELqrZ2/imVcCXV2h3S9c8Y1PX3/jzdv+ 6XvBJB4bLMqbrq5KVgQQ+zrHQCeMZugAEgBCElqkaVLmzNZIWF5b6+Z5LhDkQmHTdnImxGTSCzOH sgdcchjTS8O9gaLZiI8WhHx3Fy2LS6+4kZ5pt8/KPfvsd3YOd7JC4xXL370taj7w7Pfb0gee3n1f 0P3BhmDAIX9ciZc4dy0RfoaAK5q4/fYNy1O9+1869ej+EzuSqcce2klfVxPe3XWc8yQqg36eEyi8 syRriIAvzfMT0VhmGK2LW0rQn7hUIEtbNYzG4IKq2fxaRl00ehL5WCeO2fOpDM3i+VQKB6LxZDBR qkEO5ATvYTnG43FkolQsyoY4WB3JVxoV9prwiUuvfUN26dOBo8frv/3lyuoofeQIZZrQGyo0N2vc 8MhOZ3MZtL0+sm13w/3AIi1gEaRpkASZvum2wehMCQqRJAh43Go0phXySiaNxpCzmnTBaigzijIB lyLGOgTl8fKxBMkwha7O6266MTwbas8w4ov+1fr39mS5rYtXbVmySFXSf9z5Hyvqq3weD2qTi2Ur /JVejmVJ4tNvv83pQFXhcK6YpUgi6HG/beNaCGC05srPXHntfY9855m9961qrKkU1D+md7tk/5qm tz+x5wQ65B/f/U3AXZoxgWxySdcDAi6vPQMnPqtA93cwk/UKAs+VekHZMi4SHoEPRKN9+/fSo/Op PC7SgDUuKLpE2ddBXXVVrr83f7pNGdF4lXhBQKdA0iO1JSZbj6RFWg994pOLfnJfxc4DXGYQfaKv u7bvhuu6tmxkTj5AADSaxPVxJAMpVqlqUMIEf/S5xUefG/9VyZatM0jAADTG48htKIYjyJ/RCoUZ +qFLRZmASxoAWc0UhWzqWDTavGz5bFRZIf1X17x90yunD77nfVXhQM3rb7jlsQebWjave+h5epn1 PEVtJAnuxz8vvvOTN97wiTXv/1TqwYc7hoZa7/+1vm1b6rqvfyBYXfPAA4fe+76Iz1vz1re+7w/3 r25986bHnmWuvYm6tfV18aboj35R9a4fIV9h20c/9/C3vnNJTZN1XdG0RYkEWarOxCVhKJdb2VA/ 160oY9qAWKoiFAQsi3M3EPu6XG6PR3C7cUrtq06nzilqKioO0bSuabjWtq3XaNd3wh6wXWaRhJPm coNs6zX7P7fMM5BkdMPkBLkipoT8OnL7XW/c/Z0VRrghP36eE9CZ1dcf+pzQsONZ/8kBAHmLJKCP N6KN/fUzOKmEWo48YDQoDfkDoeUrBl58YeZ+65JQJuASBqIZhsaJxUMD7/zbj1GzVGUPKIvXnDrV t+nRh4g//vHP9/zwlhvfVP2xjx0W9fjHPvaGJ5/Ib9hw+I53bnpyJ9r66D995aYrVke/+MXDw8n4 xz5++5NPFJctO/L+D6z585/w1i/9003rNr3x3/4NH/upf3ifvfXwJz559+Fe4l/+Ax17Sc1Cz7+k qjRJeb2eBRB/VjW9qGrcXOeRARWQEmGGSpoeLh7AAEAkLB+cq+QWnuEEj6cwOKiqOIrrLGhxak2q sn46a2Vli2TI2ggbc13USgZ0qGpAmibZmbQ5kZ9L8zxB0wquzoB6JcsiAsYC0awjEH2BZReQpJSK SvR3zueGKzy4eoJlRaYQ6N/yRvQ3zefwakCDRk1FZCibM5WwKxYrDg7OcgMmRJmASxeQF4A/BA19 7darZlluovuNb2J/+YvU3e9Br7d/7vNVjz7a/sEPtd/xzi3XXPP8z36BPnS26h7v49/7ft3vf39m 6wN/PGdr0y9+0f7xT4zfemR06yU1CVcZy+ajAb973ipvjAEZE6IiBz2uWbYkwBBgtwNivaU22u9V wH+DpE8Q+mcspfUMB9M7SP4nAMQIKw7xCOHktLMEdOE/KwH1zdAqgZEDFACzEwA/1NZCSOMV4szv APcgsO62pOvPnA7ZTrq+BECQsGoQQ0LCsGclKQK67TMKQu1aaE2TIQRJQhDcaV03NLu4JGZfy86r tP7roPhkcbRVx4vXVAp3NbOP78k9VCQWC2SIwRKWOlaAJVgKeBnAkqA+wrX1Sr9KObmKYFuIubqW Xxyg0dbp7Tc8x1bXN+R6esS+3iItYlVkQcAZ0YKAXmADYkHEnGiK4pE9wQuxtVeefvjPc90cjBJ4 jMqYBDrNQF0jC/nmzZtn/9fb7rzLeSHW1h3/4Iec18/f88NztiqRigtvPfzxT0y29ZIAIZ7I8bpc sxUJmFkMpjMVgVktIAGSgPsFYPYC4iCpf8WyACIwAmh4EzlAEK3j9hwGALFUL0H2TjDOwyCwlpvW nFe/RHT7MGAfBKACGC2mGULnAkgRNxj0nbUjGCIAIr40QaaJiVYQAKLVVKZL2MaCjMc9kkKJs2qd 0iFQV62Tdp5vg5f2Qni6aG7vKw6pZlAmChbcJU28HCCchq2G6bQRPQDPprWXc8amOPeuJiHOTScF MxQV8HjQC+S408gP5nk7HVrWR2pUYxtiGn9uDlEVCRc1dUA+b/XGHGEhjGULEgWLkN0eM5dvrKjw 2M/GaxloCEvm82gkEzh2AcSfsUcErURoKsugpwiFYHaQ9GH7dScgi4Tltof1ia6lscVSIgTmYA2w v8VkbC2H+hUQqLjKM3RBswQKP1KHSPZJuysME1SeQAQ82emgxisfhAD58TqgnwZUD0FEoPZGCDW7 YhEFjekzJlDnZGl6bCULLmpydlrtzY3uNTxxcEC+t1c7nFL/usl9BUuYkEgNK79OmW6GvKaSr2QJ zYQk/ipwsl0jSPIdTXyMIjqH1GfT5tO9SsoCX2wVRnTUkUtvoe6ETx2HiqfacsoOMiO61eyquU5p atMwoWkSoyczGzkoM4yI39efTgMcchcMZe5puEzAJYoi6vCG6daUeCLBzPVM4ZwDPf95qeh3u3wL xhaBM15qdDyodpL9y4i/i0APAKNpUp8GxqEet1eVWQS9A1D9hFUL9esgYWcSQXCpa8emHyAL+B8D MDp+0n1Aq5/8dLxQ3+YUnyJAN0H1Aegl9GuRmwqdGwCnbxRET60iisS5S29sTQr7BceSER+5WqZ/ 269nCBgKslcFMPPlWBMRMEeDtXFulceWgASEVDROtePKDldEuGVuUKxgFvUovzytHhxUe5cINcA6 3if/ecDoMxyOB6sr+Hc1ccKUupXTG3GxbRPRrmGO6FGYllOIewGBtGWug0uXpw7tt3T91Q+Y0cbM 7c+XMSFQp8fRMkOvCAcj8bJI4YgXwVA0syDiz7MOwP87ABIBkasn4PfUkYs4CI0NNLR8ONgLMthZ RESFuWqu2RefzrdJMkMQyIm3F1FTBy/mIOzs4nlfkgCDgNSx9zFyRtOHQlHODA+d/7msQEdqQlSs Uz3Fb5yQezTUpckGr7POlnDxmP8UA/YWLAoRBAXsmkT2wSRg7DpLLpYKMraPa+Gs6oGM8q/HlBey RododuI/o0821Clzpb3Qd8Rzx/Ib9m+M+L5T/c6SxJLqKo8guCIVXAkUES8PZ6WII5mcRgCBpqOx eNn9RRCLcloU45eowTnlmJmqW4MqDAmkh5r4eMdBAePeQicCenE/N6uL/VWC+wVJSgThJ/SbIfU8 oJBTtR+QbzzTCDh5VUhYaiuuDYJ5EjvlyD4wN2OZJvSW2AMoE57RUpr8iUEEPHNOB3IYddMc6uzg eOGcTaqOp4LRix8exPVLaAAqeOrWFm/t6ABMUaTHkbI5H4b5XI/SZln7M/oLEt4lwtMRhhhUTLsW Cnh7s+vGMLnjlEJ66alODeNVRgwv4PXK41UppvZlpQ2KolbW1+1IJUthYrtMwCUH1Csk3UDGaAUF IpWJuW7O3MNegKSg0S3knXTuMS/quwqw1kc3uvFcFrqGXSn1uApWRJg4dzYt4gxkSzYhTZEuFq/u OGfIQqb/7rbC9/qsu1d4r6/ARUqHC/rBIlwWZGL2V5kGbEtrHQbYHGMQQ1smbM9oJ4vIcSEZiqjh qSovJdCvMhDOklth4alf9mn7dY5g7weELQEE8oDKEQYcGWLh5ClIZj1B7CyZkRgS1GHA/gUAW4Oc ehqMJOcWAT1IaMGRdlq1k36BFScIxt5tBs4omc8XcznTnCCjarQ3gJVhxksSQY7amuCWBs4EEygX tYYgXiGICRYMQ+sPXWdmK+t8zPsWu3yIl73serexR7LubysO5rg1lfzqMDO1+DP6DdRsd0WUdbuh qr367vMcDE0BkqJKQAOnTMAlh95crqBq6NEMh0KCe6FMeV4GnLAYS9MV/kmEcqD1xFHx3jx8XY3w nkYhQONckt8flZ7WwF1LPLdVMszoqJTPaw8O6IOSKdlrKz0ceWWMvzJ8VlBVV7TH+w3JIh3xBMM0 Hz4q/l6Edyz23F7FsoBIi9qvj0m7dOAS/FuDQJKNv5yQHpPwziQBGtzU4hBzTRXX7KUu5GvZ4b2Z ngYGA4DZbv+En7AaIHThRCTqFQLIBNkBgI8Aqt0W9syoD/4fe+8BIMdVpQtXDl2dJydNUk6WLMmy HHECg7GNccQ4EJZgll3S8oBl2WUJb/9/SbuENWBYkg3YgDE4Z5xkWznOaKImd85dOdx3b1VPayTN 2JI8M90j9efxqKdudfWt6qr73XPuOd8xMXCckxnX7T1LPVrYeUcEEcUwFrOWIn8yBHEIx9MYtRfX zsMwR+BoyumgdV/iOLYFGHIJzGo6GzRwI8l0345tb3wGt60QFpE4Q+PT+lZ0C4uqSHz5mDtniQvv m0xhoomC7yXgYe5Yga+M6Qfj2osxZXtKu7rddd0i1nVKJj6cPrIkQWKY8eb7LnjAKwjZ11VbJyfi pqqWsCelfqQqOA7DybSk600EFmysFIgtwHGKzSSAZYraQ2nkmhvOmAnF8rsJOae9riAzpztpXFlH IzkTDIxH1d8PylvzqJxDEXuSYO0F7qlD8ciocsDAWnxUpxt9Xi6nPp1FB++Km0odnAdgkbx+AC21 ge0x44IAY5jQQLePSCDreUA0hiRzb8r8xGphtecNxkJc1XVuTtcXAEZtwwlbb8B4n6Uug4M3wAzc tZ3Acxi5F7fOKgy3uIQTMYwcx8genBjAQCtQbgVgCkPgBuLgkoMYwsg96IV5taWcZ58OwJmf4nQa w58jqDVWISxLwYkMRoQwshcn+hABK5+yrKlfBcBwBZ9dKziaTifisfGeHqfirF3THnd0HKdOswSa 4GcedA0L5MzjbGCSvGmJy4VbrwzKj2Wt/rR290Hr1mWeFbjWn8WWVzEbqil5Z36vYe1N6ufXM23c qczqUPw2kttY8HHOJwKeY2sCflOtR3nP0VIqclQIuOxgWFYVy9RRhLDwFY9nB3YupZ3LOT1icc1e DMMO580JFXS4sdEJzRmKY5JlF3HCsxnjT/3Si9BOJYn3N7AbamhJNsZzZn0tf5QhpGm/GzE0DF/u o1sFNGZHoppjVu3PGBkTcxPYREx3qjCGJqs54XYKyP+/ybOYtl4fkH4zro/ntS/vxR+4wF1wcgFU x0k3kSg8Y9vjAsv0jI6d1dkxmxfqGMg4GcFR5HM9UM8vLpEC7V0Y+xgGGZewbH8s/PUNYuoqMMhj hA5Me25QDrxbALx6EaTbhQWAehGwCjUsgHEeoAZsIziFY3ZZKfInhHD0W0kNs5yv2ZgT57NuGNF0 ZtdTT8A7laQYkqYoGk77KIKAZEyiMKtJYpux6I+FOTfV1JgngE4aAne7qJVuYlWQ3Twk/nRQHReN 7+wVb3fpv8kddTJeCvfTp+qDRo4k63QLuJoBDEUta25KJFMlF7WtEHB5AQX+A4vAMU9dJfi5ADv3 BeAzzs3BYGJyWDPMlIZ0e56NFKhxRDSSJghgeFIxRmwv8dWd7gurCXjf+11MRz3hmjpgAbC9V96J YXUCdUG9Y5yCvvjkwTUjqoNawtyeLGzpyepZcCTcBh6dYqnzV7gFXvpxvxqS9XEdqzeM5wbEhyJG rPAm/NIW14cW00GPOxkKz8blmRkkZlUDqxkzPnlUSTntWovaR4BazCIBgNYSh2x3FAzMYIBBkc/G DUeUocz1wNqBmUuBWfLZII4iwqwWzHynHZs9CeMcYG7FCAkzeQDJzgnzRkJXDPJUAwqYlwBjcpJl LQZmO4YzmN4wa0wDn9nRWGy466CWz0PiZRgWKSnbNe2RlKNNwwxH7L04cEWXVcMQK1kGTgMGVE3g uA2W8Zr93ZzLMfsXYZqk3dXqXckTTuu5QH2+Sp8wyPe4mLCLERXlptXV5/jlLw/kVrYE/rkWbN+T g7PT36z1fvSQglnaF5cHljLG4CmW9sNTyYQiy7Yf+vQHCoqnSKLUWRUVAi4jWJY1kkjGsjkcJ4RK lbopeIPBEhjGDgkU2BmAUclKxfVni0OQaYY0rJPHOJrwQLJRwMO92d2HcTeBsxTe6KM7qplL6mjH /oPjz+/jJoHja6rYlT473UPXXztycKsvbzVn5W3FgxvmhIbVTf6VV62EZUVkc2fGlNAGnMPBUFL5 bcgQMXxVEEWuDsQNCofGKM7SlKwioWBy7ubgLNDeA/R3Y+CYWBMXkP/NQnGvNAZIQI4gOxh4AKiB hI1ZvqOcz9YiSzw50e45A4EZGy3zLDtme6o/mQXKpzHcAJYLI99tgSU4DpBaCDoXOMnwg6mJRqAW yF+cZSMvlcsPDR4e2LNbVRVUAonneUFwud0ul8DbNYXgV+yqYuI/vXvXRRf2sBtq77+fYGjsuvcu 27k98swzZ9vCcOJ99/7z5Ze/Z8uG1oceRAedbP3Gze83KJL+0Y+XXX55z9kbmv/8YKOm//rGm1fu 2Rn54zPP3HSrQVLc//5w18UX7Vu/ofOhB/cHqrDNm0/2FFCOtGWKuZyu6yR7RhAwSq8mSOLUlUtm BxUCLiOIqrrn8FBGlJZVB0s+NSs3zGQBZ1P6HhNAy6cKx3Mm2BtTqRgyf4M0IZBgVAH9afMCH1Hj pa9f5lqaNEI5U7WQwP2IbO0VFSymU6T30mpCV4zHRtURA7Au5j1thbXZVEzdAy1DHPPjeMoEL48r WQ2tmjayhAFAVLMOpcw6x+QyzT8PSm7LmpCH1xz+AAAgAElEQVStUR05vc9vYKtILDXp1GMp8rJa 6m1BlvdQPI6ZOJwQsLF0pr5qLvWwyGkiqjAkM14gIWONZayZw8+fZRDHTSZsABY42802YM6syDEX yMty/9BQ1/bXU9EoTdOQf12CS/B43B6P4HZzLheqqkuhnN6ej37MeOD+zr17dy1bTmj6ul/870Gc GLv9jtVPPAGPc+D2O5qffBK27mnvhH9ObYUDwZ4prRZDn/2rI63wRt373usbn39uqd0aO3n2xVCW lJ7MZi3TKIfMnPkCmKnI8XyiMsqXEXTDzMpKZ3VVc80cVuZaoJjhQQF9cVMzgIsi3lHHvDam9OX1 ZxH94Yuq2GZcHw0Zf4vqd7bSJEWsruWWBS1RAwZA0VLxnPaLw0qvZD4wql5UxR2KqFtTpgbwu5YJ zYVsSmvvBOLyKo68xEM+G9FG02oU6fgTK2oZSdKjCfOZiH5Rmz2JBuBgurheil/Ryt/UyrE43hpk r6k2Hombu2JqKKcvCdA3VDHQCAYE0ej3RdPpuSXgCuYYQ5HIoR3bY0OH4UhOURQLDWBUhBASsBfS MMfzqBgwSTrVhAZvviXZ3Z1esQK+3u71Oi8OXvF2+FvzB2ZqxU3z2FaOn9qq1NZObT0FGIaZT6ct SZydi7IwgDuBcqXtREUJq8wAgI/jaP7YRP4zHPgMM3NLNZ4VzTzAWJI6t55u5pA3TYU2K4G9YxG3 hifhRCaV0QZk7XsvJL91UEpbuN9FVgtkrYeqoQjKdiZndSDJ5qthFbLthgbhimDhoTQl/Q8S2sPL 0ufW0UG6cPA6nrioiTubJeCnxVNqZNIj7WgK2gAvjKk7koi83S76xrW+b21wv89HhGTz5ZD64LCS tVDQKc+yqqJGUqm5vXYVzCVykjLa12saBhrO7RVgjuN4weVyu3mXi+M52i7nVyxoX+TI4gu1qgr+ HLNxaivk15NqPQWYlinn82Imc8pHWIBA4W6o0mJJjeCKBVwuAABohmEBYGCng+j57ALMcEEMHWgm 4ub2INMgEPV+igyj8jFuml7jJbIiUUVjcd18fkR9XQPyhKxq1tsbaFMze6P6y2kjatvKV9Qx4bS6 PQs4irypky4maOqqpdslmNp8dJMXD7oIPIPIto6jl7hJn4tgCUyyzH1JO2+Epq9d4f40Yz3bJ/0x biQ08ycHMlHFu5FQX0tjbUF6XQffsyu/C4CEauUMzI3CY0kfzyYz2Wqvdw5XgiuYS7TV13kgg+Zz OBIZxslCFBacXLGopj3NTGXfssXB4VFDkfPZbKk7Mp9A/mfeJbxBqeN5QMUCLhcYpvl6b18yL2pv kKtwpgKfIT1CUawLmoJuhuzwUtDk2FznrUN3NP7JTc0eHKtyk1cvr4atB/LE7c3Cujrv9rj6zf35 Ydr/YMqIYtglbVWXtblvaCLiSayxznt+E7eIIZomzRGfx49IEscWB7nqat8mF8nj2O1rG7c0sAKO rWwN8gxlWtioQi6q98EJlI5hixrqrljh+eJS/s6lVUGe3hbWRI2IUNwPDuW/sCu/5qwmniJW+qhq BqWIotgchpFlOZ0Xz6Clt9MLOAa81c6CERrQIddCxiUpW7UcvaDQHVQGa41vAMOyFEXhTWNaDa/T F8AyLVYQiJIScMUCLhfohrmzb0AzdJqiwYxLnmcowAz6yZxAfXbfc2vOfafF6mvyuRXJiYllbYG6 6s8/cs/+j35M9qjveu7ZFZsueiSa/0qNNnp44kedrauaqz/z8M+Wv+uDGUW56+BLxLvffjCdvaGO vjYy2r1kxdrmqmU//AH98btysnzW88/93w0X/nYg9WGf2b53T2rJ8vaV/k/85Z7XP3IXpslrtm79 5oZNd++P/WM93jHSV3PW2i1twXX3/A98b7VP+tCrWy9ZfdYAsO5wGdd39X1/6fL2Wv+//uXus278 hM9I8UiyAw3WHLSWABgLR1wcNJoqot8LDwE47/MUkqJs/i2CdP7CsXkte3UK6B0bF3O54e4uVBUC J5x5BHqB6kSUe+ffCgxgYV4fTlKYVbKZR4WAywWodCiOddTUNFcFzNP3pj9F4NMTMMNT/a2Lbv3O l6T/+m/w1e9q/sDnrwr4v//dHRdcsO6nPzE6OkbC4Vuf+NLld9/Df+nzTf7At9/pr/rB93ZdcMEX /vhDdfWa8VSk/XOf9d3zM+o7n8rU1q5aFBQ+980d51+w/jvf1s49d3QidOtjX7roBz+t+cJnkk1N l9TUCj/6T9i66b9Qa6i399Y/P7jlez9p/PJnYeu/13ld3/z+jnXrnfeGevuufeQR9X/upj71KdDU 9J9b3L5f/njr5s1//7vvH/rcPw1FogVriSR4igylUoeG8fVLF8//da3gLYJFiUdHSbngRUz+XYp+ nSg0wxiJxbFsJhGLO9JdyHyHoJHtjsx3YvJUyvtETgUAA/C7g3Ok0rkcKwRcRoAzUIqEoEyr4oQ+ GsCh4GnEk3Odnc999p/e9q53Pf/TewBJbvzG117+wIey7e0Hnn/Ou3PXwB13Hr70ssu3bHr63t86 ra/YrXswLLh7snXTxmfu/a1lt+6yW3djWO3jTwzc9QnUeuE5qJUiN379qNaej9/V944rL79ks9O6 7jvf2X/Vu5OrVx9p1fXCke3W7bB1zZrdulb97/+OffyuyUEaOaJZ04hNjB9g6BUtzZXF4AUHmpmh mNRCYKz+8RABjeDtr+O21CuFMqk4lmXhtMLW8qJI25Q/Le1gmiIDJDmGKm2WDPi8VkarYGbkJenr v/tDY9C/uLGxQr9TYZrmeDQ2GI2et3IFQ89cOW+hQdd1KZ/PpFPxSCQyMaEK3kXtbWs6OuC4UOqu VXASeOSpp1/765+hJez2egNVVfVNTbUNDdW1db5AgHe5IKWVbRBWJJXuGhlR4rFXHvwTZF/IuJyL d3u8/mCwqra2uqY2UF3t9ftdgsuJJivPszg1JHO5nX0DzR7hxQd+r6uqx+Opra1taWlpa2trb2+v r68PwK+P520hszlcJK4EYZULnJo/JqhEYE0DkiQ03RiJxkrdkdlGYZUNITPQO7B/38HBwbwsV6bF CwjQUFyIzGRaVloUCQC6Xt0K70ESEjDDcDxKoIIzCbfbwwsCy3FwAoHjxIKw5k8WyAPN85UgrAoQ KiPuG8DNcQJLq/rpVqkUnxJtB1+Ee3vSiURyzdrOjo46v48rg3qlFbwpoJHEMMyCmzIlslloAUf7 +9KRCD5JwNDmc0NjEBKwz+tyCHgykLvU/Z194BhuGkZpJ7sVAi4bFO6DhfYczwtoODoQlHWKKvNl DFQo58jQZhlGbHAgMT6a2HRu+9Kl6zo7qMqScNnDAgDSFzAWUg6PpuujsTiuKuH+XtM0aJp2XNCQ caENjISsBbct44WKSZBln0l1isCxdCIOObiEXai4oMsJOFbJPzoezhWBg0BGUSSllNWz5wHAMqV0 GtrBuKZV2HdBwDBNvaRF3U8B+4dHYulM//59sYmQnW9EULaEiK3jxXMuF/wXCYlQtLP0exqyLwrr xFKxuFEh4AocWBaoLP5NAztjp8nvN3Q9I54RcrXpiXFNUUrdi1mCgeFTlg5wGSMP40T66H0sDE9g RBLDsxiet39y9m8R7Y+rZe0YggS1sCQsTMtK5nJ0Nj3R3WWZJuRfm31pu4giMoFZlqNt25eYZN/T kYCRFGUqXmILuOKCLh/gZLlGS5YctrABiQNU+bzUfZkPwMm5fHoo48sY/TxB6UC9HFgCIlpyO8Hf g1vvANItVrFQIDFKuL6O4wwGGjDAA1SG3hGj4THAYcCL6ZdbRlkWKIEzZnlBeWXgJH8wFJZz+eHt 22RRJFCuL8Ug4Uy+aPsyLOPYvsRpyr7wWxMVFf6WxLxV0pzPCgGXD4AFrIoFfDycIYCmSIYiM5Kk G+Zpn6hj6kZOPh0sYPopgv0jjrtxY5VlLUYh/tC0xVDx96ONWsn+M2cbvtOuwqzEypOA4Q0JFo75 mxHFcCoNCTjcfSA8MmJPa0lIt5B6XYIguN3wfx6VUGSL2VOnH/tCKLo+EApZuo6V+rurEHAZwb7X T8Pb/S3CEY2CU/KgIMRyeVlVaEoodafmFmIinoMj+3TCIwsI5D6Cfdg+gTyGfM4O4053QlaHJf8f HFeRs5raSlDbMcwPlA8DTMVxAx4IGO3z2vMTh6yqYIEE55uWNRqLww5HDu4bPbAf6V4h5Q0GVW/y eDw+n9fvd3u9nOBiOc6pIYGdpgSsarqsapxhAEkqbU8qBFxGMC0wQ9GBMx52mgTP0mpazyuKVzjN Cdg0dF1V4qlUTXChVgvGMzj/U8SpDqgIplkz39wsZi6zG+GvBCD34TiNmWeBI+8oVxZI5cV0IlHq XpwQUvl8PJvLHR4Y2rMHWICgSJqhOY5zud0erxeyr9eHCNjlEhjGlt04nVfEAA1PMK/K+Vxp+1EJ wiof4I7Tp9TdKEc4rjCBYX0sm8rmrDPAUR/u7uobGS11L04VOs7eQ+BZDHND6xZtILpw7ES8fTgG WAytDcdwQp1MlC7jZyInShM9h2xj0obNW4VK72XWbWjzqdnMoV274OyOhOxL0SzH824Bkq7H6yuw rxvl/tIMQ5GkU1Oi1L2eE+RltAAs5/NqqUMdT8/ruzABDKuyBjw9bNVkNCPnSGIsGsvkT4sApTdE LhZNJpOqrpe6IycPHaNexanDttRQGzDOsm/pHoyaOtZxM7wXvsmFYQukLpRuGIosy5LkqCgXAf8q Q/lJ2Jt4KKRIol0KEwVe8dDadSPZDW8Asa/gdnMcD7ef3uZvWhS7RkYs+N2VQUpFhYDLCE7tslL3 ohzh1C2AP26aYggcPj+l7tF8YKT74MSCU98EGDmMs0/guF3cHe/CmcftW1rFyQmUeelIrYIaMNPY A3wY4O33lv1cNJxKifEYsiYZhp3MoC1YkGgNlSwrC9LFsQ3tHYzgRrFXNAX76RIEr730Cy1gtwcp b7As6yhvlOEEYrYwHotrhlHj4tVMptR9qRBwOQEawGWd8Fhy2DzMmmYqm8vLcql7M+eIDR3u7e3N lTpO5OSgYeQOghhFy7rWRmC8Df1YraiF2o3jJkbE0LCOnMzF4d2anmuJdLkTgCgrQ3t2U8iXi7y5 toCUAK1KR0K5GMRUJkzmcbmCXg9uu5Zt/zMkYLT86/H5BMi+9tSBsiWxyqfPcwELAHgFfBSZDIdL 3ZcKAZcRcOr0nXXOCnCnYqOdrNW9cNdHTxiaJPUdPDAcjhilTpY4ceBZnH4WvTCvsuQPWcr7LOV6 S1+DCBZ/FqdyGG47onEVx9M43YVzfyKEr5HClwnyOHcgXt7BxfAuzOTzsdAEZSs4CnYNA4+9jMrx HCofBO3IcnqcUVdscrWL/jouaDhpEAQ3pGaBQ4Y77QQ/l5XhPrsYjcXTedEyzb59exS59FPbShR0 +QCtAVcs4DeAMzGn4ECSTidpOidKHsFV6k69VeBHfjmDtZOLVgjhifT37nq9qj4YqPL5FsTkjIji BKTYKqCdDSxPYSOKZ34dJ2IYFcMtO4CdeAgXHppyOhxOaJhZiG23NTgIDJR3snc4mYqPjaIMdZpG 8lG2NWnHMaGVVHslmCyrNB7HvYYMXAKHcwMalf5F+huo+i/nzBjKcel6dhFNpzOSZKpq/969pe4L wmk701mIsCfMp/PdP1sgpLyYSh4cGZHV8raS3gxOMUKkRkTZQTwMAvxNo3LoDBoTMTw6OPDazt3J XH5BBOgBH2asA/pVwGo4stFcDPRNwFwDDB/SwwIBDPNhoAoDLZi1HJhw/xstwzt5hAbM3ACMLZbe WL7na1lWOp/v37UDkZmtoszyHDIokSnJ0yxK4yk3Xy4cXWCf/E3NOPKN2xocsJdIhZIuqE6evsob DvKyLKkazzDa0KBVHl6ligVcRrDKd8CZBqahWQB39Orm+7MBkEaHQyRZ6/e319ct0CEDt0shwVHP qWeHCtHwPBwX4CWFv4t0a0nSyIF9gse9etnSGp+vtH1+U1hNlvKP2LH2K4VpNyLdIcBj+KUW1mLL a7DA8iMytjwA0Ef2BV6g3lTuT0JalJKRsJIXHY+uzWLoO6Tt+RP8i5x09pa6p0dAEkTQ427oXBI7 1O0wLVFINUIJBoQd5bhAH6UTgWlZoWQqK0msKo8d6ip1dwqoEHD5ACfRM4CcEqWuumdlE12vHXw+ a3lrhBpoi1nAsoCJ4RTLuF007/JU+6nsK12PRMUctN1cbPvS1vNXtLSz86gQaSpKanjocCDg5rma BeKePQa4bZSg1ThIvrYLE9pVJE0bug4J+EiuMwCWrh3evRM2UUsWB9zukvb6zYBjU9n0CCjMUX4G AaCfU+78+sYwTDOVz4/09qqSVCBaZExO/pCk7eYtR18uxyKZZ+c17kwACbygwHd0ZczTDHA6G0om I+m0h+OGd7xWPs6kCgGXD9AaMA7KgICBEYsd2NPzaAoQFEE544gt0WXP6eEPvaSTIcdyO5J2DVQC 33Zw6JFnq6+67bL31/HTjr5z0EcAlHQ6MjoKH6XzVq90LcTa9fbAjYqw2lXQIftCM8rlEgzDQALx RQsYANM0dE0bP7APbl+zdEmVx/PGB65gTiGrWnh8PDUxbpomzdCTGhyk49QlihrKZclncMI3zday 7OosAj5Ew9FYKi/SspSJlVFqX4WAywfoIegan8ApqrW2Zv6eXns2OPXjAIa7XPVVnjpRRkXjTEPW LYsgGJqkcRxaZiYggElC6oU2McPxDKZDfshGx+/97q/HP3H7F1pd1JRDof/m6Fy0XHZk+2vws3ex 7HmrVpRVxOkJAg7YSA6Q54DlhcM373LpumYaJphSlgO+NAxdURQpn490dymyfPaqVTX+BWn0nwaA X0wkmRzp64uMjTmrqMjnbC+jUmgZtUx51wG0z1mKPgPFBnTDkFQtwPNjB/aWVaHPCgGXC+C0eVFN dX8oPL86i9rY0NawQjc2rqrz+kkcM5TowYFtEll/3bX3eGnLAtael/7tT3272xa/7z0brhVIE5pn FMOMdf3iL3swjL3tS7e9z8oM7zrw4Na+55Pa8/c9veYz11zDmlIqG8rIWdVQgIUTVKCxts07B0aq oWoTB/Yzbm+3x93ZUM8xC0RCyUahyATNAB4QBMkwjAbZ1zQtE5q/R5wg0OrVNE2WZTi+Z1KpSPfB F1LJdevW11cFOZalyVlz+8NBijytU1BmBRlRHDx8ODLQj747VMCeL9SuZ1EFIYqk7BCncmU4APBy dI3PLTTD2Dt4WNN1MxbNhENY2fifsQoBlw8Yirpqw/r7X946r/cHyL7yzDd2Aa6m9l1Xn3dTAxl5 cfevXhrY5a25wFO1PFiDlhur69qwvt3QCsZIzi04DGdSzjNsL4C5/G3nb74tHe97JdJn5Xvymjw8 9Phzu/88kolM1pZov+5dXz6npW0uhnYxER/ZuZ3leV03ljQ3CtzMIodlBjiCQzMXrQGjUhMUqgpn wgkPCr+aegtYpqlpKpPPA/hCUfK5XHj/vhfCkdqmxo7lKxprqv1u96xY/4lcniTwaq/3jBuhTxhp UTw0Mho+1J2KRZ0qfrwgCB6P4Ha7XC5HxLHogC51Z6eBMVn8FtieLwQLTEWJ+zcHMEzz0OhYNJP1 0nQqGhZzJa6+cAwqBFwuKDy08D/LRBw8Pw8w7rv4is+kn/veYPSpR17sd+PZwfgQw1avX/yuNj/v 7EJSyHKVJFk3jgvcN2IjoUEzfbg3vKM7PYGyDPFaxoz3jr42kgkDbNWVF16FZ7q2909Ay2DuTiIz Pjbw2ivkBRfB2f3SpkZ+4awHO0ZwIZLWoqYdBKFNTKmUZQFWkmhbKRDeGrGB3tjQ4Ehfb+uKlS3t HbXBQNDjeSsOADgyww8ai6XgcciyJI+SQ9a04UhUjYaHurvQ2gHNcC4e6W9AAvZ4eJfAskhJCi9n GxOtNhEAxfVZ9jduGIYOf6Ef04Q3oVXGq9enBrRgn0y5OS5gGQcHB0rdnWNRIeByweSNj0uyYlom NU+eQLq+7cqrLjXue/IH0cS+KNqy6qrL/ml9Q2MxpNnlXRTEZqhkoz75u6deAKamGooJ4C7rrrz4 ag9l0CSHo4d9YEf3wKXrrv7wmio375m784GklRwe6lZVeeM5LpZtr6+jZs8xO6dwjOBC3V/Y5+lM EBOlJFmF/GCahkM8SaEVR0VR4kOHU2NjBzh28YZz6js6qny+Wr8v4HaTJ3P6oqqmc7mJRAqa16lM ZsLrbqmvn71TPH0QTqb1TPrlxx6FpMXaRQt4DhKwB+lvQAIWXI6Qcrml/x4POHWA7GvougahFv63 xavtqcPsxW+z6VDDSIjNyYD3xhcvTnl5eH8zuURD32Eat9z9fUIkTGZVwHmVpWvHzt0Qqp7lMqOh ZKpnbEw1jI7amr1PPa6Un6prhYDLBUjjiSIZiuqJxnw+X3NN9fx8LpwL67o6WbYV41vv2NjUTBFH nkBom8HhXDE1OGM+7t2yoummZdivOz5w078s9fvg43vp+ttzmeTBxHAq8ecHnnlk8dLbrzv3ump+ DkkRclg6NDF2cD/BcrFsdvOypeQCWcssDtYzOgBxnDQoJ9wHJZuySPZf13i4HdovyIWoan1bX+57 9RV/Q2Pb+rN5jwcygZvj4S3ktZXC4PGPOTiKJEqlJuIJHR7BtDLx6PCunaGRYfhla+++pqm2trIS PBXw6k0kkodHRl7/65+lfB5+CU7uL4MKMHC8Wziiv1H2ZQxg36CxLuYykH9RZJ8k8nkXst2dqQNB kPbdcrKngJu6Z7Rn6fMve9J5YvgQn2/Y/s+3rP7o37vyBc5bhtUlv/rN1y9b5t/21Kovf+/4saAe u2j7S98Oz14WRV6W+yYmREWFZ9S/b89wX9+sHXr2UCHgcgG84/2CcM7ijkg6M55IzA8Ba2Lo0KE/ 3rfjLwQp+DmPpCTk4S88vP8/3r5qg0AdNQRL2VhekwDmPuq5JBvftvptvaNb49mQbAz+8oGvvONt H9zUugIjg5df+o2LsgO7Dj786tAr/b1/3NW89rLFK8lZGpcmnQWTIHBnrTkxdBiOIIa2Gn7OqtZF kIQIonyHwmMw05Bnn6CdaIoSljje5dJQGhJgWA6lC09JWDLEfN9Lf6NZtqWjU/X6hgb64Jvg+xmK NjHIsxZu17vEnXgry2QsMx4ODXR1K7JcWK23rIn+vp6ly1a0tc7biZc54BUOp1KHenr2/e25XDKB OfplBI4K2ts1hViGRcpljC3lWN4EDOf3Hp5zuYVMMqEqiiyKoh1CxjhFkCbrIJ0sAVNSbNGT9y25 5yEmWTQxM/V7t8EbFKNobVG7aeS4cCz41b87L/6twVrCvtXcWkejyrMWgcEnllZUnHTPrhKRous5 Se6sr80PD7340ouzeejZQ4WAywXOQmBbTXWD3xfPZufjI4FyYMfP7j/0AmTf1tbrL+5cMdD7+5eG 9+7e818+7isXLl1O288gHN4trJCof+Stzj/cVZece+P5y9+2t/fpbYeeCsvdz77yH2Lig6S0e0Jh GmsaKW+ARQVyVEXX3uLD5YwIOIpXshX0bOUhnWEgc5AodqkQNpyHdrAsW5oKx5b2xsbGquACWhKe CQW9DruAq8eLxLDQudt6HWCqYAcAzrJeeGRY12A7Wt5D6cW21BaKpoZXxuZggAFnDdAy0TuKnnC4 feLggd7FS2sC/qDXuxAzu2YdY/F4d/eh7le3xsbHihtxm4IJm3GdBCSHvcrc+QxviLyi8IJgGDok YEnMO4rQDAdtYHsaYUtYg5M5BULLtzz2i8W//COTxNRzLk3Uc75drwhjaDkZFZ/0+ie+9H9jYKz+ sT81P/KKcP9PG2+7Eh09uKnv3z4Rrw8aJE6qWSGRoZiq2OwlMcB7OZXP0xSVGh3d87fnZ+24s40K AZcLCpUG7Cmops1TGXY4+v7gH377k+d3vWPtRRs7Fk00NygPfiBEuy9esVQxMEjAm5Yufiaxzc9g bzt304qGOmgOuFi2LuAZsIeZ/7z9RhkQgr/jpis/u7bz7Ief/OoIzl65puMPzz3YFx76yFX3/J+f fgR+yvUXvn/dijVv3fydlP2jbQ15XhME+ITTGqQWxEPOPohFFDmyf58Yi+VyuVh9g4tjW2tqfO5Z Xl6aT6Czpiloq5huD5z7wBFT8ypIr8N00oUnJTvsQCod3j1oXQ8t7Dkk7VjJcCfODhF3eBpys45W AVX4v4GoelL8EoBDr75C4diWzZshB5fwrEsOeOEGQuGeQ93dL/4tfbR6Q8Hz4ug42lYjMbmlVL09 ETg3Csfxhm5AAnZmsqguoculCAL8xzQ55zY4cSM4uP3BJb94hE24M7fc3n3ze9JBxtd1aWDMTLVp zaioBqlW14UbFmlmtPGJ13AryWj2ilV9MLyoUeIp0tRp0pfjApKLm0UDeCQWGwyFtVxudM9OVZaL zrJpd3ZKIDvWPzG/gtgVAi4vOHZmRtP6xycWNzXO8YdxZ53/2cve+3ed23bE06lVv/rV8ssvFa/5 +UVsMPC7+w988h/qfL76s8++fOe2loZ1G/7wEN0hPccL5+OA+u8fKB/5h3dc+fll19yaeuXVw+Hw mnvvXXn5Jdz1vz4vEKz6+b11H/qhz+Nbee37Fz/6+taurpteeHUfdiixctVb6ixmC8ij2FMW6TZ6 0bI1w0JD0JiqnAzsAE/ILko0HJYkyC6+6uqMKF24euUsXLFSAC/oRcMTR/QJx0zOxRsochUFZxX9 z2AqAasaHF7hL1NH+yH3wNS8JmDBt6MFQHsNUMLFovnrzGOy0Ujvnj2CP7Bx1Sq3iy/FSZce6bzY PxE6tP31/l07tGmLTxcEHAtCjuWb+3s0YC8NHcVzoOmXqqgKi24VVUVzNXhHWdaMsQjTQhxc+7X/ ZTOKctkNXbffHK9CMQeJdRck12Lurpkyj4AAACAASURBVEcwYOHAYjOJ5tF9HT+7n1QN3bc+G2SR kFvf45u/lcKj3cQYwG0poOznv/36BUvf+gmKigK/u4PDo/BJyI+O5GNxYhIOxWLHLffQSIHOhZzx kz6AKWpmc/u1Vgi4jOB82UuqqwbD0d7x8TknYHjnsd6Hf//AO6++atGHP3xQUWq/9OUbHnk4eckl +997/bo/P2g9+SRqfdfVtbDVJGu/9M/v/O19yWuvHXrv9Wc/9iJsfep737988zlnf+Yz9nv/5brf 3pe97LJ9d9y55elthdZ3vHfpv/0bfO9bZF9s0vnM2KXf3LZlhpQrVNUWbgRHeMi27uB2WZIMAgWV ULpRV+9/q1eqpMBt0UrGif2hacOu2eBMNabuBv82C9GtKuRg+K9tJSM/M5jCwPBPONqqiizm83ma niQSgrD91c74m54Y2/fKy9CGvmDDBhe3UH348GrAy8CxzIn70uHpG6Y1HI6MhcN9214b6joArDdR hl0YxDsJ+O2KuTycacEJHJy86rYbBN0nhln89k9ciqBm22NCRgKtZw2/97ZEVaE2KMAJQGJcahy3 LCIRbfvAe9owNHO0eFf8q3el+36P4gtMxf3US8BWoga2dAlk8bd+dslcfu/hw3lZgadgxmOR7oPE ZLETp9iYncV3rKMCbhcEwefzuVEpSa7IwW+9P2+KCgGXF+DN0eT3+Tk2lNVkVZ2f9csXP/+Fhuee HbrjTsis5112+dYf/xRupP/4h+Qddx7Tes6t7982pVV3u5/79ndbHn3kSOu9vz2mtf2Pfxj62Mdn oZc2ASPhRhcPhwn4IPGCC/lOTQuzjhAMfAkn+LKiiNmspOmYbestnfupzNzhyHhhJ4pQFInGScty HIVT97Ts2Qf8gYOqYTgpnraqpXXETY3ZBAyNY1mUkHAE4dQSIFSZMnQ0BmOTfCOFQ/07tsMtW9av 8wlCOS9tTgt4Z4xGY3AcbampPhHzFF49RdOSudzQ2Hh0dGS862B4ZBibLjgOP8ruxReQkrLTT1HM wXuCgJanHQjg3DN2wZWjJmonAMs92guPqtTVZJfWF2MR4EwOPqwWxsEmQAeUJU06SeidmyZuvXm4 kWnpQ8kUYPGm2EXnqAGvHgyoQb/iCSQWvdWHFM4jhiIRWdUa/P7I0ODgttfs1BIK2rWuSRRSxY5W fINbYJPX6/X7/R6PB3Kww9PzcM9XCLgcIdAUvEn7xidWt7XOw0RMbG7ut7kWYuv/3O28GLrhxuNb t33nu8e0qlVVb9x6aFbYt7gATDMcWhMlIXkUFziPWQfVVE2WRDjyWokENPR0ep7qQ8wdinodAIVL kY63+PjdCrpGpsk4AVZobLXsIK3jpbU0tjjK2BVtVbQuCDnLPMqnLYkTh7pfkqWz1p5VGwwsIKVP aAmlstmJSMQruOCsxMXzLM34BNfxe0qqKioKvFqKriXiicGeQ+lweLy3B15CGqlqOEPw0R5LJyfb NqdQ2k6xjF/ZEzGcb7E0LeVF+y972cGyw/iAfYscNU87EVhMJoliBA0KR2ErLAb04KE9Na/vxZpX iSZa6zUCm/v+83NxjlFcnAkvlCE5EV7mivN33nmTQc/a4IairnJ5+FXW+nxcPnt46yuosqe9ys3z PCRXnw1o6TLMsdli8E9IzI4RDIFEzex9sJlzE2YLFQIuR7R6hJFEMi1J0CZhmbIO65g3FLJxbM5A wo0Mg8jFYd8p9GIiAlagmQjpRJYkQFKmMU8RbXMKZz7+pnqBqBleHYeJLWva/SG1MKrqhOxidnw1 JGNVUSarMBUPZTu0oVF4eHC7rLQvXbqkdZHHNQ2HlRVgn8PJVDSVHuk6MNLbo5kmHH1dHNe8bHld bR1SqrILesGzpAh4PXFJlkwxH48n4uFQPh6LjY8ZuoFizlF1o8mQnKMJGN58aMmQ5xmOoxmaLHP9 5ylAy/+mKYl5HCvUIrR/iGJG30n606nYuZcuva+XHdjR+bN7/KvbqD07gn0HvYeGzfOu7z8fCdkC gpN8PvHIHBg4LhZc1wkACMsgLECYJoERKsOAt3AJ4b0+kUyKioqL4v6XX4CDAF7QWqehRQsJuLq6 uqqqCvIr5OMjqiM2HDc1Zwejud1uuMO8eaErBFyOcFGUB8cyihJLJZvr6krdnbJA0RM7GQs9o3Aj fHLgbyYvQhtFJQloKJeiv3OCE3GLATuniAAAm4xnPWYHOFQ5NdidKQ205ewqTChnqWANOcdBy4S6 oqqyKOZD413ZdDqbraurX9W2aC5ObVYQz2THEwlDUV5//JH4xIRiB0+hKGUMH+vtpQqmD8l5PBRJ cCynyrIsiTjSokFLobbNhMozUwXFsUJe7DHWbbGCpEtA+hsUPWW38gackmlodcJ01h3sjD6njhNZ MOUdBj7hyUR67XUjVz2z6NH+wKMP+J5j8WwWTRLrO0JXXiFSu5198Kk3IE6YLEpeIF7+3XkfegIy LmoFFvw38pXvdC1vOOVTQ1I8edFlmaN7dqXjcWdjkVkhrfr9/pqammAwCC1dh1+L73U80s4iMTSF nQXj+cnnrhBwmULAsKhuDMUTXo/HW/Zmx/zAicNCPuepD8bRBIP0bC2TomjSHhbhg63PV05XmaBI 0jPZypBvJrNooPlLwuFJ0FSnChM4tgqTrshSLpOBf6YTib2PP7po06ZkKrV4UUuN30eWjeIE6qph DEdj8VQyOdC/84W/aUe03ZBRDG8YXZbg+dh0QyuGDvsuT4o2A7tOH+VyOfnWlJMaa4N0TCVErpNn iqNAdNgEZy22AqXAclzRnVAmF2Qm2KsRkO0wwqmjyKK4X3gDMEhIhHaKGZ/UKVhs4MDnf6zU/aj9 gadx08QEQbnm73puuXqi1hPc2W+4BWP5anHKwgUgOXHZ6swyl+9wxnM4VfDt43DWSPoTb10nEowN 9EdHhot3vjNiOEYw5GBo/kIChi8cD3PxTItJZeQUVAj4jIaXwHgUpErFMxk4zV4oworzAMcOnold 7IIQ9pg56VIz7IDhUo2Mll1W41Q+27R6s5abJxq4GU2rYw5u2X8X957plJ0LWAgHJSmD0TnTZRWq MB2JwgF2GURJZOBGW7RBhHOanhdf7CXJ8Y3n1DY2Luvs8LrdPMOUSnkbdUzXFV2PJFMjo6P5eGxo z654JHLMvVFYvED1phDbQOOVKSzfOsyKOTSArqS9xsHYdhDamWVJtAxM6zhpX1rAEBaFyIJ0ktFZ F2RhAe5NHmcw2aurgCgnKRN4WfKyZBqGrTeJssk5nnfBb1AQeJfLqSQBzeLJ5ewT7bjJeXs+8sXB Oz9L6YbFcipduBmSG2548YGrLF7Qjtodzyy/ePf/978tO17zDEZwwFnwZvSwenXb6Nrmt3Z+ODTp +foGLjQhRSNHttoc7IRiIeVQeMp2KNZUAsamTFvnORW4QsDlC0ZV0preMzZe4/d7+DM0HXMmzPR4 FCw7vGCyAMNgvd5cXvR63HPdJU3Wn4yZAYHaUlUoZJFIqC/kQGeAXgPNxam7AiCqVk6DQzkuMARP 48dPr0ZH8l8fMDa1uj6ymONxTBW1p5JWo4de7y8cajymbpPAqipmiRuxSDipvpJGrkWKxJtZoiNA +5mZL5Gd11R05heVOqbCMk1aVSEhq4oKxy5UB4KCAzSpKnLXC8+HamtHe1paly5ramnxCoLfLbDz GOwGO5uRpJwki7IcnZhIhSYm+vvGh4ew6bz0BE4UdcQEjxvarfAFY3uY8SmsafMvjswl2xVpG4UM TbG70sKQSWmo1fTT+lrBqKOJAYkSAVljUG6VpkwSlyyCNBkKcCTOUISbwg4mtTEVQDsKTp86PeQi D8WWuj6IaVkZUWJM03ZdkEh/QxCgEW/70t0szzFoGnFKYl44rrOsfmzKBqEI06nf4GS+oaP76o5T PpFpAWcO7XW1kqrSHg8ejxWTx6aatlRBTp1xXNDHEPDUF/M2X68QcPkCh8NfMq4Hgqdlnc75gZFO U03NY6NjK1cun9tPAta2QflnE3prgFnkdi9icchgj3SLDyrYlka+ReCDk4+aJBnPTKhdWTOvW3Bo cDH4mir2kgbGNXWA1vQHhvQsMrqceYT1bJf4s4y1to5rFYRqGtHjXw6JT6rYOw2sxcXxBNjWJ/06 Wxh06hiiw0+fV89uqaXp6UaSgvakMzjNEFONIqLhLFDXWM6RKuQYFvks0axGN/LJJPqJhAd8/mB9 ffPiJT6fl2e5uoAfWpezemWPANqUWVFMi6Kq6WI+P9bXlwyH8slEPBxGmWl20HLRoj1ysrYT0mZf j9fn8/h8Lo+HK5YfKO6LO+qSaFXUYWG4A2Ywj01Q6eKxFH7QNLd4id0pfABgPhJj0UzPAMCAb6cI 9CdksSUM0ZvW9tvqqxSOtwrkEj99TTvfxJXUHgY2r2iqM+tyCBheE7fXK6D8V56yXe7zZvzNLmCf awP+UCo9PkUdfWorMQUOH5fDaVYIuIxhGkDTTLe3e2R0fWcHs/DTaeYflqZahjk6MjTXBGwqxmNp xFgZyRzMWItqSVPSH5fRQDCRN6KyFbTrMWby2h+7xGdyllTgSvSWfSmw1E9BQ7Z4tPCE8pqBeVhi fTUNqdzMa79NozdEcmZEsqp9hJFTX1DQwQ9nTFEHPAvyin1EuwxkRLOiUbUrbaQN4cpGelpLuBhW fWTTMcMWZBTLZGgGLRVyqAgEtJMcZWnTFm2Au6iSBH/EeGyirxcerX7xkppFrc4aW2NV0O92z8oI pxvmSDQqaRo0axRJCg/0DRw8oMqyLiu6ptmFHClHkdnxoEIenRpGhOJr7CVbSL2+QMDn9wseL8dz dqANiR2xgDG8MDoTzgHhGK2LII2ZPga/vIZiFPPRlDUgkYqOe0kg65iMEm2KF23yBQkACzTT/pPA DAsM5I1hydybMr96jqe+hCMuvFAEkYhF0VKs7RJALmgBWcGci0da0E7YRNks7Z8skLd5huWaaY3d ckCFgMsaKK6DoiLpjKioFQI+NQDTUFzCXC8DZ7NGxrA1pHTQkzcvrCVDUd0RMMxrQNILo/OL3eJf MxZG4FfWsZc3MphmDmcNwcO08FOc0IbxSMjQkCFLrw8iCe1EUs/ZLRHFGlOslT5iZFxzdIMyqqU7 zGuH1ty5TLi2nhweFX/Ur/Vr5s/75WYPcbbXNq4BZphAs/O2WJZwnvyjrskxnls739pZE+UQ+Xqg TQxJToOTQidhaRLF2u6j+/cO7twBP8EbDNavWOUOBuEAH/R64MlXez01Pt8JfgWyqo3G40jRzDAl RdF1ncjnh7v2jw0Pi9nMkf7aEtnIr2i7jGlb7KgY4H3kROxCUijDxJZa8Pn8LkdsYTo/JD5pKzn/ 4jr8HkyBITc088td+IVj0if6dIMh37fStdSFmRY20JP/StRaUcX+3WK+hkKszNB4Mqn9rNfAaOb+ t3kwSX+6R/xT3AyJ2se2iX84TyjEJFkYqvsN7wUSZ6lp1iDmAvCsQqOjdqoaunT2siiP1sVRLDdz CkFYZQVU5Niy4ImhO3mBeA0rBFzW0NNJVZaEjsWHQxNeYXElFOsUkOg+2LTlglQ6HQwE5uxDQChr qYbtL7aAqJqyaW6NFconJ1QrpFkmtNMs/YBtyG5u4C9vZnwkRriIumpGoIkjlSoA6B1TX0fmLH5t B2evoYGh1CTbmVZas3TTeDJUOHhItuImKGZvoLwOiuho93zRJ393p9SlGVEVhQO9djj/wIg+YBRG pWY3+43N7sCb3U34pK8SWkmQK6BZ6EIJS8axeh2QfG35T6QqLMsoYiuT6X35BZRwjFS7fcHaWi5Y xfAcsk0n3YCmaUEOgMwJ34fZRRJRIrIjsGmZPI5n4vF4JJIMh5AUM445i/rQZpvsnL22hyy5goXu RPPaNQGPSt6FZhFt1+6F1p7H6xM8bjgtQGE41PR8g0+JwSExZOTCq29gJDRqY3ZAPXwKGYZkbYd3 OzRpo8jXTNGEj8d99hHyqcKh4BtdLvrqtR6+S/xlWM+JWtgQ3JL2eL/0aNIUC5eQuGOl+5qmOZ9f J7K5UCKZzaRttwduW/l2UDhtFyOYXBFfuASMADDB68mSpPlmAqJlggoBlzUAnPyLkl6bH00wAW+0 ta6unMIqFwZMVc3H40PRwNwRMDCtbtnMA8cDDOKqNR7TXtImhwDLSth2KokTdR4Cy1mvj0sDEdlH 4AyJBwWytYq5vIGpsldrczn98YiWMLAVNTw0o9HBDXO7ZBXYBIAx2YpF9SeKw4tphhRrTcF9DSTV imeNlGzuTOh2LiTOEZiZl380qGUxrMNLL3HjQ5AwSMx8s5MqhGhBjuRYwXJDO5LjeV3XbP+zOTVo yxG/RPwrSbL9o9lmq2WrYJqyFBsewuwIqYIyiGUh+S3Hb8zzpqI45ZvgW5zYGdzxI9v+YIahoYVm q0Yc7V6048ic+YHjSkWhVUhMnymG8hZ2hGcBqYahCzzN88yk5v7xx5x6+hDZPOpPXrNeHJNfU4wX UwZ8w/IA28wVHkTG/tbSCsjCiQ5/zLMJUpKZVa0h0dglWnYwMMEBa1tY+UvCVDH8wgakJtObNAnn as7xk63B+U0+RximHW7mmPi4XcCYxO1LRix09sXQNXT5A/CkzAWS/V8h4HKHIUuZnkM1G88ZmAhz DNMQDJa6RwsPsZ6ujsWdc3d8WTT7ZUvGsCYSz1tgOKs/qGBpDUCbYo0b252zxkVLMQFHk1etEOqS RihjZHVIrGBctl6Jm6+kDBkQH2iloZW5PaTszFsmS390uV38CFJyWu+2PdiNJJ41wIG4+oc4YgU3 SbRwWLdoDWYtrNomYAtsDcn9MSyjWIeRVYavqWI6XQSmYw4/QwN4sYe+tIrRaNJ7As4UJ08JGovI rqYZzsWbdsEcC0wtrwSgLWvYpXVs9kXSFpCM4RbLURcu7ofZ1i1AxZhMu2IVqpuhyHAfp56uE+iP TxIwYmgnI7OYlHl0jBWB/Kh2bUpb5tcmYI5iaOQoOpKNVSwnRdo1pBH1UkX2fTPK0e0rDwn4mXHk 8vdT5HsXsZc2scX1etpFtWDq9IO9YdzdJWKaNaFYCbQkTFzXwfuJIzyrAPzSWvZtdXi1D5qfb/51 vHUkoxE4SXJeO9724lXFF05Bp5mA5mvwq3d7+Lp63Z7wlT8qBLwAoKQSkZ3bic1bBsMRgeMquhwn C02UFEXN5XIej2cODg/COSMmQk7Cr1ns2tstblXNHSoyMXkfe0W9ubtH25s20jrw03idj3mnh1Yg +9p5oqJiPjwkPh63npjQbm2l86L+3ISRsfBbOvn2QsQsGEgaImRTgF/Vxm/vl/aIxst2QyDAbvEY 3Yetl2L6RzucBxlMSObEZLfWVDMfXcE3sQTB8h9rNX4xrI/k9N8MmgGO+NAKz5vKOjvk5AgGsTjS CTItFi1aHpOEbVd7MHQD2rDQDpUVWVM8mgrNLR1YR2cW26t0ALK1iZzYiIbRIqiJWUet1zlZIIQt BGlHQkHmJO2h9SiGcNQk7Oxe2wVtr2XC15BmSXsZeOoRHZvPPiZJ2NFV+CTe+CI4R6l3UTe0cdU0 EeSJOhfBTSltTcCNGDYOgHn8oiMA+1NFasY/uFp4Ry3DkNg5ddxQynw2a22PqENpfVUV8/7A7Gki zwA445FULRGLwVkSnIUcaShoXS9s6nUAZ1XN1VUZURQamrIVAq5g1gCAFAml+nrAkmVj8cTSJrZU 0gcLFJAfYsnEeCq4zO2edScbMKx9ecMu8UJuamD1cWlrFtg1x7E7Ovk2Ql2GaT2iMaroL7yWf42n /3GNe8WkAUVbgFDRwC2bSIPq4IC03wDLqvjLqgsWkaUaL4hm0s5nOaeOSYbkPSJwBvUb27k6SVmE 6SNZbcgspImvdRPDCnDCwfbHtb8MUXcu5rwUft5S77oW4/VB6b6IMZwzftKV/8omb+ObPf2FdVDb AHUkpqfNiHNisBjdjunRXLabGpGsBY5KCEFUXCgQ4awaF146hYiPfKhD/bYOs7M46RAndhxj2k5o spAzZGs5UXYQ1vQru5MBVvgUvMn5T8LNEmc3sFUzk2RctcKqZWHkMbu8t4Z8sBAKAH5xQKzfSJ0b IAI+5mObmesSyuM98oOi+bdxpcZN3dDCzGmOkqSoI5EwZhrWAlkcPQWgOPxAYDSWiC2cWJkKAS8Y ZIcPs4FgNuCPpDONwcCCX62ZR0Bja+LAPp/XWxcMBNyzrMgBBzTDdlS2+OkggbXUUUwWxc6yFLU5 gNMi2cpjPbK1M6TuMLFcXv/JgdzVTawHB2MJ/cW4fhiFW+EX1NBEXn4objEkcXEDHWQLX65pANNO aOmsZqsZvLGaokQdsjtHMWf5CMMg61lsRLW2RpCgEKTKDYuEr9UTBwalH4eNmGI9MypCy/yDAfOh kNXgpzvq2I056/GcqZogroDGN8sSKqYqOUnDM+2Gomrt7CQkksxxhk2u05eCsKtEmE79O6dUk1NK 8ljtKnuFknSMVjQBwPHjONVZFiYmDeVCGhJJvKEk5MlS72S336hMkFU48nG7M8z713lukvSH+qSn k2bKsP5jR+r9SzxNutqr4EuqmPOW8d27xG4MwG9KM+F3enKdOinkZMWQJCC9dbnH8geg2QVTtqtC wAsGJrQssplwPB5LZ8yO9paa6goHnzCAmEjEJyYyLS0+QZjdQDbDAG2Ca3HAqPcgU3HtoprlgxP7 TOz2NfVBQjYY4qIO3+CEfjBv3lZNDfr8Tw7Ev3/IuHpp7cPRKHz7yhp3u5++sh47cDCzYmktm8yu 8VNNcJqVQvIPPO/iWDjCi8v8VEN1oC2mNhH62sW1BFD9OEZXCYtq8W2juVcn9I921mKH0FJjXXUV TpJfr1G3xolXclZXQotgJllV9fNe9HHv6KzGcvGlPrrt2IihGVFkrBnlPwGAl9Sy9Q0gqdJOlSqH so7lXzAZ52w568HTVoxwQpiJyUCsguV6fAYnXmBh3PFQT7FuZzqREzzlI28hsPetbtwxnoAfH/S4 IY3phsHSNM8yabuoX0tNrYvIeWi81e9lKFToALYGkIdDgufeWFMdjcVvXuW5IEv/5lDqdVE/mAKk 2/VQOI2F1TvPaurGRA9DXtzs97FwqmWcbPdOHCPRqClLmWRi7j6ifEAz81FGfVZQIeAFA6Dr0AhW M+mq5SsPDI/ASX9jJSDrhKFJYio00TsyEvR4vNPVhT1lUAzxnujuK2qauha1rGuo8t3zi8Ql10cw 4mOP/yb7uU8fDoXvivZdFGR+zjV8bnOL6+6f/PCC90Iz95NP/ebh2z65Z3jifcnhDq97t7dh/YXN //CbHz128wdWBJi1P78n/OnP9IyNbxwa9AiUp636ny5cvP5/vofd9sFgrXH1Q7+a+OznwqHxs8Oh IMjl6utv2bLk6l/9N3vtB9vdxPpf/SJiv/c/rIl+Pf/isiXXddbd9cPv/+Dtt2um9Q8vP/jkjR9W k+Pek1/EeANiQ0YwSoLCC4uvM1N1oTrxZLVEbAbbEp9MByqaszNOmyZb8cliWSd7Xm8Afx3/iz/c /cDHv9DGqeuefSZ/wYU7LWudrvK7d+3bsqXG51v6L1/+4if+ZUhRbt75PH7JRdsMA7aC3n1j6za4 q4Obv/7vvd/4ZjKXu3zPM+ev2/zzhHxjvbtq1/aas85urQl88idf3/SJf82LuQ/sfaF7cWe2unoW e34MkOKXqoi53Jkwa6cWjmTCgvGVnzmYqpdmL285uXoobtOSJCU0ke7rhTPtntFx+GCXurMLBpZh RPt6QkND8XTqzfc+GZAUEV3aseTR+29143U33jjAM+/b+tfPPPWbw/U1rTdcf04+Jz3+OGz9divd cdWVERfzpe1//fwz9x6ur73zznf/u19tevEJ8757txDYeXe8G77lpqf+BNl3X1V1y9uvOJfAxEce he/94TJ+87uvgBvX3/uLWx+FR65d/U7Uqt93b9NLT/58jfvO294JN37q0V9d/dgf9k++V7/vPth6 Fy12Xvsu2Ao/9J+3/xV2AH7uu9csnt2LUFhgLZaSoShyOlBTwTA0y9KTdYeOAdzuJKgWMe0Bix9E kKckYvxm4N309o2bbvn+1za+9urY6Ljw+c9fsKiF+cY3owcOnN11sPMzn37hssuvuvubH+3fnglP wNaL16yCrfmB7r/PDX7sP/8PbIX7rLPf2/kfX/76Ozes/9oX2MPd/yoNfvw7X4StH/vWF/4+3gun huKchAcegShLiVjsNF4ALgKVZFg4BFyxgMsIk2EiKOK0WLsDyQAh1QKz+PCAZFwaPoy3dfRPhNa0 szyzYBY8SgtDVTVJ2tvb7xaEWr9/Fo+sBQLb/uFTF9900+O/vhf+Sd3/e93tnjj/gthZZ2361Kd2 /c/dcOPF77vp4aNb4c95n7ir0HpToZWb0go37rI3XnzbzU4r+egj8HexdZvTesctxVY6Fp+4+Zap rfAjnvvxTwutycTIzbeMXHrZxedtwezWWccRCpzJXJ6LT51LJNes2abr9U8+2fvpz/Zed92VSxY/ 8fSzcDvz9a8N3nJLdsnSbbl8/VOF1qsF4eHXtk1tffmaa1sefaTQ6j7SumuyteOXv+r9yr/O6SnE M5lEOhOPRN5814UPAsfg/K3UvThR4DOt61Qw/1BVNZ/PJ5PJSCQyNjYWCoXi8TjcommaYRjFb6oQ E9PSSgarOxsbFtVU8yxbEclyAGcqqqLkMmi4iYQmoqFQIhrNZTOyLJuGQbFc+5bza1vb3r5hfeWK VXAmAI4a23v7xgYHdvz1IcyOaYcTe4/PV11XV9fQWNvYEKyu8fr9cLrvSIOVur9vFfBkxby464Hf wrkgPKlAIFBfX99mo6WlBZ60z+c7ph5wCVGxgMsIhSolLOtyufx+P7R94Z+SJEECtiYXzLBC1oep aIqkKkPhSCSVWtXaWuv3lbbzZv/EbAAAIABJREFUCwKaLPU897T7hluGo7G2utqKrFgFpz1EWc7k 89lwuNQdmT+Q1ILJ0qwQcBkBR5UXEAF7PB5o8kI+FgQBiQrZ2vdTCRhVSpekhKql89mc4RoMhxVN q8RFnyCGd20X3IKbY2fXEV1BBWWIaDqDFEy7DpS6I/MHwpY5WxD1GCoEXEZwhIc4joMUC19DJnbs YJRVOSWlEpm/ipLL5ZhEAk+l45YZy2TzssJQVH1w7uoNnD5IDg8N7dvLMMySZqOpqqpiB1dwukIz DEjAuCxJ+Xyp+zJ/QM5nnlcWQtJzhYDLCI4LGrNvINouoOZoGkw1fzGbgGVZTqdRnqimqsrEWExR wZLlfRMhN8+5eb5kJ1A2KASzOTIOdsE6itJxDLcD2dCVjPZ0M7zL5+LrA0i6vdT9raCCOYGkqHAE Obxje6k7Mq+AT7jgdlcIuIKTg8MakC6KvmhrUk5oKgGjZH+7KZ/PQ3MZ1RVPJOTREdDYtK2nr9rn XdveVrJzKA84vgRHoZDlOF3XMBwrlJGfvJL5cGjg8FBalDYtW1qR154twGvcF9GG8iYqPsFRHdV0 C09QAERVlCjMEJhTJMEp/kMigSuMInG4w1DO0DGcoXCexH0MIdAVv8Rbharrg+GwoWtjC0QYeVaA 20nhLo8nYQvdlDkqBFxecDi4yMTYdPJDul1pCxrBKF3SzpWEOyujw0jbvr5BM/Sgx1Pn99HUmfjl 4kfq6NEsjwrJ617N9udzjicfmxR/AJqaGx7GTHMvRW9cuoRfOPJ15YxUTv3eQWky30XlDhNXt/Lt wPzNiArJtpbGWRKzUCEKpEEAuZYjcY9ALwPGf41rip1nV0UTZ1cz62qYTbU0WyHht4BkLi+rmhmP AfP0T/8tAlkvJOlyz21e9WzhTByjyxlF9V0kfz9zEIGjS0BNqesCDD070IuTBEk37xkY7Gyob62t ZZ3SbGcUiuyLgskF3adDSwq+RuVpTceTX5A+RBUBdF0JT6T9gd7x8eUtzezCyd8vWyiKAdm3hic3 +shkRn9dth4ZkVczuAZAQgcT09bty4K3k5NZ7jiW0K2nQ8qrcb0vz9/YfqTwXwUnBTgdT+ZyfsG1 Z2jQnEuRy3IDHPFYRMCzLPk+R6gQcDnCCWaeKaTZEckqlnwp7mZpWqr3UGZ0uG7dxsORaDSTaa+r a66uPqbo+GmPQjYXxwkeN4ay8hlNsyPJTetIaTwA4Ba0gq4o4tDAKAAMRbXX13EVVZPZQLOXvqaT Z0xrxUDulzFL87EfX+KicAx+CduGpKfzYF0td1U9ZZjINqNZQplQXlAtv4v59HJOzmkvjKg7FPPR YQlQ+J2tjLNEDyxMs2dQcM4559X7Fj5UXc+IIiHmI+PjZ5TYg2Fa8GkXKgRcwZxiWpLWRdHK5UKv v1q7YaPGuyRVDSVTLTVVjVVVJermfMMJvyIhAfMcZF+Konknlg0O9lNq3sEhSdd0RZHFXC6bTudH hvpJIivL6zs7mDPSdT9bcOrN4wTO0kSVi+i0ncgkTXQG6Coah3OgfFZ9Om9UC9T6GrZQcxEHe2Oo 3D1NkiuDNBOgN9Yzv9mW/6tiDaT0TAvDitpDPdKjObsUsb12/K+bPctdFRJ+I6Tzoq7rE11dyXi8 1H2Zb1iW5Z5jac/ZQmWsWahw4oycUCPWhmmaqByNaWKKFN36kquu3rd0RVjVoCmM9FFZhsAJF8eW POvGroiDxmh8bnQJ0ZWhKMZWhWUY1rZ9TeB87BRTQNc0WRKhuWzouhyLJfbsUts6vTzfXFPt5rhK RvWpIZNB5W+zitkdUyNh+dcJkybwVjcpUIX5IkOjF8Np9JUUDVnnWsPvRtMtzQRp2UqjVWKMABih Gb/ulZ5OmfDNDS74ZVkZw8qfQWuapwI48z4wPGKm4mP9vWeC/vNU2IU+AC8Ipe7ICaFCwAsPRclo iqIcvWhBEOBsF7Kvk7ZU2E+R5b5DbFU13dSyvbcPbmAZ+qz29jnVzDJNcXR0b8agXIzbMSVRVXYM zhUYhoQWDiu42FBodySfJWmKJn1Bb2t9sI6jZ+0+dK4MemHHpkEmpq3Jpd8pfji4RdNUuDekYZHj KJrOpFLwcu0Q88OtrRuXLKn2eWerS2cUZA0N9/0p7VspDb7w08Q59eyl9YVq83BW46KImZyDoqzd 32vJkrEzZ6VMwJDEMh/FYZZk30PwjVcv4huANShjTUxlevRGGApHSctMj42lEmdE/cHjsGCmzxUC XpAosi+k3qJopaIojmT0VM0sI5cF4ZBZWweJGtLOSCw6pwSsikNPv/DtYZ12s16WQjFNFoC2CwGp lyUhBfsafCui47/tzaEkZgL31gSWtDafu2X1FQ2eN6sOf8JwOBgU/pm+4izahqN4copmCrFsBJGN RlLhkKGpBxi2o6GuIRikKynCJwnStmbbvfQ6H8kzRLOLXFNFe+lihQbMyxBVGGZMtygp6+bDE5PT Rwy/aYnwjnqaI8Gltcx4Th3QzfsG5NV+6rxGrppaKANsCZCT5EgmbYn53gP7S92X0gA+85K4AJKA sQoBL0Q4zMIwjMvl8vl8ju3r8XiOr9mA4oy0/8feewDKcVV349Nntre3rzc9PVVbzZbc5IaxMcaB gGkmBDA1gcCHPwj5COFLQv75hwRCMEkIJJTgBEgMMdjYBldsucgqVpee9PR62d7b9PKdmbtvta9I tqWn1zQ/P61nd+7u3tmZub97zj3nd+QUQcoE4abpsM+rX+SgaJygKYJStEyOn2vqTXiLotshmewL Q7WuFRPZA8nC6bFo/O47PtbqnLcg5FowefX5rCAU2KVpGlLqQIXfrVJ2uCIIE4cPwq5ysSceDm9a 1WUXm3r9wFcH6Hes4lwkTp3lcosJKm8Y3PQ1CI7AehxEXwW5TI0TGeWaBiBvYkubI+RjTyaF52LK 7qR0qqj5tnk22+HRc0FR1dORCE1SJw/sF5aDEsW8A+UBC5XlofxlE/DyA1r9BQIG89diEVMyGsxf M9PGAmpmxhkpCs/zSV4CyobnLQG/a/5iE1Qpn8oL4aaW2jXEZ0ciReKud/2Q0AVN18Zf+dZPTu8P hrbeee3/auR0SQZz0yGWTj3+3CMY85b//e4PO+XswcP/9dzAc4n0Q995vOPLd/0OW+26Lim8BpYz ybAMc94D7blK4xlVC9nKuZ4eyMbzY/v2FKIRecfVvCRyNNPT2tzoW0K1LiRFOToyemXv6iVbu4bC cZbCz2Gmijo22wb2eBx/vo2bTAjfGZaGJONwSrxP0e/pZvMFRSDIba3ONof03VPChKgeLeg2Ac+J sWQqX644K6XI8PBi92VxYJheN0OoVBa7I68JNgEvS9QsYDOqhWFQ8Yb6msGY5X9G9Q3lZGq4UNR1 FYy+eYvAMvJPP/nl56OnHMHf+9id729kjNT4E//y7HdVwnvTjd++fXUYmlA9W7HT+3GSdXqaG73I jjTSorkajeE0w7i97sDNN9/rc7l+dfgxPvVsQr4zLE28fOD+5wd3CxrKGG2+9opP37H9mosiyFAX Z4XX/qzXdE3Ljo2KpVLPFdu9DQ35SrmnpaWrMcxYImUXoSuvD2Cpp4ul/snIhs6Oxe7LTFAE3uhi DNwcBx0MI8jmSjBNkmYMuq7jptYVbeACS2Cm8ol1lmkknW/9/g4nu6ad+LsQ81i/8rO0MFxUd40T k4JyUhCpETzooJNgKJPElQ0czAAX+VCXGGDCnS4WI5l0R8D30IM/u6RSj+qBm9NtnLctYBsXCfUR WKS5uMoi9jWsMa7WDLbBLHZY0tAxQZRNdtbO/qmvtxNcd8vGvtRAIvfLh3bhm8PSi31PSKrS3Lxp dagaf0hz5kZFEAulCuad7sjFFYEv5nmpUJoYz8WsoTTAYNLI2BNP9+/SMH9n6xrWqMRTGR3nNeOi lXFHOUskZWqamMKVDGOpjKF4aaVU6t/1LM0yXduvgolMrlTqamx0Ox0kQSyuX5qhqVXNjblSRVHV paZ3tiZIPBxQH3H7m73czqHB/WvWlnjhMjjZLteQrHS4nJfHJo91ebmg8+3RiUNrq3vpALO1Ymxu 8V6fyx4Oh2m361/40XUNjbt46d6QcYCnf56Qtjd6PkLlvlTyXtHo/MNCZFdj42If69JCkRcGIjEK J/te2V8q5Be7O4sGK9KeEsq2BWzj4uBMoK8lGQ2sUaPe+mkvvCIIArSBRzNES5J1df4IGOPWX/kR zuX8r+d/PDr+k9FxeCV82YZ33HDZO7r91WoQtKvZj2HinO+WDj72UpGUC6liJCdmMaxl2+W3BUgj oyPDl3G7t1/ZtU6Xs56GDezF8TVWRSuBfq08LofTaUlG44xa08yqInb0SC4QyITCyZ7VgWCAY5jO cIMbpjYMsygGcUWU3JxjNJ6M53Id4fDCd+AccHmJlkce/fzOnY5j46cnJra/ciBz6xvxX/yyAzO4 z97b9q37Yhj+Nzt3siOJ4cHB7Qeqe3dgxg8/+b96v/OPsHfrzp1MMjE2MPg5r/cDt7yRfOiXV2PG 2z70iTX3/xvsfWDnTm4oER0cxO5+32If6xICzL/NpV+KdGv6/r4TZ1IhLj0QVhaibQHbuIiol4wm rUjd2R4nVMgBjGBgaAIn6peH56kTXHv7FRT2Y/SMCb3pjivfG3axtf0E6/dgGA9zA2PW9xrxocla hfDgDVd//MYNV7Ik0dn+hu1t/QciJ/oGfhJPtHa17byp/eqLFIhccySwHOt0uWXLWcqynKppRl35 KXNyo2mqJJUmxiqpxDCGN/T05Ff1sDS9eVU3x7KkpT17cfo4DWiNoSQIpyNRSVYsrcFyayi0pNRG VZfr5Jvv2PjIr6LhxpF3v4ffvXvVv/7roXe9hyqXdn7i43ve+75KezvsTfr9Q3V7SYG//tN/UNtb gb13vbO0d++q71X3XvvlL+x9xzvR3rS1d7EPdGkhX66UBaEnGHj5qV2Z1CWnvFEPTdckUbHXgG1c XKBAX2wu6kUAukUJNiZD47ihqfq8SsJW4ru/9eQ3ilNP5dz/vDh+yzs2dM1oJgulYjmrYaEZHHV5 x87jEy9Zm/k9Bx9rbLzsqtaQJ7D+bW/+6jXRgy/u/+8D6VO5Yoxig3dcebvrIhBcreSUw+lSvabl DduyJMMNbOj1jgRTMlqSJFEQBL4iViqjexMje19u33ZlkTcdDF6nY9vqHhfHzX8X6wBneffJfhhk YSPAscLI4MjoKHb1tUGXq6NpaTljZb//6HvvNkgS/mI7dya2b9fMdZCWp//PnyqWQCDsxQhi+l5s xl64duv3/vZzf6xa0gq1vYt6iEsO46mUriiHXnzh+MGDl5ryxizgMH/mbRe0jYXB2bygNb0ORNQ6 WE/z5oLWU0O/+cnuHxaEAuvo2rHuLjH9xKHIqT3Pf9TL/fgNq5prFplh9QObLXnlvOuuWz/+Xim6 a8/9uyf2CcqBBx95b/L6f12tH+xLG2u6L7v5hnuiv/xizCimy9GKrLoc83+hWoqVJM0yTpcTekox tEtyV5VM6iY18KPJiizyfKlYhN8Sfka+UpElaXj3S4O7X/QFgj07b3gynaEYxu10bO5Z5WSqPgCa Is/PMlZM7S7dEg4xKqJ4ejIKVq+mqoSuhwis78Are0/3w5wAjHfS6epsamrRtIUxwV879Kk1coMg tKkC1cqUPO957FWnhI10OytsOuBqSeYLkXRGjU7uf/EF3JSYI6ySJPicI4MZ8UDTFE2TFEWQRG09 a8VAt5SwFFlaCvGSrwqbgC8J4JYlB6acmRF74delIUUyI2s7N4nJyo5Nn7lzc2853iY/+7Xj6SRR 6C9ozQESC3rc+TzHUljY4+4MBtH7wj5vOoIbOHZFd4dGEi5P151v+uJlQ795aPePxislhxAZjj+x LzKqGtc8MHxANdt3Xdt7lZe9COyLZick8KYZYQ2jEstxqgLEp+n6tAVg4GNZlPhKGdqYT62iwrgl 4gFtK4VC31NPeBsaWru6NF9gLy8AnQMdAo0HXK6WUBBNkHTrAwkzNdn8+Thz2R6TFBntNap7Cd0S 6ZxIp0VJBvY1ffe6hiuyV1ESkcjYwOnk5EStY7qqVtLpyUikqzHsWybS8zbmF4Is942Np/N5IRY5 8szTOKoFZi1LmdoywK/YTBo2wzY5E/BIM6YKDX4Wql6mwM17dtlEyNsEfMnAwMBsggF+HjKRcG51 z60fOzGy7647WQbflM8RRLtw/Udu0I2PD+F7QwHG0Dc9/1z01htvu/bDvWR4O40fY9nWULD3Zw+o b9j2Ozd96u0RqtTcNJrNbZLw7c6t3Bs+XSb0jw/Ij9/ymZaJ/o+lPL+54+aXhk6/u6m3V2b6L84E HRV8BFPA0o6mGUtMG7Nor76Zuf4ritDM0u5QwRKFF8F6UBW5Fqsll0ojx47BJ4Q7u/CGhlA4zJBk kufTuTxtRcmhrFeGouENwLskQSqaSpqqJaaVLMqKoWsUQQiSBH2AeVIQzGhd5St8NhHPRKOxiXHo w+xDqOQy8YmJwaambWt6F13i28YCAyZ5o/FEsVwujY0c2fUcZjl1KMq8ls2IfpaFa8uUmpkK2ETv MjMYWdbpdjtdLs7iYJhZmm1WxPVTEgRRhhtz2cSg2QR8ScCwHHqSAgO9js2Dxwn3NKwf9ku/8w9f zX71b/F/+1eNot78gff7//mfj6/fuP2Rh3SnczwaW/MnX37fV/+W+tuvymx02wc+4P/i3x1fv2H7 oy9ta2ibyCXW/MkXQubebwsu11vf93v+f/4n2Pum5ydv6Vw/mRv98MtH3/gXf+6/71uHb187D8d/ FkzpcJjCJgZNz7l4BoxLUTRYEiYzqiblmiooprmsTLOVrUD0fDyWi0XHrehok8ytcQ+ZJCzncLtd DpebYmhBNxQM13NZRZZkyYRpVRuGaV0bGgYPqgoGriIrlUoZjSbkXE5mTRQT/SdHmpo8Tufa9raL 90PZWGqASVv/5GSmUMwMDZ7au0e3BHmAbYF9OYfDFIh3OoFoKdPPTCKVN/RGaAOkCw3cXi9cjQzL 1Yzg5W4HK5o2lkgWeSFALa0VmXPAJuBLAnBryQybN8xZMzlPASzZLVueWr36pjvvfPZ734cvuOYL f/LbP/miGA7jjz1KRaJD737P6BtuMff+2/eAgq75wh+jvepzzzoGhuv3AqFdW7fXu2f/4IfuMfe+ 892wt7YKOO+oyVUiTazqq7Mi2jQrhA2zpCuBZEmS4FhOlkT4JcECrjUzncVWuJZJqKKI/hRFqYZ0 WZ5/3HIRViv/wFfraLnqXIIJDM1g5xTo1Hk+NXB6IhiyCfjSAUzX9pw6BdPBwsTYid0vypZ3xFxR IUggV6Bej9fr8fmAZRlLKqB+9lbNXWRZoGiYEgJTm0YwQb529sV11RcdbZxM0jALaOic3NjDm3eP 4Rs91jEuS45S6EifI5kmRFX3d+R3XDNy5ca8cyGIBu7QiiiFfV5npbQAXzcvwC9ZwZQVD7hLeZ7P 5/OxWOzkyMj+WBLO9c7Nm9zLpFDXAuMcweQmrcqSUIGfswKPkln0QjH52FyxncpWMmVONFmWRUGw 4qV5eJQtl7JZB1G/WHcZfC7j8bVu39HV3NTd1OR32yd3hQMutOOj45OplF8Wn/rlg7W1CSuhDmxa ty8Q8AeD/mDI7fFwDjBwacsInnp/tV42CRwM5i/LsuZKME1ba8ezfWMGU841HN23av8Jhi84XtyD X3fvi+/zXvd7n6sxqu7fMvrXX+zf5N127x83Hzo56xMchRs+cfhv31+8+EapKMtHRkZDHndxdOS5 Xz0MUwqO4wKBQHNzc7eFjo6OpqYmn8/HmI731zHnuHiwLeBLAhyOh3AsKkrAHIvdlyWKcwSTW0WX GcNpmJ5khlWAfVUUq1VnAYOJrGpg/yL25WsEPL0+1bwDpSmL0cioKECHNq/qXmoR0TbmEaqmRTLZ WCajxqOP//ZpVTlzO1t+nCnr1ul0ez1en9/hcsKlaxJwXTNsqpS4maZI07CB1mJmfZvuHt+/8Qf/ 0vREHa0+8mTbjZuBNvSmtkpzA5OaYKNHuv/2K/r/+iNcx61Ih1ZhY4vE0vCMkioMj4td7oVckoU+ FHO5BfzCC4JNwJcErAohZixuPpP1+/yL3Z3lBJTLBWMVYwVLw9y5atROZ1VEhKYHWhSBep28AFSs yGAoW/WpLpqbCYxr4HhJkpRkohgMFSuVoNeuZLwyISnKcCweTWeifccH9+2ZPaurKrtZHGzVCXc6 XS6GYa2SX3X8OhUtjdrj+JwLwIZ79ODG7/xd4wuTBucsvPEtojQR2nOILgOzmrvF62/vv/t3yInj bT+7v3HPcHjPS5SswR55410nvnJnycXpuM5Uss6CIgab+QWZE5pzZWsxKTY+thDfNx+wCfgSAs6w E7F4d0/PYndkOeFMOrUVzwKj25wWraUGqqmKyppJHg6nS5JlWZvS6LYI+KKQMHw48nuXK3wplxmJ sG6OY+xk2RUHUVFOTUyOjY/H+k5ET5+a06eC17TxKMpM9YXrgGHNcOjZ7lbrKV6HGR9F5ye6/+en DXtiuN4U+8Ifn75+u6KkGw8co42OInUYGugOZ6WhtdjRTo3vbdwzRKtlzFpn0Tqb0k0hzdApVcaw oOJmeecCXY1mNCVB8OWybQHbWHKgVJXSsdzir3osP6CEJcMK2QIreHagFoahaCqDojSUAWIKelj/ TDUNQ794gRZA+7Is8ZUKDL2FSiWSTOVE8cZNlzO2VtRKAVw9BweHsqWyUimP7t+bGh87S5oNjngV R7lHpmcZeZqtotdz5T6cdRHUUEIvPtv+yF5S0vJ//jdHbr9cMX3Yrolb2+HTmx97CpoQkujMRtr2 PNz5w2cxLFDxdNPMkBPD2Of/6QbpMWJsDM8bcL/ogfDYX/3jYOdC5Knzkpwtl4lysd4zv8Rh36WX CihFpiRF5pzJeLyxuXmxu7PM8KrCn5gVHUNYzmrK1GzWrDVi3dKzuogdM4tOiiJ8ryLLfLlUGhuW wk3PqdoNmzexNLXCRI6WFKwTbFzUFXf4ilShcHoyWhEEn6o89dAvJIF/lfegjKNqyH1VEOssS7xn BSnyoRP7aElR3/b5fbduVKZWkHXrYJ0p08Hr/Pn3d/z8+7BhODz8jdfEb93UfugReEpUCq4XjhmW 1KhBEpqikeJCyGLAb3VyYkKE2Wgspqq2EIeNpQdc0wiKPD46enNjoz00nx/OMZBVFQ+Ahk1Tmaz6 qS9yloGZu2zJcqFYVtjKnj6lY9hzhw5ftnpVe0ODLdBxMQDD/UQqrWna6taWi/QVuXI5lS+MJVOs oSuR8V8/87ShG+e8/Ga4k8//vBOq6EhFMYzJ7OhVp3JqcV2lFF1lGA3jMIxWOlbxzQGVZoSr7xy/ /bqiMdJuzTSVG98V29qper1yMCD73IInlG1ZiKATuNsqotjo9YwUC5ptAdtYiigXNZIqe32SojhY 9tXb23g9qI58hJnpu2DZfabAqFotuWGaOwShCULsyKF8Q5hlaBfLhbyehenJpQM4uelCcSKVWt0y /+wL1J4plgRZHozGCF2XU/HxwcGJgQErdrmmHDPHTNAUwGJZGuk8k5R1MZwvBxsaIYtmZlNJRDNI upRu2fVsYCjG33q3ZV16cm/+wMA7rxMcDsFSiqXy1e/ir3v7kTtnVmRZGJjqNzyvvKqTYCnBJuBL CbKsZjOk11cs5B2NTYvdm5UJfCq8ZWG+DsiAsIZavE7SVywUSrksxbLAzN3NzZ1LrFzSsoZuGKOJ ZCybbfB6G/2++f1wQZJGEklgd5MDhcrg/n25eLxcKJgFFszQKusfRSGNZ7PoQh2Adx1OJ/xZqb00 VUsuev2XosZ6imsub9q3K/Df370iOyH4NOcLLwQGBphcSQnd3G82wVXWyXs9Yq0LuoaompAlwjBw XcMNnZIUjGFFeqFYRjdy6TRfXh6VgBFsAr60YFirI7HJySabgFcQkNBg/UCryXKi/xTFciVe4Bi6 MRBYrL6tMIzFE6cjUVNuiWNHEomA291wwXlfsqpGMhlJUmK5HGz7SKJ/757xoQGxUjHlTE2/BomC +8zA5nqByTpyhRc5h8Pl8Vgizw6Koa1grPOZCOqMK37Lm8MHT/hP9jf/57hOYgQvwOvajXcfecsa 7iGzDW7MeItDI03NNtd3773lP2gU9o8bhtbQdPob3530LwTRwK9RyGZsAraxlGHeGVlVV5deDTsb 8wiwjPl8rv+5Z8TtVymatm11j9PhaPB5l4L6z3KEbrqdC6Ks9I1PNLpc+bHRfl5gPR6Gc6zraONo RscwB8PMaRMjxdMZL4qKEk1nGJpWNT2Vzxf4CjR0A7Nm0799+slyqSqmiKPkXku4ysrrdZsiz9Z6 vxVbdcYIRm2mRJ5dVjEGCptSeX59R4sT+ctuOfJn/k1f/QfvWAxeUFetT9/z6b6btgkc3enzqY3N lZZGtc4C190dqeua/KNRks87ykZ1TojjGsk5Kyp28Ql4Mp0pW/qv2vKJwMJsAr7UoOTzRD7HB4L9 E5PrOtptDl7xmDh0gHV7nk8mmjs6Nvf2hv0+Oyzr9ULX9Wg2OxJP4oauFPKHXnp+dHAAsxJ+eq+/ KReLoBqA7lDDhu4u0nqCqkniZlloysEyZUFE4XIWZZp5abFMFh6BmZFuWkcggEnCnqeemxwbnfbd VjEPyqrWBezr9fvdHg8qtDDDwK2T4HACAbNWlYXXG/9c/8XF3itf+t5/OAXZwHSVcyhklW8n7vrT 5FsUheOm50LRg/d8rXTV4dZDB5iMYmCMwWCG1yN0Xj7ZzJ1XB14fjo+OkYZOmiU+lxNsAr7EoMi5 Y4d9l2+J0HTI620O2p7JlYAzegpWHJZVF4c0CN0cvw1j8PlnSZrhL99M00yuHOwIN7i4hRgTVwZy 5XI0k81XKpyuZUeG+15PrvRlAAAgAElEQVR6sVIpVyOhMGzoxV2oGfzs4dW90b7jmLUcy3IcUCA8 Mh4PyTmALb0uJ8dx0Ays23w2k89mvSQhVyqwkctkjuaySNV5RnrClBIqjdzLXp/PFwi6PW6rysK0 NDPoEWmRMHJTg21NXhABWyBI3jWzGoqBk6Jjrok7wSYuvxr+zv/rzhdFnjdF0XWNTyUX/tsvBDYB X3JQeb5w+hTjcguStNh9sXGhqA6vVQUkiq7KH7G6oRMqaRVcqrbMjQwd5yup3rWpzg6f07m2rY1j zllo6ZJHWRAGorEiLzhoSs/nD7+yLzo8rKqqWTvImuWgMONapb/C+DjaMMsCmoV5KbMQAsMawMcE wdFmnDK8KFQqfLnCV8p8hdc0rTZ3YqzEBHx6+hC8jqoHgtXrdLncHq/H53V7vRznQPxa3xJHFZEs GkYiHCugyOCrAsaxE2PjcJCkqi2vBWDMJuBLE8DBuqYl8vnWUIi1R+FljmpJY4qkzfI2nMPl0nSz 6KRu6oHoKDbVsFaFxXRqIp+Vc6nm9ZcDh2zobLfTwc8GRdMGo3FRlnubG4ePHX3p6acrxSKQoxmE bHIrsi+rUhf1bzSmZNFg9iNJog7GmWGUp+RLz6So4bg1XaqGSlmC4ySGeLTu0+BlaGWWkvZ43G6P y+N2usw/zqozaJ6+uuZVukUB8cR5rf4uQ4D5W6jwIbdLzqTmLOm9lGET8KUITZaFVDLJccPx+PqO 9kvhLl3BQJL6NGNWeIVhGowqsLzMUsRmwUS9Fv5j1UvUVEVODw3z+aKw7YpoNtPk96/v6KCpJVGa bSnA1NZW1aMjoyVegHnMmmDgmQf/59TRIzhWVVm2sm052qzlZ0YjV9OvZ32I9WPrOvpnVa6s7UIb SLGqKhlp2qyklVg0k86RBeyw/M8urxfOMFjDqIagOQOYS+EZq1uSuCi/0RIDQ9NwpJd1dvzmhV2L 3ZfXDZuAL0VospQfGiAdjgEM87ldrcHgYvfIxvmDsIwkGJSdbjewLJhnTpdLVVRtKjUTs/S4dE2V ZbNYE1+piMXC+P69/qaWcmNjMp9f297ud7tgXKcv4aA84F1BkuHXmEilYbbCqkpseOhHe/fAT2bu tsKRgfPMICeXy+V2o0go2opGrudgi31NaKpqyqQAB1uuiJk1oc2ALGT3mh5j9Gg6ta0c3/rqgdaX mhUGgYDhFLMcB6YzcD8+dwXfhctBXyKwfAtGuViMTYwvdl9eN2wCvkQhFwu5/pO02z04PmkT8PJF tf6NWYydg5EftlmOBaKt+Z9roz5QsiSJfLlMWgWdyvn8aCTiCje6QqFyvhBoCIX9vqDbE/J5LzUa FmUlVy6lC8VsqUyRBFYpJcdGYwOn08lkffoQjlbZWRbY14xGNu1RJ8NYtYbqbGDDCoC2+Nf0OFgG MDoX02TBq1IaaOnecmpbrmhihksbcbTpq+as8GYrBwkan4fC80oFnD44TYMnTpylRsWShk3Aly6E TFoTpaLAF8tlr3shypUsKWiaAkMkjG0w8i12Xy4I+BQBW6Ywozid5rhv+p7PRGDBE1VVREGA4Ru2 FdMUFgiRzEcmU6MjmbFRX7ixsGGjMxD0Oh3NwWDI474UIqULFT5bKsWyWVFRfU6HB9NP7t2XmBjL pmauJuJT5e5NY9TlMsORg2Y0MmtFI8+wgOtc0KpZs0Gz7F+TmY1pHzlFwFbYlOmItmKrp7uOrcwl lGJEM4z5ZypNkrjNvhZM5c5SCX7qQSv+fNnBJuBLGIYhFQtcILDn1OnmUHBdextLr5CALE3NPP30 358ss82edp/DDSOVqskYTjKs18O4GdbT3tJy5PC/HogNmgq7eMuGVW/Zuena4KyMi6UPtNRHWjar mTBKU4ymT1VhOmNxGWYCmkzRNPCKwPOmkgNFk1MhPMVkspROJ0aGOnvX9Fx97alyhWOYtlCwrSHE rdDSwmVRjKYzk5kMTMKag4HeBte+F3b1HT5UzOfPZkihGGP4hVmGAVsU2BdomHM60CLuGQKucrBZ EMtiXvMfZlWknGZPT63SouKB8FCN55rBq/gUU5MouYwkaxqTNjAsns3B/AnHjEIqtdh9OR/YBHwp onb3po8ecgRDusNRFkSYRWIrhH8xTUqcHj8QM/RYZq7dOOt33O5XduerRVMSLx45vHdg21uu/9SO rm76vCXsFwnobMK4bCB/Zl3gVT3AxgImkASRZTmG40y5YLCmFMrUhdDMt2iyMtLXN3qyb8eNN3nW rOsbGx+OJ9a0tjb4PGANr4wRH46zzAuJQn4oGoen3eGG9lCw79DBf3/8N6V8ARmf1JlSynUyF+bk hjGjlhkWfj2Wc5iZvg7OFH2k6RlrsdUoaFQJeup0zFmdoxqpbK0GY3VVL2fgTHjzrJpHlzgk1fRj KWMjxjL0P2M2Aa94IPPI9F/RKEEfxg3TV6lPjQvJl3a5u1Y5Nm9JFgodTAO53PJSDN2MN4JhsTYg 6aoo6d4Nq2+mKyk4Rqk0GavkadoT8nWwBAzBOk5wLneDPAnjX7C9qRWswnI5kakcevjJr0tv/MJN vauI2mebpiRarlu6tIyGY2Mq0QVDK7jTORhFBqGlRKAN1tJLkmVTNoiSZcQTtcZH9+9jDh9u7uyU m1v2xmOeYHBNR4ff7YJdwMTO5VZHC34IXhR5SYKfJFUogM2kiqKbwFldPfLbpx88eZIvl00blKpW sMdJolpvqO5D4AJgrHxcMwiZ4yxZZpYx+ZhBLmR8+jdWz4VhnDkvZ0GNXBGnzn2ZTQ9vvqCfYwVB UpRsyUz8jQ6cXuy+nCdsAl7JqEbokCSDMhlcLkEQ4MVqjsrUuEDpmlgqDcXiLo4N++a5wMtFhjQ+ sutkIuJv3Lm1Zy1HYAof3XfyqURJWb/ls7cEGKDbZN8Pv/Xyg97A+jtu/FK3C1c1DcbaSvHEw0DA 1FXvuuVTTaw+Ob5n15EH+lOnH9/90OZV/zuASanUydH0qKAIpoAg4W5puhJswaW8VlwbmmtpptP2 WiayOQ+jTJEmp8slmYRkACOrVrDumXhpq8QhIDE5oQwPwcGHulfFhgZh8uYNh5uam5v8fiBjn8u1 9CUtNV3PlkpFMHlzeZhhqJKYTiQwgZdy2aPjY/lsFl6s5hdZqb2UVfDAikkm6qtLYSgf1/Q8O5ES JMuZ8c9ICoNA+bh1QO+aybtz0nAds77q4djUOwMVUYQzi5VLy6gA8AzYBLySUWNfp9Pp9XolS/oK tlUrQLPWDKw8rVSo0Ez/ZAQGVoZaRleFEhl+ZvfwAZ07Vpb/8KpWfO+R/3p+4GUNp/2r3rmxwQXj YiDcAe1kRRNlgwuh4riGjLTuTY8eRtDuzu7rNiaPjqRGFCFSVnU998rDL3x/PB9VdPQrebdcRnQ1 tzqWg3dgzmEayADxjCWrBCziBaOXoWlJklVNNbQz5i9MWTRVlSUTosCLvBA/fUrTDSBvlz8QCQb8 za2tq1YFPB6UtQqs0hoMBNzupUAPcJjJQiFdKBpV94VRqPC4phWT8XIiXsplc+l0IZutD7BC+p2k NS9hLcEpIFdzgbya4HuGICmG5jjOzMf1eKClqaExFQx1Nr/xAh32JQk4xYIsw2CVnZzQZJuAbSwx IPPXlNFxOBD7wiswgoiiWM2LmALwsaxpWVXOlUqHhoY3dXfB9H6Z+KKdW6/+aCo3vDt3/Pl9f3WY xQqVtKypm7d8+arWapE4GFrhUVE1afZdqmZHY4MFJX0qsv9EdK9ZcQ1r9lBaKn1oODthYGvuuOmD 7Wz+2ZceZln/ch9OTQoxC+aYszHD0MF6AztYURRd1dCCJWoGZAwvisC9lUqlRJtrkzgmi5Iqy7l4 DE/Gs6MjyaEBpz/g9vlCoRDj9SVyOTfHAR/7XM7ettaFt4xhOnlqYhKGYzjLgiTBbIBj6GwuV8xl IwMDhXhckURJ4NGksxazhmCRL8VZXgFTbQqVErJSfcg6nSnrXRRjhV85XG4gatpKQFr6boCVCl6S BiajhqryhbyuL8sFYMwm4JWNegKGEQQ2AoEADK/AuPX+MWvAFf3l8rCsJXJ5MCB621rWtbUtYs9f Mwind+3vvuPvx3/40UkpngILH1/7ljf92U2rznSe9vd2YVhizigYdc8vntlT+yia2nLXmz4YJIiy o8VBUrw28JsXH7z5ive/5933eRh26S4CvwZMCQVTDMvBmQd24TiHoshanVwlgq7psiwJFb5cKlJW gg2wjEhRqrlsYbXUDT6RgL8UZgxb1O1rbW1atcrt9UUYbjgWd3IsTVLwuQ6WBWrc1ttzrsmcUfXY QhvDClp61WOBy/fQ4DBNUZIpy0woqlLiBeh3o88rFgulaOTU6dOxyQk4LqRrYQmFWQ54SzJpptgy STC05VuGm8Tvhz+Xxwt8TFuhVXUJvlVPNc0wqNACY6UDYWcxf21cbIzG4hUwKrIZqVhY7L6cP2wC XsmwCplRwLuwDQMKmD6yXB1zZxAwWDuufF5PpUfKFYl1qGb6or4shII1uTg2cTg/9ZT2r+nwzpHT bHpVFcGYFeTiYn0VCd3A/iu3vHl1gw+G5PaO2965g39p8MV0cfC5/X9yoH/zm6//7Lb2TnI5j7SE xXBmiC/Hobp1VhwAylCtI2DdJGAzvZWmkMw0RZqFZlXFXCo26paKkeCTpql8OjUQi5pVChi2ef1G K0vHybmchs9XULS9igxspgIfM4wMMz+T8nDdwIC+4CJDdanhYzvCDbA3ls0Cp2q6Ad/M0pSkKIje oCXHMKIkUwTBW97xkMOhlIoVUazwvMDz6cGBPbFo/cIK0li2eBetfdPVBJ7p8XSWiqfZYY9FwP5g 0On2wC1jxjaT01zQyKVEUNVPRAUP7KioRQFceLysOGhKFSrCcivAUA+bgFcs0NCAcipMRVmLgFHs 1QwCBlYuW4GgsCEW8sMKCXYwDFcBjyfs8y7eEbw65HL02KmHHzn6qEiwId86Uh5P5h57dD9z1w2f aHdNy6lSZRilCzrWPi2Qilr1hm1vy+VPjk0eniwn9xz4UbE8cdPWu0NYztVw/Vubrk7G9j2270fF Yt+hgd+ubvpggFkGM5JzAM2oaFThjqGtbOGZJicwqiyzpu1riSIiiQ9JFMECti6bqXaGoVnBWqam hyTKwI2ypClq/MRR9LHQBFgt2N6RdbutmgGYWSERM69F2mIvljHDnaArLMtoGH4olwNm9FgqXbIi w9cVNd38XtgCyDLQnKKoGArnNvRIqZRJpcBMN5e3zQ6ZXAt/tQPBp6Sbzdh/M27ZTCIiziTRVlkT WLZW7M/j9Xl8fqepQeI4U0x3erUDYqrgI3HJVDtYaoAzPpFOJ/J5WlVzicS5g8yXOGwCXslA4wUa SihraENLvzMuWTAooAE8wsTfXOUqFso40S+KTo7bsXaN17lU5SkMaXT0t88ce0xQpNbOe+7cdoMQ feo3R38VGfvlI0TbB259uxvRpYGps98KTAP/I9evWf3GJu6Wycihl4/+7Fi0r6//p4VK6zbHC/tT JZ8n5GLQUjlOYMt+oD2TLmxdFuZLc41cpucDLW2iGAKGBh4F/tPAeNXrloqBgM3SDgpwpCgIMLuR BAH5V6qOZOvD89EIdkYcyhKEsqxbEtUxMAv2UVZ9IUqnGfhWFsfNCEFrlcTE1AZ8k460lHHsTLkf ggBqRRWBZjOhpRtJmQ5jh4NzOuHaplkwqqtm65lm1q3BWGLLTrfb5XZzDlPkuaY2NfO849MwTyfH xusAUG//ZBSmhyGWHozHFrs7FwSbgFcy6keKmj959oQR9sLQyVgqd+ZgxFfysajmdOvtHX1j49ds WLfgHX9twEkn7f7z93/9J8fyb1i/bU1L2LG+VyyferT/8Nc+8JED0Sw0uayrcyhS7nRhbZ2rf+/6 a7JFM/p558YNv04dIAnsi2+/E2weXNMu33DrFeu3/uzhP3129OQ3P3z3zx/em8j3ffjNX/3h498q w4d0b7r3d/8gXRQX+4AvFNVMU6CW2jUw+2Ko8ZllKLMs65Ila0lCm0bAuknAYJlKJvnyQqUiAgdb PK3PUgKZqk5gLX7UrYAYprtbxqx0ZITSrD4jesawM7qYll/cXNe1/pAlOocxivjdTHu3KulWaycw jFnNt24hGEVXmVRtJUebq7/WjYB4fYYu84xf0saiIJrJwpW2ubsrevwYzP8WuzsXBJuAVz5qYZ9n 89WYq3dTEnfmuAPtBKGUSOAud8nhPDU+ubajbUlGe1Lt696+6f984Uc/+tEz+eJ1/aewI0fU9/3L F7tWO5tbGoaHi7zQ88k/7PnmN7UPPfvmyXHsZw/sf9/7L+vqcDY33zE2ctXWN6/9zOewb97weDp7 YyaD7XqefN+P/9ra2zw69O504vI//tIHv/nEfYcO3hsIDv9/f5O993OLfbzzhjP8Meu0EnX18sip pWKTNY1p9XyQ1qKlKS26zEXYCtjBsiRN1UDE6lrqyFxG3Kxaj5YxfD6lW89MKMmqFV2rPI9ND7Cy ZCNpi1XNOo0WATOUaWdPc2cg93i1xi9tLRWj7F5b7nFJAq4cRdWaAv7WYOCl/pOL3Z0LhU3AlxDO NqBU3XlTI061GQyaklQul4ataKyeliZqSRbJ2f93X7/6/e9/w1/+5fADPyt3dW3dtVu8/w9+84uH bvrMZwJd3S/fdvvq97//9q9/fWrvs+L998PeGz/04a6Nl9X2jn/zvvyGDWf23vPRtTt2oL2fhb1/ 97UTX/qzxT7QBULN9sWnxKX1KZ2sGdpaiFMlSeIcosMFdrKowNCoqTOqDlSdz5pJvaY6sqrNDr1+ fbAWYUmrBAUq5FctYzD9+kZpz2ahRg6tAZumbXVld5ZuRlWKeUpVw3YvL03AdTOWSObK5bZQMJdK JSYnF7tHFwp8Wa9g25gXiKJYKpWSyeT4+PjQ0BA8xuPxQqEAdjHOcIENl/nC4XVtra2hEEMv0Rnb 2h/+4PRHPgobnY/8KnbTzYrX6x0a5FKp5DXXwosbvvPtk5/8o/q9rslJ1+TEOfZ6hgbjN91cv/fS Qc0/bLmc0ZOZowRa1tWmVmpR2JRlK0/VgTjTslqezzKkVb3qhUaf/LoHn1ptgqnCBJRFmfgMbzGa SEwlH9HItKWsmK9ZTF1rbi/uLnWUBOHI8AhcPBva23Y/8vBQ34lzNMYt2YNAINDc3NxtoaOjo6mp yefzMZaA6FI4yzYB2zgrAQuCAKOro7EpvGmrvyHkcTi7msJNfv9i99fGQmCKec86PtSq7iFqrUtv m0asxpS/2qwNZNEvSnyaXh73dcByQFfN1arn5izRUgSqIkRWUatgP+fIO839Y2NJIlMsHhoa7m1t rUxOPP2L/4GL6RxnDc41ELDf7wcC7rKACBgm50uHgJeoQWNj6UBIJbMDpwhyY0UQ85Xy9jVrgp5L rnjwJYhXJSSTRKf81fqsfOLp7SyyRkFcun4h7Gv1DKvWLkDLJlPW65yB6rVYKtyuI7TMAfO3wWhM kBWZrxx4fhdcRChshTzLqgFuSQ8BkKzKmbyypTTNsgnYRhVVl91U6SSAZtYtMOsmidHIZDTStHkr 1t55fHT0mg3rl5VetI2LAjTkGVYhJtwgMBQhcBaLWX/N1YFe17e/riJCS2fYtXEeGIknEvlCW0No 7NiRQi6LRiqUuwGPs+PmkAsa7F2Px+N0OhENLxHDtwZ7GLVxRuWHMhUKOVQ3CdgXntarRvOjw6TT VcDxpw8dbg2F1re3rdRq7csThuWRW+jY3RqxvUrRvZqE1vytec0YbV9Ls+UO3NBJWaYUFX5PneFk lka/JiWUaQ1eUylRwlXV9C/QnOpyyQ5WXxFHr6pq3/iEz+mk+UpsaNiwamtatTOciFyRV7meg2ED XnS73X6/3+eDtzqXjue5BpuAbVRtX1MPiOPQ9Qq8C09lWa5XjTYtl1Qcp0iNZiK6wVLU2va2ZVKz YblDTUVemahoDsbroFk4X7phai6aUt8kQxK0x98oZY+eSozhJE2RTo+zozXc4eEWdHp07nGttvci EfCKBK5rzmzSlS3iqsiMTMgbr+WNWOdzL7pzJVI3pGB7+rItyS3rBFbsvf+7wQqtawV3JEYXK5hm aIHW0tqto7fdklzTpC3/36kkikCtAQeXPH40n0kTVnlm4FRErmDjmkIr0w1c3NIBhNdhTAsEAqhN zRG9RC4em4BtVAmYZVnEvmBIwcUNlzUqG1xrhpI4RaEiVMoijg3HE3ANux2OlmDQpuGLCy33wrNf 28drTsbLUSxRJWAzURcImCJod/i9bdl/fjqJVIFYt7O9vXnjZb2/u627m14S48wZLJGBbzlAXPXI j1p+ewQImFBFemSCv+ET8S35Vf/2s6lfkGwKdzb93oeP37G+40c/46a/mcL62b0nZF9rrnfZE3CR F06OmxlH5VRy8MRx3TJ/awQcDoeDwSCMXWA/kNNrM6NirMiucLlcnKWCvqQyvG0CtlGdKiICBoqF ixs2JElSp6saWTL9cqVSKRQKmUq5TNJDsQQYXJqmdzU1Lu4hrHAAxbIBozJWkSoVaa4G+C0+wWJf wlToLPNDp0bGxmITgvTRa9dtYJbKaGPjtUPY8J2PdP0yQtfpr5FjE461JnUI7/6D0cv87Y/+3PPK cOO//6ir45PWGXaJl98Rf++OgtepG6o3PuIucYmr18nLfG6sqOpgNJoplZp93uHnn+Vh4LFQq/MG 7NvY2AhMXONX9EZk5lpqp+bgBmBqieA2AdtYOkCXKVy+wLVwdcJlDeyrWOL79WWDwRoWRbFYLMJ1 bCSTciZRUnStveP42PjpaHRbT0/D0q7csCygq3yuUHB6Gxx0tZiEVI5PJHNXvf0HtxEwJ5JTAw// 9JUHspJwx+0/3dFAirJsYJTD737mp/dh5Lo7dv7vG1Y3TZx67Kcvf78gHP71/l80hT65Phw0P8gw VFU06xEZFOt02Hf+Eoba++Ov9N4/BFvyFdcPfP7z+P4fbLzvUQPjNMKcf/FX7Bh8w+axnddv+PZf dD10sCESNQPgXO7Mbbf13bZtyme1c/H6P2+A6f9IIhnN5pws6+IrkeFh9Dpy2iEjGDg4YAF5oest YBTagsxipJtmrwHbWHJAhepoa8RHTHxGL7BuxQ4IWBAEuOhhg+d5Z7FYziSLpQLX2a1wjmOjY+s7 2uFS5yja7XQsSenK+Ucyn3eynNvBvXrT1wSlv++/H3r5p3nmuvff+bnLGty5+N6H9vxgIDXeuvUH n726iyPZcPNqmnFgkmBQTpfb7aq+UTAfcNyst8h4ujff/QcN4f945KtxfjDN5zHdcfDQj5459kRa qhZuC4c+9PG7PuBb5rbRyoShBff+svuB/bDJX3P3ia98Ju6jsdVfytz8cY2jw//zz+1gCisaqcqO dIouKBjGag5GhTtXV+hcxDPhwwSRlmRaUVRfU66rXaGW8WnOFIujiSRH0xubG3/1g+/V70KcSiO1 0anQ0WoV5+nRebUg0yUYDG8TsI2ZRZOAYs/I5dcRMLAyYt9yuVyL6ZdTyWJk0tW1yujuOSgKGE64 OK63tcXndLodjqV0qc8/4Ffa23865PFuXtU9TxxMNoR6uwJN5fzunzxG37l9/elTjwxkoz7/lp3d IdSCohmkpBhLZrD2GQnZqigV87lIqZwanjxSMV9xMgSl5ff+4pUHFczRGNra7HPFJg4SVFm1BXiW JMhyousXz3CpkrH66oE//ZTJviaofHMLVUo6M0l4wu57bnXmcMuLT3sPDGhd1ydaQmvgVSEb/sU/ NDxDEPEippjvka964/Ev/d9Is3MRD+dCUBbEZL5gGPra1rbjL79UKZ0p1VHj1KmSWtXMSTQo1X8I Pj0VbUEP4DXAJmAbJpBLp8bE2FzRqigimrNQW1AxaVuW+ciEVqkwDs4TDpcbmvrGxoGGt/QALS3V UobzAfi52hsaYtlcIp93O5rn4yOJcNt1t12nlJ77znBl12O7d2GYu73tzTdsee+WpirXkqzfT9Dx Od+txU8M/Fd8nMgXY/FKFN7b0XpVmy+ISf3ow0mqrafjpm0d1yrcOs8ytotWMthc0pFLAlEUPvHF iaZpszpc00iRhw3Ho/9lVihjnMI1d0y+6x2pxsJGzJyaYZ4m1e/T2l2K1yu7nZU1m0tues5vWfqQ FOX46FiR592cIx+LDp04PrtNvXVLVJW8ySW1xPuqsAnYhgm8Viz27PmaKK8OxR/W3D5Opzm/NuOl cxkhh6m5LFsoOpuaJZf70NCwg2U7wg2NPt8yuiVeO+Cg1rW3wSQdBgukCjUfn0qFQr0OxolV8vCE dG3Yftn7NrW31j4ap10e3Jzjq5oy861GOZU9lKo+Ybvab/udnW9v9rhI5zV3Xv6mJ44/GUs+83Tp eIOv5+ad19uRWUsSBpuLAAdjWGNqc2vtDiSUsq+g8RRumHInjdmP/36iLSAHwoXO7krYT6ZeNN/p Dcfv+eOhLU06Tesso9OUwnAKuywJWNO046PjqWLR73L5OfbUvpeFSmXOljW7Fq/Dwnb2gmATsI1p qPfYzNil6zoKPjRrxLpcHo+H53lkE6OIrWq7Yl4u5ulVvTkMy5UriVy+uzHc1dQIU1PaCoRYyMO5 2ECKYNFMNuzzhecjBk0qDP78+W+eyEXRU62y/+jY7o2t7/CxM2/VTGJIwnrZ6S+2h9ZmSjFBLsEn jU2+9FLfZb+z/QYP47l25xe2bn7/gYMPPDf03Ghs7JFn8MDbv9Rsy6gsOeCyt0n2BjAs0bp35OSb ezBDaTj+wrYvf41LZPNf+peC2caTvvbGwY2tZ95DWtcGSYuNbbnOefHELCZgSOmPRGO5HEfT12xY d2Lf3tjY6EqtWWATsI3XCjS7RNH/wL7BYBDuCtgWRbFeMAuVn5MLWSkZkxxOtaFpMKIMxeKmNCvL bl/Ty5qBEjhLL1QBg/YAACAASURBVMu5eQ1wwGZEsW50NoYHItESzzd4PRc4+xZL448+89VjqTGK Ca9Zf+82et9DR3493P+vj7oa37P9plpGb/WHJsmZXmR6w5ZN997Q03Dy0IO/HnwyV0oePvbXFfXz b2sTnj6daGpe39Wzsyd14khmTNYimYrUzMygbxuLDyncVu5ZFTidcv7l3Xf8+g0KH+eOn4QzbwRb ZGpq8qpNewuuWr4QReLGBwL+HKHBBaLRkqaEGgvtbeqyWmvQDWMylYY/lqKu27i+kEr1Hz0ii+Kr v3N5wiZgG68VtdB/MH/9fj8QLWzDhizLZhn2Ot81GMSSWUu4XCgWS5FxkWHNqiU0gzW3HBgYZBmG pamNnR0ubr6ChxcaMEyA1TuRTuuaLsgyvJIullpDIY65oFmFJKU87tAGz9pAw21v23ZFg+OqYin+ 7NDekJ5Mqlgbjbk4FtM8DtocU2/ZuA4xclPAn8iJGIF1hoLdjWGD9m686iPbtt7008e/cSJxuolW UtE9R8YPdoo9Q5PMUGYM3vKW7e/r8NjsuxShuptH3vseStBantlP7XsWBmjD11DesDHzto8MXxlc dZDAWIdGT3MjKb7OShPmSsRbvvH5lrrX+ZvuOPZn/zfpXU6DfEUQx1MpgiBgfKAM49j+vbHx8cXu 1EXEcjo3NhYdNQU4YFmKooCJkVxlfcISbNT0OqCNnkqJqUS5WJRU1SMKZc7BulyU2w3NGn1+STVX T5sDAX8toWapAo5xLJmSVQVVAJhMZyRF8btcDI7DBCRdKIxEoxu6uy7kK1zeNR/03sy1bx3vbN/Y 0d7+7z+Qb/3Mhsve+Lv7c5GezngivimZhPE2ctWHrne77n6l//gVW8EQ3/Lgzyc//KH4NZ+8R/Sv VYVDTENvS3P7vz/JveOvTk8ee+uxfPY9f8GHHrsdCzGK/pO2nVf0rnn77tSuNfP1w9iYX+DFNTtP fqY1e/luTlINAlcaOwrbrkg3+QmZT9z6Lnk9nWj11b/BcHUe//ynVj1zIjAyTvKGuU7MYLrHx2/Y LC+3HCRZU0VZ6WoKBxyOl5956vj+/bqmvfrbli3sesA2XiuQbxmsW9kC2Lg19q3X64BtZP5mMplE IhGLxeLxeD6f53ke6RcTFO3fsNHR0MhQlGbVxvG5XVt7ViGnNIHisRftKKfBtObh/rfukUgmezoS VVTVirrENU0P6GpmdDQdj+kU7VuzzhUM7Fi3NuzzverHngNcMrnlFw8y937Wf++9R950+zqWwSuV UxS95ckn8vfdJ9/3LWhT27teVQ2Xq1+SrL3/IN/3TxpNO/7oU/V7h0rly577bf6bfy9/69uwl/y9 9zV+5SsvfOjD+Q0b5uc3snGRYBikpmM4phOkMXU/4IZOGJg2W/nV0Jy5DFso4qrZCiMwg2EVb4D3 upZRMQa4p/ojkZF44vL21tN7dp88eBCGl9nNYHyAqX8wGGxvb+/p6enu7m5tbW1oaIAXUVmkhe/5 ecO2gG28VtSk3dAjyglG1FtPwEBaoiiyLAsbwMQVC6rFW1V1LVWp9B2vWPcJ53IF1qwrYNgLx/vQ 2+H+AQOup6V50aU8KqJ4fHQ8M5V9qFsTkOs2rtd4/sTBAwPHjw2XSqbvHY7dqspHbdpydHj0jdu2 XMiXio2Nr9zz4evvuefxv/+G6nQxP3tAdbkmbn1T7Kqrrrvnnlfu+0doU9tLPPYolc1OvOe91t6P mHtxfMbekXe/Z+L6ndd9+GNo7zVf+uLjX/krxe2Zhx/IxkUFjmvUzIhFAyfmFnbGST7YCH8L0K+L h3g+NxyLex3c4V3PjZ44rs3FvisMtgVs43VgqpyrgXzOc9Z2NesHiyKygMH2jUajYAfncjmwgGdX dwBoOE63d9JON8OxQOwaTqiG4WQYr8tF4Kbx6eRYszYiSV684ktlURyNJ+ArRFnWzEPDVF3LlSvQ PZamHAyjSLIkivC/5MkT0fHxOaveNl99nb+5+bYd21dYpLcNGxcVMIbEsrlYLgePhK5XRoZifcdV RTlbSCNYwE6nMxQKtbW1IQsYNuCpbQHbWOFARvCMnNcZHIyeAmWi2kpAuvAUbhhBEGasFkMbeAWs ZD6drFRGsqLo8vm9zS2606V5vLypq2V+iwgfoaq8JMGbQx7TdDOrnZKkphvwX7XqOo4BN4NBDrvg mYNhfU5HkRdQhBS8BO2BU82vNizlL6uWe9V8N4xELp/I5z0Oh4GdmVK4Oc5Dkl4SL6ZT0bHR6NgY isZkGWb20GC+TZFVnDg5Ora+q4ueZbvYsGFjNuC+SReLpyYnZUXlCDw9OJjuP4XK/dYkNWbcbqjI YH1xheUlvlEPm4BtvG6cO9sdWA2VHwHS9fl8SGW6UqkA0aJg6XoCNtmX5wuFArTBC4VSFqzmGOv2 uIJBf0ND+6qehuYWzsHBzXlkeGQ0kRxPpnCLUM31Y7Cekevb6g1wnqJWg7FdHBvyerPFEpi21fY0 hfaaBSemhGFVDcxvIGBzGIApdE+LmUMJpK5IUioWS06ORXO5E6lkuVBAAmEwpZizmChyCejppNoQ juRIj8vV0Ri2SzTasPGqKAnCQCQmSPKqhlD/npfTA/2GrtVU9tCC1wyjFlnAHo8HVRhEVu8y5WCb gG3MM9ANg9KFgZngbkHllcDYrc9WwixtS1EUS6VSrVA2NAY+liWxEJksJ+L5iXGH281yHOtwaDrm pCgGZr4OjnM4Oaf5B7tIuEWxaTderlwejMbGEknLa90acLtRAzOCzAoeg8+HR2BZWTMjyhRZUmUl n04c7e9DDeBRqJT5clnXNOgS3OqMBaQ0O4ODEfvCsZghaRNjUlfPYCwO8/PGgH/5jQc2bCwgFFU9 PRmBG7bV5x3e+/LkyRPwYn19hfoCgrU7DlVs83q9fr8flQGeXYNhucAmYBvzjJqgNNwYKG0JJqpz lleCFwVBKBaLtfsHvetMYrGui8UiUDRac0XvnxZ0bWYXMw6nywn3oct8dLhc8GKDLKbhHeXi2MTo oCjKogD/AdEaVgdqfi1iauYMzG+5ps2PRD2EKbfH7UZS77XhADZQUbMZRnDVkc7zpXJZSMZ4hu6P RDxOh5O1c21t2JgDcJedmowUeT6ZLwSdjrFX9o31nUDSAqgwuccCWLqzi/jCNnKwAQH7fD7UxiZg GzaqqBnB6BHYa86grVp9w1p8NdxLtVit+pbo7ciGVi3U12vSZamchb/MObrEUiRLOWvdQ6IiyMeF jFqE+regV9CIgFSvazWgZrSEDpvsWyoxmUw2n6+kkkWCVFZs/qJBSRIpK7ihEbygu4OaXm45ccwf z9JwQpt6out7y0GPSqitLz7RkiRVPOM/Ncilcriqa+HVmR3XjOzYnG9wLVbwJ6EptCDiMA+TZYxg JR/n7zvUPJFkK3Asofj6DfnWRonB3ROnuw4PYozqP3HKmUqRZclwBvkNW8d23hjpbZg7FNnGawPc vMPxxFA0BveRkyQyJ0+MnewzAy2tmxERcNAC8Cuq8ltf4wiNKqgZ2MHwiGbGy5GDbQK2Mf+or76J CjzMGWwPPIpuG8xa14G7COa8omgGXc14ixksPUW9CCgD6vxi+OsLmcGdXF+pu/4Gril/1SzgegKu d0GjbKtsNotESCRV0VUlVyp7OG7ZqcO/GtRA/6G2F/aER6OEVHS8fFC8808Ht2Qu+6vvTE1JyM6u 7eOf/vjAlf51X/mGu8zXv5nG9rX9+inyw587/vFbhUVYItedidHwvr2dB46zgkhOjNDOq/d++Zbt H/t0bRzsxBpzn/yD42+93vf8U13/9J8zQumYXY97fnxU+M1fppa3jupiAqnIjcQTHMO0+7wDB/aP HD2CMo7QLBwxK1i3jY2NwMGwjYzg+vuoJkrvsAANZt+/ywI2Adu4KKivTHI2mqyRNJrSgomJ2BfV PVwAAkbsWy2qOCu6qtax2qIUGgjQrV5rhgi4WCzCNhj0pv5XoQgH0j8ZKVQqPperqzG87MaFs0Bp e/rb6370pGswXXuJemlvsNOsbahcdUuyJxA8tNvRv3fVt0Txzz6OmyeHVlqvyN+8ruLkdExz5JOO ClvY2KIuwu+he0b3rf/+dxp3nSaUmnPCF57ogEFQDzYWb7jZyA749x4LfO/vLs+VslU9ldWFd15V 8LlVEqP5vCtTNAJbF2PqsEIAVwRMTAdjMbgj2t3O4X17ho8fq+X7oikv8pnBXBw4OBwOwwYycOvr xNR7sGpz6OV4l9kEbOMiYs4sgtltav5nMB8R185gVrTuW3NBaxbOZli/ll4h93LNBY1u79kzaGTs 1sp91/zV9QeFhEfgEdi3GpMpS0o8phvYuKJwbIGlqZZg8Dz6ucSgtTz34w3//HNHXFHWbIq89z3G 0DNdP38ew1jkj63cdPupN13JRW9ddf8/tv62r3lkjDajzx3Fm99x/GPXSjRlGDolC5SCKU63suBD JZca6b3/u43PnyQUrPCJP400Sa0//7H/FK1Z51ELN0d+/6NJptz8+Pc3fOdx16Fn8G0bzB3rbzz2 hx+ssLSOY4Qq0YKM066KnWJ2vhBl+eTEREWSPKryyku70tFovYYPNp2DXS4XWgwGG3fGuk9t4l7D cjR/MZuAbSwiancUbhVZqg/Ump1bDNCmcA4ZkNeC+ru35nyevYBUo2R089eWimfc6qgztaxE0mqn plK5sRHC52/afnWuXFkBBOwaebn33x8C9lUbtp/626+Ot3gwbWfyjknNHXS+eH8ntKBZyeWROtfw jSEMO0kauqU8imteh+B0GLrKyAoNp451S7NKK15s4KrU8vj9bU+exLWm2Ne/fvjaNRqhJ666wSnQ Je3wWrOfhMa5yuFAsbvD1JvCJJS9hnnYiselGAYF7KtqFMkVPMu1gshSwMnxCbgdjHy2/8ihUjY7 u8GM5SHkfKot8dY3q20vx6XfGmwCtrGYqNEbMjTnJFRjKgS6JsKFZs0XQsDY1H1bi72a0wJGqLXE 5rLp5+Rmc/jWNCGVlIoFMRSUVRVVDl6mwKVM138/6uuPYa7A5Le+NtrmNl8l3Mm160mx2JBMwDM6 PhE+RnY/+uPwI3sNx9p0S1Mr/ApiIfzA/739eY4cTmJWTTll87V9f/nV8VbnQvafiexf/+3HcZrL fvbeo9esVc0SBWQ53FbGsNDLEfMARd47cHTDb/eu+rcHMJwWG3YWfKJ5kPu/e+unnycm+vBE9aPS 3/31y1sbFrLzKwCqpvWNT8SyOVM+Pp9LHzvMz8W+CDUORmMCOYU5Ja6WL/UiLONBwcYKAGKsemmt s3FqjW7Pm3fP9u3Y2V3lM5aEz3a343VBZ9PaGIZSLkXTaQdFrunoWL4SlVwq4o6PwYEJH/3qidXu +l24rtHlHGy4fviNHT8EVqbUjnWZt70z3oR1GzqGE5hGYzlaae7ROFZjGGnNGola6EEzfOAZGOnU LTcNXn+1TE8bx5m8Sa3UyOnuz30KNoxAa2nr+vFP3kE/8T3zbDm9+EROY7q0XlbnGJXmSuxyPYmL BVFRJpKpaDanCXwpHiuODAtnZ1+E+vuxNv1d7lw7J2wCtrH4eC3rNzXSnV/18hkUO4+fjFlGcH5w gHK6RsAkNrBQINDov6BaSYsEgymk2FwKw7zJa3trS3a4Jjl4TSFxA6NhV+XG6/JNftXjL27bmdy0 WsvtNp24DnfxHR+b3NSquZyK2624HKLbV/E6Frb/qm/gKJjofGurEJqqemnojCTqFGtgDAzyanhd /qYtAsMIvVvT1+3IccU1mHmg2rV39d+2SXM6VbdLcTsVzl1sDCxs55cr4D5NFgqKqibzBfiTKmV+ oD85NHgONq1ZungdFr7nCwmbgG0sD9THQC5uT14XpHwuN3Ca2HjZcCIZLRQ2dXc1+v2L3anXC9yg aJ0Clq14xtPYKi/MLLzjfd0P/MIzmS2979NWSHEo/da7B67sURlGsWrQ0gRhFoki2dLm64Z3trzK N1zk/qsO4F2dKZYoXsZYllBKnU/+qvnpfeoN70qS0H1Cbrly+A8/kWMohaYMHCNE3LAcnnr3tqGb r13Uzi9XTKYzpyNR1YqalHOZ7MBAJRGrCd7N6XNiGIazgFTnzqYFvZJgE7ANGxcRhq6XIxNgCjvC YX9P74mxCYokg55lVg1QaO7k27uDfQcCf/GR297wNomfcO4/SIkirhvcznviZhNCpVjJwdWqzxKK bOqXGQZskIZGqBpuaLSo6JxTYBZ42CGTO29d+9NT3IsPX1VMlzc0Ox5+hJElQla1hmsy66wIA4KW WU6uZfcaOq6aRURwWSRNApcJ3SAVmcKZktNWN3sVpAqFvvGJiihput7VEBo/cXzylX2GJRFPT2FO kWfg3Zq2BqLhsy39rhjYBGzDxjwAnxLgRJWSkXxHLWRMyaTgDwYSo7tnIBLrbcO8Dge9fMKyFF/X 6LvudE/GfSej3G/+24wDplnVHxLe9fmDb13V/k/AtyRGTNPkVjxNCkdQ2XTrF9/dWvdRwo4bjv// X4t7F3QltbD5nYO/v7/7wSP0wecCB82zpbu84o7rT37wTVrff5gtSKq+8wbFyd6ATmLUf/6ft/zn tI8affDFY23MQna+HoqqKpoG1LTo1bLnBC9J8IfYF0zd7oDv9Iu7Rk6dQrdGTVFuhshz7e1IDAAJ TC5rfavXjmUzBNiwsWRRy1ZCPjQYRFwuF/AuPK3Padajk6rbEzerH+Y6Gxs3dnUsn9BoPLf5ziN/ 1tb7wwdYQTJwXOtcl779LWPr2jGFL6/flhLJTGuwfnFe960d+v2dXU+NOjNZQjaVtjESM1hObWpb +BrkOu0avOcrYvihpn3HcZgUMRx/81vHd15Z8HC+4rr0zp3lq7fzdafCoN3ZHVcn+oca+uNURQZ+ NnCzApfu8M7IW11ISIpyaiKSL5d3rFuzpGTGzVR4ReFF6dDQsCDLNEl2BAOcyO9+5FeZRBzdHag6 C1i3QK7wiAScZxi4NRmsWhvkiMZWrhcaX/ibwYaNlQSkhFUulzOZTDwej0ajyWQym81WKhWkK1If PqZTlO5y6y4P4fasamne2NW5NE2Zs8LQWEnVCVyjab0mjq+rpI6rFDlzKDHk4PCAb3yC4uEnIDEa g2PnW1dlulsWXojD6o9BKyquazqY72StBwYjyhrLzpR3NjRnJt4w0M9mBTPKjMAMB6N5mxJbNgiL FAc9EImejkRbgsHLuzuX1NStIorQsWypBBzc3hBSi8V8ZGL0xPFSPo9Z3AlcC+wLpm1DQ0M4HA4G g8CvtRpoNXKtSccjCQ5ATWZypTqibQK2YeOCAHcQKsZQKBTS6XQqlQL2LRaLgiAgaZFaS7CGoaUg iryuC6FG0uHc0NGOihDbsHFujMQT/ZMRjmE2reoKLY0YghIvDMXjcAOIspIplfxuF6mplZHh6Mhw Lp1WFQU1A34FTgU2DYVCLRaampoCgQCwbM3ARagJxCJPElrHmSG9vsKwhKZRNmwsU+BThRRhXo9K qvl8PjCLkWhXrRk8FUURbOV8oZDJZysMC6Oqg6EbAwFyhU7wbVw44BrKFksnJybBWlzX3hZ0u1/9 PRcZps9ZlvvGJ5KFAnrud3DCyNDgkcMSz9e0nRFq6bzIukWFFsAI9ng8M+r41uvT1WRiV3Yykk3A NmxcEPCpmg0Oh5neChswtZdlub5mIgK8UqlUwFAGhjYSCSk6UWlp33960MlxV/auDngWf2C1saQA 106uXDo+Ol7gebjMettaGrweVOaSXtjaA4Y1fdStixkM31MTk9lSCS79kMd9eWvL6KlTB556HKze cwjaoDgsZNrCneKyAAbu7DKgNaXYFay/UYNNwDZsXChqEVi1YBNU0Gk2AYP5C8OQoiilUsmRz+ci EzrH6f7A8bGx7Wt6HUspssbGooOXxP7JaEWS2kJBQjfAAj40NKIZOvBhT3NTU2DhEsp5URyOxStm 0REMqJemqEafTywVmULu18/9NhGZRAu9c1qrQKLcFJCwMzMFVNxzTjGcFZ8BjGATsA0bF4raBL+W blFTq65vBmYxNAD2LRaL0AZGHz0eLwkC19mNE+SxkdEmv9/AcbBy3I4F1oqysYSQr1RypTJDU6lC EdiuLRQKYPrpvmN9gkB6TCU11ucHLixUKiRBkBSJYziYp7DdGPA7mHlIkUoWCkWeJ3GCIglZVYHv i4IQy2RdHEeRZMjn9ZJkORZJne4/PDqKW9HLKMe3Xseq9mmIgFF2r9PpnFa2ZEpE/cL7vEwxDwRs aArPi6zDCT/phX/a+XdDqRzf+9yJnO/td/w/9q4DPooq//9mZnvv6b1BAoTeOwIKNrxTz4KKvXf/ tvNOz17Prmc5FRUFRcWCINJ7aIE00nvZbLb3ndmZ/5udZFnS0BODZb7yWSezb9qbt+/7fn2qRPDn faM8hh7cdBOtqgQ91NuLgFEDJARzE1DU+kWHQq66GoFC0Y7jXU4Xmq4Sddr81FQ0/56SZ+FxahEI hWrb2s12B5IygxSlEAr9LU2lR4q72ttxxHEytDLDZHHx2LD8oy0tOKejBYxmGPR/JCtnJ8QTMXE7 vUYgN+TCaHV4/H42H3ukNfrwBIMl9Y3+UBA1RaeKaLwx9JVJo8lOjIdw+GjxodKqSktbGxkKsd4P PT5T0ejevqUD0ZhXKpVarRZ9csFF/VL1nxC/+EfOBPat+s+9974w9p9vPnHF6WLilPWmt61y+UsP v7NJnFK6flqC/MQH8OBx8hDl4EHCCtBXsav+aLZbyuczF+1FMygSZ7R5w5D0jESNnKTEgc7D448K RI0tXdZ2uyNBq8lPTXE6HHt/3NBaW0NTVDdpURQ7YMyoiT32QFwo0BaOre8wt3ZZod85mEFDFIxq dYrBcLi+gYrUiuwXNM1Q4XBuUlKyQc/t8Xm8na0tXQ212/fu6upo93u9oWAQYpyWEaciZkUyrlwu j11cRtXInF1GrVYjDuayXHGZsOBPoGQeHL+UgOmA51DNgS3NTc5DreSltPjU1XsJkUG70+mwaU9d oDwPHoNNKLFFk+D4AojhUJDTWrvq60RKVQXDuAMBtUyWZjL+fmso8fjpQNTb2GnpcrksDqdMLEKC rLmxYcMXq31uN2fU4IJzODNHX50tGjyBmiphShoJGMHmeRSIRSwLhsIMTuCcOoakGXSJJksXWgjK JWKCG4qs9Eyr5XKvP0BSiHnDAgwUYrE0FKgo2mtuaTG3NHtcrr5JmyFCwGgDsS9iVl0EaCMauRtr zeXcrxD1KiPgCJgYWj+y3yZ+sQSMOjAyGGTQ/8LrZIAJBfwUI5RJhTQdDlM0IYqtKMZQrNc75rQ2 dDRVA0zlAurDZNBpt4WFSr1G/jvLdcDjDw3OTszNp1ykI5o9oxHDjNfjqavBs3Mbg0GhRGJzu1ON RjT7quUyfrb64wHxrsfvD4TIhs5Os92BXrRUJIwXi/dt+OFI0V68h7pkPeCYuJeOFxFqOFLzgLR0 BCPw9TjhQ0T6lEhlYrlMKJMzUjkpEhNMOEUmkSlkaAziEVMsOtxPh+1uh9VstqIb6eo6QpKcayH6 RHJtv+mo0Ldc4iok13IZNjgBl1so9AouiqaiROByTPL6Z/i1nbAC7o5d6zbsL6/zgyY1O33s5Omj svSRLmcc7dUHDh21uHyESJk5cuyY7Hg02qigu2Tf5k27Sj1+UpSUM2PChLH52eJA7aOPveYD5fTp o9vL9jdaKeHw+Xctna8VMm5z/cY13xbVtzAg8HdV1lgBkpJNUiQxhNsOb3/5qVeaEhc9/6/LkzWS X/UxefD4KcB6Ko1H0/0gaYCLGz4uZUfATzbWo+mN1unbSbLT4UTTbUFaaoqRrwP/R0OHzV7e1Bwk SUSp6XEmhVDYWl2578hhu9mMeBWL8BYaKmicxGZI7hU+S7NySTgUCiHqDQQCfr8fbZAkyaVB7baJ kCTldGBOp0giCQcC5dWV3LfoAmgliBoHfb7oCFTIZNF43NgSgb0kb87znzPuIgI2mUz9EjBEFp3R TOlcMYY/fIDvT8SvScCBlpcuuOy/R0ob2iwhkOvj9MPGTHnk5f/MS4dNnz72wvId1bXtLn8QF0hN yWmpf/v7p9dN2vDB0w+//FFFTWsgRAm0cbkZU+75+6PnjW145Y23vAHys1Xx7vZmRxBA/5Uobv3N I+yvPfnQ2yu3tTg8x8xuEzVqEXqpjKe5sWj119sKUx4OUoPcIw8eQ4aoKBBNR8D5ZPVK2cHFL6E5 kbSYKbdLlZrml8gqmprRrDaUkSc8fm04vb6K5hY8srpSSCW0z3dg65ammmqfx8M1iAqOiOR0Oh0S MREHR7Mo90vAPp8PETCi4SgBRy/HkTGnbomCG3hoDQjyY34z0ZWioAex7sqxmSOjKmh9BFEzcF9+ jdpfBqLzPydOGgH7IsHaMQhvenH+o+uOqvPG3PrYLcXL39tUVX9wL3WotlN34L/3/+OVfY1BzYSL /r50YtHK5d/s2FIsObt6Wsey/3vBJkm58q6Hc12r7nvtSLl9V2l19cK8AKtnJsnmBvusRZcNC+5+ b3P18o83pk068PT7672Gcc+++fBYpfWD5+9bvqkV/ECx9yHInHP2K1s32uRp6TrZyXpGHjx+CbjZ h5N9EfuiiQ+JAmjG5ObKaDNuikRzKPrK7XZbK8oUmdkBpbqssckXQlRNGzXsNHwKH4THL4Hd7bGz 4eBEVXNrkKKyExOSdNqKgwf3bPrR7/HEpk7jrKeIgLkBgxgOCZqcEEwc7xnAZTkN9AAxcZRcY5tx tbk4to5ycL/lJaKqmmh8UV9O5dYHXFYNrsoC2uib4RmOj+6NdX3gcdIIuDBHJ4h1gQ42LH+q1QuQ JqHavvn6YFU9JhTr9Zp8vfO/n+wraghKTnuucsNdRsbxfs3BTTsOhTCo+u5Tm8sPSQn+hkP/XF2B xp40Jc00PYyDJAAAIABJREFULF0hamHtyxg2bv7pL7z3n46XTv9wW7Uv7OgoKfKG0v711L9vv2Cq AIJib8f2TffIR+foI/EbYrUhf8oMBsOFfEgSj98MOK0dmkPpSHlUtMHNlbEpO9A2mh+5nFmoPW2z dZUeEaamMQnJJbX1aNpTdFqmFwxnp8g/ep6gPxK4ZFKBUKi0qcnh8aI3h964QSEXetyffbm6s621 r/88R1QcByNBE5EcomH0GbWhdp+5R65lNcnBIBo8aCOaCib2hFEC5hpzG32bxdpKop99o4ai+We4 24vG+Ead/Pt2Aj9ce+GXEjB6gQGXC22o5dLYARG01HzFsIv68rKqdlNC2oQphXMuvvO2KzLDFV84 WQf6Bx483wgQsrXv7Wy2AMxfNNJa8h/24IqtaztNmfmF6anTbn7g1tMmZnR8t4EOU1JN/JnXPj7W hK8FdqyQPndLRyVoRifo1TircsbEQMgBvB4/SUfypbXXfrtqRSM24qorFxuVfIIhHqce0cmUtb1F shP0K6mwHq2RlNFoLkPbqI3f73dVVXqtVrFQJItPcKvVmw6XSMWinMREvUopOt7exuO3BvS6kbxp 83iONrUESBLxXarRoMDxttbWtgNFe6uq6Ij+o+9LjCVCNGy4WFsOvYysHK1yhBodUb0SsUGPFppr xrXvtxkWk5OZU0T3y6mxmmou+iiWqk9yJ/5B8UsJmAr4ne1NwEYBhYJel81ha2upK6+oarM5TCTt RMScMmzprfdesXiS1NW4btV7JVKpn2LnmvqqOsd4zf51XxcVlaA/R2bEyWq5Eh+mc5beftWyv6TJ PQd2rvm8a1yey4tWjxKJcFRhEvqaU9XhrXZV4QjYVrH6ozWF6aoksXXX3m2dAJ31Le5wWAu4pXrf h8/98/vWqePOmDFfafyFj8mDxy8H1pM1GiLJg9B8GpV9exEwYlw04aL50efzcWmzUHt/R7uHJB1t LYrkVCREhxOTjtQ3mDQapUyqkcsRE/Pe/r81IFqzulxI3nX7/B12O6KmOI0akJDa3lZeX9uIqJem 0U7hAEuoKOOKexDN4NiLgKP23SiOuV/F3k9Ps1jq7dsyqiWOjVnv1xE6StUcEw8i+/LoF7+UgHFC IJKxSeQ3vv/vazd/6HY6Ozuaausb7cy4u08reO6bA7TbUvzDqid2rupsPLptX/PZ5//fuPgcLRR/ +ew9zo1ptcW7D9da0eGmOPXYhUuS39zfAuHyfdtebz/osjQePrTPcNq9j86kOPsyxsq+hFafhmG7 sI625ItPy4G961b8u6tlm1HoKjm4u/PYfWHqhLQR0yd3mvMN8pOQm40Hj1+O6KTGicJoGu13+kOT I/cVomGFQiGXy2UyWTCS+gAdxdJzU0MIsbjHLTLGddB0q5WRicUmjRrRsFouU8pk/Px3yuH0+tx+ v8PjsThd3kAAvXSdSpmoUlka6hoqKjpbW0LBIBfGw42Efv2SuCAfbgwgMuZ4t5dLFIdo5rXYHKj9 5oSJDrmo4DtQ6ph+w9b7toHjLbs8+/4s/FICZugwHfChjaqirVVF0d3pZ197yV2PLop74v/ueemz bd9/xe3VTbni5gevHq9q9xwse/HQ/i9q9kcPoBk6b8EN773rvOuRZ/bvXMd9YcwadcPVF4xV7cfY AQcKCbpbIiE9BSdwmijJPffFl8T+O558a/+29TEPJIzIAZgua8Lf3/j6blqk06p+4TPy4HGygGY0 NN9F3aH7nQE5hyySJLk4JZVKFWCT4DNoOuY0h93tPG5WUm5vNWRkBgWCBnMn+pGIBIKcxIS0ONOQ PxmPbqA31GzpquswB0kSiZlSkWhsdpZcKKw+cnjDN195XS6KJKOlgZB0y4m5UUen2FOhBpz7VTQA Kerf1FcShR7KHLzEe3TIRZv1276X21SvnYO05/GzgA3+tk4Mhqw/tOWjFd80BRmdLmFYQf7IgoLs jFS1TBxJRRr2WDtazY4QzSg0cakpxp7xFagrL2m3hvFg67OP3P/ljrj1DesWpLF+8H63rbmpI4yF GaE2OSVBJSHYxvsPOZXpo/IS2MM9rd9++2NIO/6shQVCAK+1vbq2GVNok5OThHQgREj1Sik/Fnj8 9jHQTw9RLJJ33W63zWbr6Ogwm81dXV3oT0TDsT6rUdcbdj9Na4cVEEqlw89uS0RCiVBUkJaqVSp4 vfTQAImTLq/vUG1dkHVvohCVxmnVcrE4UaNpq6st2rTR2tnJvfFeflUIXHKovu5L0Yg1nU6n1+u5 GrpRtv7l93zCyZ+n1V8bv5iAfyYYyt9UXdXkCug0OjH4t3/y8hMvvlsjuvhQ+bujDXy6DB48gAsC 9vl8TqfTFgHa8Hq9oVAoNrITbSD2RVSNvnJFgCZsTWqaXyyVKlV+kkTtUg1sbKZMIpZLJDwT/xpA b8ETCPiDwS6nq7HTghhLIZVIReIUg17M0J1trYf37G6uq2OODy7iZF8ufNZgMCBmjWZIjlUsRzMt o2+5akLRggd8EO0fA0NdccVvrnj5getf3V43PHu4WuA7svOgAxJOe+icbJVwiO+EB4/fLDhfLTTz smXmCEIul3O5jWIdVtFGlKc5mzGi6rr9+xRarSY7R6LW+nGi0WKp7TAjoSnFaFDJpDKxRCYW8WLN LwcTKZHrD4VcPl+zxer2+dArU8tlyQZ9vFrjdTpaqytrK8qbqqvRK2NNYjF8GU2vEU1hYTKZNBoN J9rix7fk4nyi9XT7FtDl8bvGUBOwQKYdOWXapCZnQ1vD4eaOxMxply+9+rqrTpeL+IzzPHiwiDpL oxkZi5RyQ6IPp3zuRcBcuDAX14S2uRRINrPZ3NqqM5lESpVYqVLHxwfI0NHmFolIJBeLERMn6nX8 DP5LEKZps93RZLH4giFfMCgVCXOTk2QiIeX1uJsaa1p22i0Wm6WTCoW4GvW9Duci0DihlisQhIRg RMBomcU5WMW25Lz2OEctzgOLd3T6I2GoVdDA0D63o8tq84fCaLqQyLQJyXEqzmDMgwePCGITJkRD NqGP7wwiXTZVltXa3t7e2tra0dGBhGCPx4P2c1TN1mqVSJAQrc7IFqvVJCFAszgSiAU4LhYJSYpK MRpNGjU/oQ8O1JWIcVu7rGKhIFLnIOwJBNBb0SmViH2VDG1pamytq3M67CF/IEyR3PqJw0AF6pVK JZJ9EyOIi4tDNMwVyu2bQyo21If3NP6DYciLfmO4TKVLVemG+ro8ePx+EI0A4abyvqkSgEt3Ewyi Boihkezr8yFqCEEkdqWvtThUX+OjKFAoxWkZAb+Pge5pvc1mTzbo85KTuELq/MweC1bJzy5/6Oq2 tmZLF9tjkfRVqG8RVSZIxba6qrLSUpe9uzQvx5HR6vS9ihfF+hJz2SUR6ep0uqhxl9Mw9zLu9vJG 5l/QHwxDR8AMTVJhNJucJFUzO/t4fcEg+nkIhDKVQk7wI5PHHwXcVMsFLEV39s1qBBGXac6ZFpEx F6o0UHJpLqOWr6KUo2qZWqNMSqbkimY63GLpkkkkmfFxSBpGNBxmzZaInjE2S79Q8GcoSIzEWSTY IpIMs3n02DxlqAM7nc6qljb0FfpTKZHEqxRqodBh7WqubWiqqyux2znXqliOjPotc+rl2OJFUWbF egrUc3WEuPoK/dYZjILn3T8qhoqAacemHz+op2Rzp1+WqTqWGDIccje31Jid7hCaawBjK1dKlWqF Vq83KqJUTZN2e6fd5ydESg36TyrGMfB5Gj9f+3aV3REgSYkiLjt97KzRCzO0J8hQTwbcXY4uL8XI 5RqdUi0WsJeg6WB1RZEN0xVk5qokvC8Yj98KohJPNHylVwMuQyGSpTj/rF7JpaPNuOT7XGkHp9PJ UbvHbnNYOnGJRJmcQojEIa2uLBhssyokYlEwRCIqEgoItGRWyqTJBsMfuxqx0+trs1rRJ+K/EFtc nBERAjSxuLxemUSsYGiPw06GgtUOe1dHu9vh4NhULOqd4SdaH1ej0XAF6tFG3+JFWE8KZc69Odb/ mU8j9WfDEBFwyHr4ha+easPVWOKZmaMTenYznY073/v8qf1dHhJYAmaXj2KZUqbSJF739GXzxUDb WotXbP+korXOFfATQrlKrp4y8frzx42zNP/w6vpXPT0nEu4x7qs/et2im0fFK/u9AZpCS/8vvt73 Q53N7qdAKlOqNeMumHvp+NQ4MtD4n4/uPCqc+uDl90/NiocwuW/XioMu9VnTFiZppEPQOTx4DI6B JmVO5EKyFJvRkCDQRr916NgaAJHk0na7nUuEiSb6qKDsa2xA0q5IpabiE/wiEUNRYpVKKpXJ5Yog gMXlsrk9GoUcCWiIHEJhKtVgRKw8RE/+68AbCDRbupCwiWR9JODaPV6XzyeXSJCAS7OJLGgyGAh6 vSGb1dNlYXxel8MR8HqjxX+irsh96+MiAkayL6LeaIF6tDziihfFEjB3Kq4sNJdgsm8FIR5/BgwR AYeDji5gaJoJ+snY/SF/R2vnoXpnnwM8C54Cuq1h/Qsf/t+m5vYAdeyoomr9nBGjQr4uxL6pGYvO Hze/8eAHn9cVb9/7Tpw+PXXRRZo+QixNerdsf/HJb97pdNnI6LyEb8HicocnLiZC9npzVYM8yxVk TWgkaVv7zT+/cY+ISx1+tibvj6994/G7RTSgBSLSMOKGYxVe+xAwl1Oac7LlNKWcqTgqK2NdnQyG 0RTl62jz0EwnwyA5WpmS6khMdvp8eI8s3ml3ZiXEJer1RB9lKVdkYoge/kTo170U9UtLV1dtW4c/ Yi/nkkKhj3SjQRKmnJ3t1tbWro6OMMn2DBUKkZEcZJwlniv7w2XM4ITaXhFBrFgcIWDOsRkRMOfb 3JeAsZ4yBtGau3xw0Z8TQ+qEhUX+xe5IG3X5K4+fT9G2l++d8rE/ODzn0jvOXUr4A6bUQnB3rl75 4Nr6JhCNOf+0q88eU0i52iuaa03ZcwxioTtyfGLy8HkzL0tfdOW8VZfesO6b2s5Km5/UCHszcGfT d/d/9Aw6JD3h7L+dfs1Yo6q99Ui9QzRlzBS5EMfVE1f8u9qLyTRKhd9hcwebW7rsfth+uGnf5ASd SmuUD07CbDhmwMda4ARSleJ/qrsUrCr6bmenePHCxaZfrgKnw6xaXvy/ZDUJB62VdR1xGQU6Qcjj cwYZhUH9+5Z1/tiIemlxn4gb+k2vj7iEq+4QldtQS84S3MtXi8sBwkU0sUblYNBaXhouOYz2I7ow xCeo84a5Gaa4rgH96/eWCjPT00ynPhFmp8Ox52jVQN+iTkg3GZPUSktLS3tjQ3tz8/YuJCAwURMs p/pH3SqM1F2O1iPilMboMzYkN0qcnAcWYlwuuAgBkTHn29zXuBt1qop1b/41u4THbxFD7gXdG5hU JkdDNyMOgwZcLjPl5Y7l8lXaOvcVVdaijdPPuPzi8VNlhAA3GHLyp6rlcgLHICISk1SYJIMOW3ub K8CmgRagKaafQdxQ/DVL2LIZ5y+4ZkZ2mgAnDMYzpsjVcrEItfaYN1zxj6XScXc+MDPvlrdub3N2 +zSuWn3TqtWg0Dyw9pnbXbVbln/74pqKvUEaVJrJf5l97cWzFybKmW2bX3r5u3cqnF3cIXLZDV+9 9FTSz5WaKcdnG577uLbq86JrH7r6usKEZOlArmpM2OVsKinf9OWWH6odVoFAO7Jw0ZlTTh+JHzjn 4ZvUeRfmS1rWlm50k4GUtLtevfN+Y6Dym+/feX3Le04QysR5EwrOvm7JVaOTDGTAun/f6re+e2N/ Z10YkoalzrhgwTWLx4/Y+8mlt27bpZaenqVvPdjCVqlatOiLx86bJ/mtSDU8jgMWky6fSwLcr9jH VXeIsi/aRiyCZGJEtLGHREu1I/b19oCr3M6FRfmcDl/RHqFaI01OxQiBiOBqSrByIUYQEonY5guU NTa7/X60DBAKCFa6ZtCGgKQo9OmP1JNA8iPazcnTSFoXi4T+IHsbSqnUFwypZNIEnRY9WIfNbvd4 pGJRIMRmVFZIJEE2hTI6DGPPSRDeYBBdXywUBikKfXIrCURz6KLoWrXtHWinSaNmPT+BCQWC/qAf Hen1eSkqzNite7f86ImYwzkZtLvMUESu7VXnACIKAy53FVd5nssHyemNe0nA3DIINUM9jJpxVB0N 3u1Lsbxv858cQ0rATE8xwUFaRCcQkciYkppzoKl63ZrbizZlqoVyiViTkJg7auS5f5s2rbO5HLVp by1atf5ZW83m7+uK5aphE3LmmKT9PJEuflSq+Jsm3/ZnP6pYLjXKpDKN3JidOWHepCVTsjLdlrJy KhDf1e5kpp0xfkmrzVpVs6XOTWVlTB5uNCqUhZaGTY++f1exJViQPlPoPlBs2fneVxZTfMr5Kea7 VjzlA1la4pzxWfHVpZtacHeIrdj0M/tFoL9w4VWta9/a0vDaA6/vWjjh2iWzz8zV960hQdtad7+z 6v9WVZT5sMwJWdn2rvLV639YVXzv5iu0TbQDKv5TIkjK0ae5zZU+//dHaudWr7tnVVW5wjR9rMxT 0lC89WBplzzvs2Vn793494dXr3AqMsZkTy+t2XG06dPX17m1pucZiu19p3/d4U5TdsLYTnvl2rW3 nTXn4Cw9X1HqN4pYQYrb05eDo4Ja1IqJKJZj1l4EHM1t6Y7A4/FwRuVeOm26sx3tCUWKuqNDEDsp NBpMrUF0RkqkjX5fpOQTjqGVMroiWhlg6LoEOgX6ExEq2mDjeSI2KUEwSIbD6IePzuYNBFu6ujrs DvQQVpebzRwikSCSplklE1oFhBH7ov/QjSAmZpkVA8TZrJcyMGwz1BCtIegwEw4jrpULCYXf5/d4 3E6H2+Fw2W3ok43U6nkQRI2caMslmeLIsl9zLOczhfqNc2/mCJjTKMRSNUfn0dq9nH13cPUyT71/ cgwpAQsIXDeIShMTECKjqGc8y5Q5Vy99Pq9sd3VzncMXCgasTeajm9q3b6rY6ZOsLPS7UJu2pl0f N+0Ctprh4qWnX7J4zFhpf7JaxtgrHgJ9cWNtvbkDLfvtzua6hnWHGjbtrW594Y5/aSNt4nUKfeK4 m9JHeXzOT5Zf/EapY970G5eOm4B+QNu+uanY3AqKmSO0WUcc+9jWQplAKMS7Neo0xSgyUv9yxsiz vMKM+H57NOzcuP6tje11MX0x8fZLlpm6Gwuyxy+7X53if/n8vZ2HPvjuH0RC/t1TR/c6B0M6dx5a vQaxr3DuvZfdOT01cdeOl95Y94HDF6C4pxalLppzz0XDhEtfuh4Hqqlxz7aG8gDAzKyZVPOX3Kyj k4uAavv8hxVtAHmG7EScLInslwhxmYjwdt+OtnD0LbdOTH7+i4dL2hrbXEHgCfi3jcGlKCymZhxn /eWIk5Nro82iyaU9EQxCwFxiELQfNUYN2E+Xy2OzoUYiRMM4y7tM5BNdNYxh6BqI0BBHoj+RrMmm A0E8hz5YA7ZEFmEtuYAIySR2ArN73DQDKUaDSaUUAMYmfESiM1sjOUiRISrEqsjpMEVGUl4wkdvA IrfE3iRLwDREbtdDUc0htkw51pNSSiaVon+x3cJZ0Dlmja3615eAY0Vbrlkv3+ZoD0fNurF1Bnmi 5dEvhoiAaZJdawsJPF6tGLARLhArEqIMihOizKyZqSkTvQEfq4QKhxxdpe9+99g3ZUc+2rRleAK6 c+WEMZcuGT/LoDYk6lMTdIaBNLdCqWnqlCvGjfX5gsHIyt1bcWTlyyufrG5eubPxxjMjV0Q/KKFA KJFJhUKBSiQGECvlGqVSjYes9XUH2Rb+4nWlh5xBn1Y9+cpzH1o4PE8szHrhgjv+vurfrR3r31pT bFTnXrPs7X4rMdHe+te3/rfC0nZsF3b0bxdECRi81qMfrPxHVYDdzsw5fVZ6ct+TUEF3S1ejPQxz Fl17yeQZBOXaIwx70OIjI1MBfvbAjDGXzD1vtB7/6M74IOC1tV+1sI4mUHTkbb/XgovTF0275YZ5 00KWH7dHTOhNbbubqUAQICvr+tv/etV4E7Pczh5g1I268uwrCkWlIgHvgvZHQGwEKkc5Ud+rXgTM qaCRhMfpn33sL6Y7qOk4CbjHVIzY1x8Basax8nHyN8eH6BKRlF5cg2AkuBlJ4xCJNUYsjUUYCiLB UehKQSTb0mG/QFhP4HRP3XiOXLtPzqYR6X4crOe5Yp+XZcEIEUqkEkIhj43w6cWXXG9Eyz5yCTH6 sma0eiCXYaOXoNzr6tEMKrxxl8cJMUQE3NF4iKYpNBBp7JiISoWCuEgc+VvECpPoh0kR3V8Hq+++ fXJl8oVPXPf8SIOe20f4GhkPSx0+P+fLLE5LGj1n0hnqQS2UzdueOeOj10+f9+a/LjxdJ40EKYUD zQLMxWrDvT6SgojfFOc5yh0S+V91s62BDI8TsXXRIzwWdiWkLL3v3NvOGJUjCFNsVhxcPOP0h9dN v37D+tde3ry8tnXjv55flvXs1wV9opFx1eh3bl59tMsRycouEglFSm18ds9a3Fm/Zukbd9V0WQD0 Uybc/49Llqap+nGhIv0uT1cT2kg0GtFr87mtDUf3UqwDp56AFoj4waKJAcNFY0fMoYO2xqpPqMiB jvCIa86/4aKZc+PlRIjGQrVOf2S/n0k4beo1N597ea5OjCZOCLWbKbZTtElLpyWqwNIzk1KDdS+P 3wU4ySyqI+3XWswRMGJWztjJibbRoKZeEjAiVM5ajEg6qtCOzf4BPV5d0YSa3Kn6nq1XS3Ektxe7 RAizI4/TM7Ee1z3ExomY3Ge/dexjJVEuhXLUYzmWDjkC5tymOJMt2ogl4OgJOSrlzsa5Q8eesNel Y++Bp14eg2OICBjHhayaiArUVm/B6h3V9aX7Stfstthmj7l7QZ6isr68qNkPdGjXnuvnH06hSPlf zzpja5Dy1n782PvkJdOXSEL2w6Vb1xevbEM/SUJ/2pRJUvP3wK6wu9lyYAQPHfiKpuxrt/5fIFR3 9rA0l6V2x77Pfmg8gr5TqRZOSY0Hc/9HukMsJROELCt9GNHSHoaCORPnGKHmw4///emOj+Ujn3xk nPSjPeWpmePH5c2aWrXj6+qDYfpondVXIOsnH4g2JX9KSv8XogKhBHUKLks/b+HL50/OH6iasURp jE8pFFZUf7323cn60NGtT39cXY32Z6cZIULAx3W4SJ4RNzxBIGynyFGjFo9JEu7a+tKn25aXdqZ/ /tIzE6WyIr8vMSF/Vn5GW+23H77z7uqjzcuW3EFxAobDR7JrIiT/svPaocqWi3KGD97LPH7jiPLB IJFCHC9G421kMhlHnH3dqqPuWoEIojzdWwLuacmxb7RNrNgd24yj/2j6674JOKMEHK1MEGuv7UWZ UQKO1rrvVwLmdMuyCDjLbl8bcNSCzp0nKt3CAEZcnnd5/EQMEQGLRIiTMJ/X8tIHFxy7tiBFGixZ t3PntqZ2bg9J2TvddsSMJf57Li+Y/EnFnpLyVfeVr+o+AJPodXmFo659cE5+5WcCwMQEIcdPMNTF 0xfeOtr8WHFn46bN92/a3L1XKFRnJo8/d8FtI3Vql4X9IeEY9PxqOF8xmVaiQD9ZnJCMn3XjzMbG vW1lb6y6kmshlaeMTkyyNX393eHP4fBb0YuNyrl8gukE2bj6Qj/83CeunYnLdFr5YEFIuEQ3cdj8 SQd27ulYccuzK6L7yTANDCt5oImBiP7yMXF+9rxzxu3+8OCmI0V331jEnUIzLHuMRpp77ZnX2Deu qm5a89BbayKNhTrdzFRjSn1EP4FpFOg+hAqTUcQK6VaXk44IIjx+74hy8EANOHrmqAvRcKyRuBcB cx5biIPJHvSyKEOPXMu1jK0q0VcCjjY7IQHHxs5Gw3v6SsBRmbUXT/dVF3MMLY4APXI0bWS/oi0W 43bOsyyPX44hImBlQuG89ElHrA6BSK5RGhIMCfH6BJN22OjU1JbmscMs9kgWAYmg+4ekmThuStKs l1KKvj3S0mQPBDAg1CqjQZ+UmTxh0rARWrGAmnD57ZrOwvxxshMxgy7/Lw9fotpUubvZYvaTjECs MKiN8abMUdkzhicliAmcSZh129kPJKVPN4hZkyf6SeaPOPNsfPqsnHwxwdJycvrsey97YVdlUZPV gxEMJlAkJRZOHzVDT2bcI81u6ehw+INSmSY+LnnG+Mvi/5dAYKHeGPdTmuUUnHnrpeLRFfs7XQGB RFhe9mWxhYlXqMSakYtH/iV12MJYJ3BlXMFlS/6VkjO7saMlwIZxEipN1qRRCxMFuHHu3f+IG7uv vsTJKvNpuSIuK33G1GG5zeQlAdOE3MJRQpbBTacVnukRZo3LOPVhnTxOIgZ31+ISUHM0DAOks4hq jGPRV1CG43XLUU4diIB7VX/iju11e9H1QWz+ioEMsVG2HijLI7c/Kiv3q6nu23U89fI4WRiqcoQM 5UDCbYhCEiVabkpEEolYKhIgfmPQjy5Mo988+g2wUmjsQWhN7Pf7STrMymgCdoEqIKJ8y7DRhPhP LMHAUGTAHwwiWRH9KMVCsUgoihWdwxQJuIDo2UWFfL4QLZXKhMcuB3SYdcCMJBMRiNi0fJHz0qQv ECDZqunokaTCE8njJwNMKMTGRlpbtz74ypUHvSOefuD9s7LinS43IVbIJaLed8DQoVAwHHF8YacY PKYDkbxB0QwwSNoRcmmxwyFfkJRIZILIg5BBj8sfkiu0EgE/4/zpEJugo99vOYKMfvZrVAaAaJuo iNwvT3MW6KiOOir+xraMdW6KaoMHMsT29YTql1ajQm1ssNb/1GE8ePxsDHk9YB7/K8L+jk++vPf5 rTvzkmbn6ogNBz9lM3gmX/PZLQ8VGNWn+u54/OnQS5YdaCZhjsdAbaJe2YPwdJREo75XUU7tVyrt ZR7ul31jt3nq5THEOOWZsHj8VIT8bq/TIsZ8FU1rjjSECFwep5ty9eKl2XqefXmcAkTJb/BF/AkZ Ovr4Zjb0AAAgAElEQVTtCXk69rqDM2ts414bgzfjwWMowUvAvx8wZFvzkW2HtjS6nM6QRSrJXjD1 wjHpyX2Uzjx4/BbxU6aa2DYDtf+JnPpTGvDgcWrBEzAPHjx48OBxCjCEBOzsgKAMTH1THIfB5QOl Ak7icpWhwesGQgrSk5RD0e+EpiYw29gYpZRcyEgAfm19Qjir4YNvYeYFMDrpVN8KDx48ePzmMFQ2 4M4tkHMmiNSwughmxk7HFHx4G9zzOtyzDe6acdIuV7UOhi2GK+6CZx8DQ0xWqaa9sHwtWBzstlAK Rj3EZ0BeHozOB0lP2kVvFxw8AG4KTJkwLAcUAqC98MQD8NjrPWeRw9IH4LnbwCQ/wW00HIGjdYAp IDsX0pOB9ammoWwXvPExTLsULpp20p73t4kV/4TbvoQzbfDFo/DLyyzy4MGDxx8LQ0XAbicrlXa1 wT9uhDffgTzjMQkyGMl7cff7cOuMkzZN1x1gPzu84AzGEHAIPnkMnvwWfMc3Fsjgwa/h4TlgqYaP X4c7Xj7u2/+WwAU6sDWy20npIMPA3AEfPghhP7z8AOj7qy1B+aF8L/zjAlhjObZz1BWw7R1QBWH9 WnjtTdinjxAwA0c2wnWPQuGV8OblJ+nhfyOgweuKJPDgKwrz4MGDRz8YKgKOuvdv3QFPvA/P3QAm rioDBio9sMUP2tkSv/0TMAMexN8SUEogTEIoDBLJCTTA/RcREMCEeXChCux2+Op7AAVMGAcJcqDF MD4BOo7Cw1fA+/tAnwYjckAlAY8bfH7Y1MASMIdH34bpBvj8fXjzI1jxBly/DGZk9r4IHYLd38Et 98FhCwwbA5nJgJHgckK4FRxBUBGQNxIuvBBGTmAbB32wfw9UbIM9IXjqApARIBSd4NEYBsIU0Axg OAj/t9dHQWMDiLUQp/8ZinQ27Sf2k8wENAkUA4IQHNwRyePLV1LiwYMHj34wVARMh3q2bPDFa5Cb DPdeAGzxIgISMkHeYxhmKKgrhR93gNMHEgOcvhhy48B1FO57nlXkzhoPxbvBSkHBmXD9WT9/Ysdh 7m0wNQTmUjj4PTTFww0PwuIRQGJgUMPy52FVKSuOP/8KzB8JGikrtbt9kD4cwNpdeDAhEXLy4cqb YN8uaNoHTnc/F/GYYfVHcLgWcs+F1++HvHTASXDYgFJBmgzoIGjFEJ8KpxdC/WZ4egWUHgY2nncP 3Hob6Ixw1qUwbzh0VsLXa6CsHeRqKBgLc+dAnBKCHti/ETbsgS5E5wzgGph3KSwp+NnWaKoNbroJ JAVwzQ0wP2fgJJNhOPAjfLQOLlwGbXvgQBl4MLjwdpiaDj4b7PoBthwCbwjS8mHWLHbJwmb7pmDL N/DFj0Ay7Ns5GGD1/BkpP7tAMg8ePHj8CTBUBIxF5mCpAsaNhpId8OJ9YEiC62f2fBUhAZqCzV/B Xf+EpjYIkiCQwndb4IknwFADH30C/hB8qQerGRCVq9dBSj4syfof7gMkYpBKIR6giQCZCowRdyrG Ay1msEeqBH3yIpinsV+ZkmDqLNCIwRYCl4f9CgnirZXw7kuwvRJgGCTq+7mC3w/WTnbDUgIffwrJ BlArID0f5uSxO4MO2PAlvPYZqKbAGZXwn3eOHfjh20Ckg3g6xLXCA4/C7gPQ5QWhGPQmSLkCdv8L 9nwD194Lje0Q5OoTqQHLgrMLfvY7xGUQKIPvdsDBTfDUS3DBrAHahWHN6/Di1/D9BvB2gNnKqiiO 5sHn58NrD8PbX0BzJ5BhVoGRPA0eegQuHAFv3wrPfAO1MZUhZAqIV/GJpHnw4MGjL4ZqaowvAFzA stq9z8J5Z4O1CW5fBB8VH9fGVg9PXgbF5WDLg7tuAGcX/LgCvv4M7E7WoEhR0O6DM66GhcPA0wRf 7D0JdxV1AMfkcNF5MHEYu70T0dJT8M8H4aarYOJwuH8lBDxg72C/unwB5E+Ax9+GLhfcdzPk9ZfA 2ZAMZ86CJAB7Lbz/CjzxCNz/f3DJOZA+DQ7bgA6DPwBUkJUXx10H+3fAW49HzjMG1u+C/d/CDWnw 1PPw3XYwzYRXnoCpWuhohn3rIQBQuweqmiE4Cb7cDdXb4IwRMCL1f3mBuB7e/x4umQj1h+GKxaC9 HRzh/toxELaz/68sY9Xyi6aBHMDrhT0r4Z//AZ8G/v4M3DkWXFYo3wdNdVD2JTzwITTZYdkjsHsX PHIuiAj03sD/8++QBw8ePP4EGCoC5myHiPBEifDso7BoCpA+uGUBrNoLoZ56s/V74Ec/yGbDjx/D w8/Cd4+ydHWkDWxs/mXACTjzHHj7FRgXx961JMIZxetgXDZEqnl3/7vrTQjR3cyaoABNP4V1u5GQ CPGaHv0tBsPmwI4iOLwHlr8Lr74Ed98Iw1LA54GXr4FvmiPWaREolaBUw/AJ8N8f4MFroN/iRYQM LnwSDrfD+i/grf/Ac0/DOWeACAPXfpj1fxDsSS4/3AQiLYybBlPGgh4xmwZmTYHRBWCvh+qjrIk3 MQ2+XA1bO0GhhcWns+QXPxxU6H874Y77Yb0d3vwCrj6t/xfoLYHJGcd1yznPsfJrz8sAQxqcvRBS ETt6gVgFnYOS5IhpsHoz3HIpjMiDbANsWMO+MpUOjmyBV48ALoGRo2BkFut35gtA6vnwyj9g8hS4 7ymQytgwsDE5g52cBw8ePP6sGLIwpFqWTTlboH4UvPMq3HIHrN4G918NU/LAFSEAWy37OX8ca/dF vKiNyJcEBtWVEA6DJg6u/xcYI5E8CBTNbpBOKMyH+Ih2F8eBEEB2Kntsexu7RxypacuBC3fu9iGK sJZcxjaIfMcqlncchoIpMGIijJrUvXNxPpx7NzgpOFwR2ZMPqz+GLBNoNCAZoN/YFcNOqPfD1Mmw YEn3zhsvh7uugte/BPpzaLv/uPuByNOwD2QFLwViHBwW1mML4cc3oXAi/OVKWLgELpjN7pl7EfwH g8++gYpSuPkceGwivPMmnDGmHw4O+CFhJCzKj7hN4Wz4U25M+HVHMfz7ZXjnPbDpYfY0eOg5yFUM 9u4m3wpZKsi8Gtb/DaRiuOwJdmfVTvBlwJzFkD0ZbrgM8g3wTC2EaTCm9djmIz2P9lhdg52cBw8e PP6sGEonrJiMHwlj4dVXQHkPvP8D63XFIgiadPb/R0qgqAxIATz9LvtnkgokJHuoWAC5xmNnOFoL JA7jzoNn57IGY8SsiIAFQpArQYhDcw3bhgyBxwEOF9QdhUP7wKqFC08Hyg31JdCIhL9y+PQDOGiC kAqkZXDXyzBuHjzxOIxMgs422L+NpVuXj5XwkuOhCVgJWGeAeMNgjxl0wKPXwmYfXHUH3HYxSBho roYtP8C6g4DkfGw0qHuEZrqX1vcImH2gU4IELQu4iobj4F9PwvB4KN0Ij66Dv94P+jZIHAP/mgaN +2DxldBxCD5bDTNGgqrPS9Qjbn4nYirGWc0BImCF8piH+Y634Zn3IDUPlt0K150POcbeh/cLTABq DWsYVnGpp5Phsjvh0oVAtcKap2HfXFZAJ76DstXw2gRYlAX7PoBQkO20dvNPOj8PHjx4/Mlw6oox xI+Cx/8NzB3wwQ/dd5I+HeZkwObtcM+VoGHgUAXED4OZ84Bey5I3xgmuBMTlAL4L2upYs6hSCPr+ +EMb2fndp6zDFxUEpw06zRBMB/9B2FnM+hOxpFAP777AemITajjrPPD5YPs3cFU96BWs5tncCl12 ljXn3wyLh8OuyGlPmDQMF4JRB/ZKeOtJ2PwJ27tuB7S2gdPLfvvcU6AduMMpnBVYcwshPRcOdwC0 wOMPsusS9KTtTsheBuX3wvetoFGDmOnuMaEKBAMYEfQDF/GddhW8NwWy81nlgXJgFX3/IGDhX+Dt /QBO+OJd2ILWKBaoq4XFUvj7OSB8BVzl8MhN8L4azLUQCIE4EuTNgwcPHjz6YKgIOByxQCISlcQQ RuJweOoFCNwKKzfB5LmQlg5PPwFX3QQl5ey3ci3c+gScNQlKK4AgIscKWAJIiWeFXXo3+EiWgPuF 08p+drSw/7qhhzP+CnkeWF4N1p5MHN5IHJFyEtxxA6S0wYsroar02ElSxsJdD8E1i8BVDyIhpGSD WnyCxxQr4Z4XoOVW+G4fHIjJwjH7r/D4YzApF4IdrDMaRAT6bpBs9A6MgfRIXi1dDqsbMCyBd+ug qEd2XPYILBsFb6RCzcZj58xIg1uWguznW/ETxsDS0WwfnjB+ibu+QXbczkXXw3td8MjzcLTHh27k NLjpUhiRzwY0X3MhrK0GR09jdHdiPgkWDx48ePSDocoFHXbB5x+BJxUuP7M36Yc80NIJpmRQRIyH 1jY2jsXphPRRkMO5GQeguATkqd1/ettg/VbQjIa5wwe8XBeSQT8EWwA0RsjIhIICyEgHtYxlu7Y2 oEWgUoFCCseV/6ShrRFKKoEKg1gFaRmQGtdDHgz4fYAJQfLTQo+DXqgrg+o2EIhAnwCp6WDSHouF DXjBTYK2R3gNe6FoHzDxMHXYcSfpbIJOD0v82nhWKMcxdhHT3gBVjeAPQ0oGDMv91VNcNO6HjbVw 7hLQ9bmSx86+NSwMAg2rohf39GSYgvpq8IXZIK44GbQ7ID6OD0PiwYMHj77gqyHx4MGDBw8epwC8 bMKDBw8ePHicAvAEzIMHDx48eJwC8ATMgwcPHjx4nAKcAgKmaTpE0Sdu95MRCgTbXUEfxRuzfzEY 2uMLWtwBu48kab4/Tz7C4bA/FA7317VBf7DDHQz0+x0PHjz+iBhqAvZ4vD8cbnptb6uVPEkczJDf rj0w992975a7Tiar/1FAk8GjjdbSDm/wRL2DWh6sab1/VdFf39tz1ZdlOzr8PBWcbDDFJbVPbqov tYV69y0d+nJN0fz39n9R5+W7nQePPwmGlICdVtubG8pv3FB51+aao74T02XIH/ixuPHLCvtg0hjl /7rWW+kLbWhwUgM2+vPCUt90w1eH79pQXeEevMPp+pq2e9ZWvtbi3e4K/Njpq3GSg7b/yWDCNQ3m D/Y0N/tP8gIJDY9tR5pWl9v8vxvlR/jrXXUvlFtKrIHe31De1TXeMk9gV6ubz1zCg8efBEOYCYv2 //fr8mdaPV3sH9hP0LQxFovzzS1V+zDtyMwx2eKBisoyvB17EHjtrq3uUJLAYwnRg623qODOBluZ G61hRA/Pyx5jkI9LlP/cQsP9gg4FVpY0vlTmuk2keXCs8mSckgM7PN7eUrWVVmelFI5W/tox0ScF tC8EepnQKBX06Vt+GPPg8afDEBIwE6rqZl8AuSJD2nsKYqiwh6TCNCaSCGUE5nH52xzeJk+4Gaxb WzxGk1gsl0j6zlLYr17unWEYJIILcBz/+YyEjg2FSBoXSITHHR0myUAYhCKh6KfNu1Qo5CEZHMNl YoGA6D4TTdP+IEnSICSE8n66hkX6+NFVyU5CLk9RC2gy1GD2yg1ak4jx+wM+htDIRN3pQILBg76A BeDa2eMemKQS9HpUBr0cGidQD5yoCxgmEESPhrpLIJcQTDjUafPXOXxdFPXo4fbr8gQiQqSSEDHN j/Wt1xsgxGJJDzcFg2GBmOhpSnsDYUKAS3qqa3DDo9FFtYBte4s7I1mOhgdOkSSDoWfibpOiaAbD hETMPdNMMBwWC0/usGe6zNadNc7cgpThmhOsA9CtCAkCjQW3N+ALhdVKeXddD+y4nyJ6OzQhkvcM jlAwjIuJU5c2lgcPHr8KhvBHTahfv3/edeVNd6yr3hrGjtEFQ9fUNT2+vuYDW1SFrNj5V/W0z1uj La75ZPc1GHH68MxV52UNWrgHgoFQcVXDK9uaVzhIvVA4P9Vwzbw8XfPRqzbYF0zNvWdqolaAMWFq z8Gqm35smzNzxL8mGt1267PfHl3e5rMCPloh+du4nGsnm6zVTZf/UJOenjwZHG8cdVZQMDcnY8XZ 2SZpb7oPh8Mt7daPd9Q8Xef2MjBRp7psUsZfR8YZhNBlsTy8puT1DlaXO02juOy0kcvy1HTIv2F3 5fVF5tYQoxUKzh+efPPMzAK1wGzpevn7yv82ezsBHymXnD8m+6apCSoIbtxX/eiu9p09Jtw5w7M+ OD3TEHY8vab0jUZ/Z89tPHbm9AdG9+0bpmzPkcLN5sX5OSuWZFTuq/nrtqYmSn55Mv1BC1uB6uLR ee8uTt+z68h7pfYd9iAD8NaW3bt3EKLEuFdnxq3aWPlvp+iN8fJVBzo2e8MgUKy/cvI8A95mtn2x p/aZKkcbyRSqFMsmZ14wOl5HeT5YX/p0mauu59rLZozJLT50v7v7z1BrnenfdbnxuvvSFS8eaRmX k14Q6nqr2lVFwenDst8e6U/5rHVCetx7Swrz5bDhs60Lq8OLxw77bH5Ca0PzHZ9XfYsWGjg+2qB7 ZH7uPKJFtbwp+oy3rd53G0bMS9UPU/pfK/W+dtHUG7IU5hbzXWuKV4SNh87S3L6i2pNsOE9Lv33U 3hCiFQr97qvHZ+K+H4pqH9/bsZ+kVQLh2RlxN83MHB8vI37uMouh9td33rmlqX5z27fLxs0ySeTC wVZVdWbzpe+Z7Wyab4hXSB+YlX/pCL0mpoHX3Dzzs6oSB/3DjXNP0+FHdpedt72lTpXuuX4YEfRv 3Ff75G40HsIyQnBGsuH6GVmz0pR9BWoePHj89jGkq2qMEMiFgl6pgWmv/cGtjattlEQgmpai9Dg9 te6wXyxbmKbx+MlKGxKeYGS8Kl4sGGuQDS7sBr2elVvKbzlsQ1P1CJ3c5Q98Wtu+nlZ8YfRVUMHa g43ZcfKluRqH1frMzqbiMD7CR7Y1Nt3yaeU2AZGmkYr9oSMeX/nOUoF64kxfCIlcK0obP8UgTSbS hEObGpztoXAvAmYYuqyq4Y4NtZtddLpGXoCH9lidh3c1q7TKsxSuO98//FEIT9LIM0VMeZf37u8q 56UWlhVV3b27oxUTzUqROR3e5SVtaSk6jT5w9fLyLQTO3kYgVO71/WPHEVApLpLYnilq2xlk0vTq 4Uq81uJ2B8MUHV7/xYFHWmiVRDzVqJCGfBvNAbu/X5MtVdnA1oGo6XLYKaDCXN4z70dtOJIYSYpc UVyzdFpieYV1vZ2ys5ZULEcrlRC4TiKwefz76TD4HDdsd2pFAr2IsYY8u7sCaU7L7etq1jnDyUrZ VBW1y+q5d0+TSKMYUVd5Z4UriOOFcWoTTu3r9HZ5qfnJujlOss3hr/NRSql0tFGarFMEPWQgSL93 uA7J2SkSoSZMrquzHxGzC4IwzbDOeUyo2BKxhJJkbUPLdetrd5F0gUmtZkJV1q7nD2inTZdyw6PG 7jOTkB+nTJII8yRCj9WGDo6YhBmHP9iOFkREOODzbUWP3Ww50EqkSXERxYSDzgPtzp1lVf8stdEy yXg1lHcFPqpuaSSkn5+ZYRxAlzDwsBaMTtadm2F7q9F73vIdN07I/dsIY6FJLh74NB6RcJRepsSp klbvrRuPeon82/OOUai1w4dEXrTBPghDNbhIH1qaBqlgMLhpW8UdezsDUvFEo6jM4l/d2FGPiVYb 8tIUv7YaiAcPHicfp16txYTDIZrlBSEhmJlhmiKLbw7hI5LjV56b0N5hu+/Ho2us2N8XjDhNKxRL xNLBTkQdqmx9ucIRpLHLJmRemyFbWVz3SpXnjDj5iJGZZ9eVruxyvby3ZXaK7EhR9RoPmFSqczOl 328v/QEgVSo8wyjb1Uaag+yZxARG4N21g88cnnZ5oujd3TVraZzoo4ANBTxvba3f7GImZ8TdMz4t zd0wfl1ntkKYIaG/2ljzURBL0moen589W8FsarB34HLSalt+xFwdFl44MfO5SSZzm21zFzUlXvTd lkp0G2iRcYZRfqiDag+EI7fBhGmai9jSy6XLCow4TZIKtUGC+SPKAolQMC1Zd05c/HQbuThH3l+n YJzKViCWqwho69kbbzQ8N173TXnTx/W+Chtz7txh6jrbu6Vtuz3EPxfkF4oJuVxqAPtTkcZGnfah 8Yad1W0r6zwSLPD25tp1TnpUkv7OCemTw23DvmlPkwlzFYJQhN1RHxUY1ZelK6q9ZF6qbrbBMMft /WR7zeNltsLUlBULE8VCrHx/DdeRSwrSLtDj7+2rX8sQNIN2YXKhUCfCIRwoQ9zJQNDpXn3Ye8RG FiYnvDY/K4Hxb212SXU6lUm98tw4NDwe23z0407s7jnDz4mT+h3uR9Z3omdNU7Cj2hUKmkMAosiJ EQjBlKz4u3KEt2xudlCMze78tsZmBjg/QZkZDtR2BXzAJrTunzQZuqXDtqbO0RX1j8IE83JMU+O5 UhhYfHLcg/OFga9K3jAHXtxTddQdfHVhTuYAdTJUMtmywpRrRhkNeOiNDeWP1Hg21NkvSVNHG4S7 y24JU+QE0IFmPxVAY4AMWx3OT0o6WwDOiVcWYqEai9/L/mr4WH4ePH6vGGoC7i4/H1OkjlBo7xob 3/JD44Gg7/lddYUm5dIJmVoCFyplmN+vEqLpk4jXSrXKE90qQ7c7g84AnZyY8uSsTBPtWVvJTk2Z JqnWoLhhfFLpD41Hmjqu+jZoqfOgc87NMU5Uk8862Rux+UNfNJGdwXCcTH7TtKwlGTIzVxVJrH1y fk62iI5Xiy6kZSl99c+Uv6aLUiqUN0/KOitL1VnDFl/SyoUy0v16R1BA4OePyLgwRyfG4IpEHUMz 2w6VbnTRBYkJD0xISlILk9SysegkHssjEQ9uZ5Ba0+zoDFBGqezaKZkXZSv0NH55vrXiiO1gU8f9 TveYJP2Nk4xSoeC0BcMuXlu1osv71oGG7UblxNSE3L71EmKA47gIKEuAimiy8Xvm5J6bQG2v61by Z2QmaiXE1gbzbg9ekGooiNR8Ctq7j715et51IxTT4pUL8gLT45g7Oym5TH7Z2MwL8/XhVtamr5YK tHJx5oS0W7p8TzcHvixvLu1QjE82nTdOLBDhcULQS9llgEguN6kk6P13r2LEukfn5aQTZKJe+jdG bmyqYAcDjrP2WSZCKgzT1eE9IHB7QHT/ablTk9DqS5GebOQOV0WGh5pV9mImNRoeEtznjViucamQ axJh3lCYikj96XrlPVOzzk4ghCK5NQgy2rE/4om8z+zc5gn5CeKc7IRbJ8ar+rPJM+HQxprm+7eb PVE/bkyAyaQT42SiyKXIQGBfTVeVl32JWqloWpJaJxpQKayTyRfnxucb2cXkglGGl2s8Xn84NjS4 x/5ORB6kxzkrQLU6rJsjdbwOdTr3ekkPjs9LNd06Odkk5SmYB4/fJYaYgDGcm14E2DG6IIRTR2V/ m5W6r6z2tX3m9U1dhzt9OfFTZ2kFrCaRnZeCNTZyxgkJmG3LNldK5AkSnPZjnMCKxGucICbmJiys t5ZVerZWW9D8nqRTnpsXr2ds7ZELoIl1mEnz2MS0GSlqk0IgwLDuQoCEJFXJ6swnDUuexM6MfWdV Gs3JIoEoHrEihsQRdipEoiAZotoZEODYmHSVuPsgjHUED5EOgDmJilhVNhUkOyJxVn4aVGrlQ/PT Z6epE5TohIQQV1w8t3DuaMe3u+teL3d86fJXBvEvz8zOSk159WL9sqqW9/a0ftVqO9jhCsjkb07R Ddg1GM4wtIUMs2ZeVdzSTAXuczCcoMUthbi+Y3XqvY/N0iIiIEYnG0YlAUFZI88rNElFSF4kIy+T ZhhEH2qT6e/nqy9pt7y3tf6TNufyLk8tSDcvSoyeZ2urPQRxMe9dkqwgREBE+harbGe7LhCmXCTE o+ux5Z8xSoQHQzSIZeONomgnHnuobkkxVG8nwShBLyfiJkd1RJgVwyO1rmRCUeQmlSIiXi7ECcGZ w5PCdPjHgxZX5CQNQbhlTPpFY1PytCL0Dvstr4wR4jPyM1cqdT6WJnERgUslouHJGo7oSZ/3je1l jxY77CQtFSreXDJqUYpCPrBVlvVl6+FYq9WFboM8vtcJNM4iI9cchDwFhtqyf6lEpD/ELYqagth1 o9KWjk/N1YgUaJHzs63WPHjw+E1gKL2gw5u3lj1fadsYRJRqe+CL4stmj5ydIHJ1WZYXtfmlqtOH p98pEtetq6sO+La3B2Zpoy5FTIfvRLGRGKI7CGMYEq8q6uo/rVLl0u6ydtas+MyB9kcKNRKV+urc uB3N3iIfg2FEYbxxQaZcSoXPFBKvA5WokF0+OmW0BrZsL15W7Jibk3RParepmhNMBvL+ZQAjcbA6 HF8dNScSqu3F7Ay5s929zylCDBsgw09tKEucmyZ12V7e0rA2JH9yphyJRl8WN45Xi/6SId5eVPdC mfsvs9JmCAQlEDLKJJcVpk7U47t3lyw9YB2fEvf0ZMOho9bktPjFc0cJRIdvKHaWtzrb/a49mxpa xNKZ+Yn3zib2/9hQ5aGK6q2+KTpZP3cY6R40raP1AadiddPs/5CUSbNPtanKdXuuZLD3xp0Bi5Ai xj6v3eX+vrJ9hIKsjDzvAYt3S2uXrdS2x0pOHp58zZzs9q3Vn7b4d1ZZXIsSVT3n8SNBE46roBjb tyJ2ncI0dTo+21WTjfsOkjSS/cQErkD7nY6/f1dz7+Q4S2vH03tawobUb/6aIxdG3wjTGdHYI76N 6NvDq7dXGgu0+ys7O4DVt2Ax12IfBMcEOJGq1+Rj5nIGzshMvmZCnLPTfPnXDd9a8HXXTV5g7NMb GGbSq8/Qq3vvj4AKhR2OAInhF4/IfPGsbN2JrLF1ZssLm2hLvsHZ0nx9iQc9/ux0pV7KLjcj7wnQ AjBC0NTHmyq6TPiWdk/EPI4lGrUT8PZ9NJyWkXDT5CSv1XLPuoYP2ujPrpj0l+R+DRA8ePD4TWMI CZh0PFHUvrE7BRC1urYLS/LMTtBazM7/VpmLPe337qzkGqbpNGclR629rGeQUTLIfeJEZBKXCqWz MmQLaqwfdgQvXlV07Pv25o1duYuMRE6mNu6IFBp9WpnshsnJrN+pQHnHtIRDO1t32z23rO0uL+Jm giQAAB1ASURBVE8QwmEGuYAJsRIhjg0eriyR6m8cpa4qdb26++iru3v2ul1l3sTXRhhuO2gu6+ic v6LbVXm4SZBtSn4g3fVSk/fBjSUPRnaqxCIQyK+ZEH9oV/Nuu++eHw7f0/NY+VrxkTbL42Wd9pKO 6LOelm1IoTw3Hu0sJQH2N3bvF4ovGRHfl31R19GcSIeWJqz6IUJGapGElT9F6VIR6uV6F6uWJhk6 ku0EOyaK9Tz5cfFTQt1tY7RHDzs+OVyH/nXv9HpK6lq2dnrWtfvDJT2GZoHwmnFJHPtSEbuDUiHm mI2mI9I2cVzfpo9KG13kKvb4H9pV0/OwYEpQLYiTHNjdsbK8/tPy+siD4Playg+M/BixYnoxOzzk avmIVJ22zfx9fTv619MBwDmeoYeIMeFj6Ubj5fnmZ6pd31fWoX/cmbMNOt2gDsz9QqpR3nnmxOso TK8U9StAxwCL6N/ptY0W9A9Y+VywIDflslyjSuAXsF2CSQjclGYYq2+v8PreLml8O3oozsRpDdeN 1jeV2X+sbhxVHXn1GJaq0RgHDJHnwYPHbxpDSMAi5UNzsqf35Dc0AjZlhBJNIclpphun0AfbPF1e iiAIg1Z+Wk5CQcSrUywTz0zVh9SCWfHCAU8rkP5tfBLhhQXD9MmpovtmY/FVXa2OICEWGtRSyu9t dGEa9ikZs8XncoXQ1uSM5DmJETsnYFmjcz9QKt6vczn9FMUwIpHQqFVeNiKBauuYnqQZm2wYzO2L 9ewRLpxR8JSqbVuHFy0tlEqZRsQ0d/mGa+RT8+P/o1aubHF1eklCJIzXKk7LTFiQIRutyDeUmfei 9gQoJNIRiboleYZUZdwHKtkH9S6Hj6QYEAmFGrVi2agEiddJ0OLDXX4nSUukoji9akl+QrJR8Nac 4Eqz1+IKUTiuUUkTjPprRvSb4wIfVZB8u8KbkaIT4cLx6cbLfRjEs/pcTCCakKQ720opk6UMMP5A 2OtHcqQoqhoXiCRz41VauWCkJnZ+x+bMKHhW0brZ7EHN5QqpQUY0d7pGJiZMTqdGtjja7AE/YAq5 JMGguXlCRCWOCbISNYsyqPT8+EinY3qDYmaSZkaaMbZvCVXcW3P9K1rcjkBYKBIKQr6yLmpGiv7i AmmCRLa+wdbhR4sVoV6nPKcggaNJNDympOptMnx2AntiTChekp9GgrjY6qcYTCLEOu3ekExpVMsv SPGkpeiTY7yiZCrFtbPzDYmdJRYfehC0gFMqpHOz4wpVA4+0AcE+7+DRcdGnXDAhHXMzDE2HwmGS wTKMmvPy4rK17Au5bFKyhhQsztCIpKJHp2Ylm2ydHhJH60GgasxeTbJGIZNdOCNfYuw40On1UayT oEIunZJmnKgT//x75sGDx6kHxskHpxYMHXb7Qu4gjeP4/7d3JlCSVeUdf/ter/bqqt57evaNWdhH jAwKQeISFVzxGGISskmiOUaJx6AhBCNxAUSIUTFiDuICRjCM4KAgDCAOzD7T+1bVXXvV27d7b96r 7p61Z5hwTA8w73c4h+nuW/fdd++t+7/fd5cvIjICQ86NlAhpmqVAok1mT7HOBT1XtTFBoGe9krbl NE2XpCiJp6FjVyy8PcGRwHno1wdveLowCdlt11/yltQxMw/geYYDfAuQokiBDZbvPNctNm1O4pPc y5sXwAOKbvvjKc8zAolqmsPyrNyyS3TdUhzgD6NRkeXm38FzvZpmAwJjaUZuLR6frBhYcBLHVXXX BJBmKJlnuDkjCxmGrVoA4LjAM7FTeAgQNG3IsMHtHRB4/jyD41m+VRLbskuqI8lSnMVNVX/iYGHI E//kwva5K1IQrDZNDVFd8eMP1AAAVN1xIOI4VmLwmmJSHBflSMd2FN11cYxl6RhHk/Oms+u4Zc3x ZyeRVgt5jjPTtAVZTBybsd8VLcsxXEhSJOE5eRW0JSW/6fySKH43cJCfZUTwX4U4/AHdsBQPT0fY wzeH+HWrWi5AuF+tqmZ5NNslU6WaSfJcWqKP70R+5VieAwMx44LF1P/33UxBJBKAMIg8CP3/izxz uPWh39Cu/5u5/uD6lWkDnCAoDBQVR4hKHSI1V2bbc0BQZpahmOPvTAkJCXnN8KoQ4EXAajRu2rb7 tkFj/ZKlz71/6QkjcUggqyDYYRRWTUhISMhicObPAS8KqNI0hqcNiOPXnZ8N1XdBSJIM1xJDQkJC Fo2zRIDxREzasipT0cQr20+14zckJCQkJGRxOFtc0FhriRGd/EBRSEhISEjIYrLoAowQcCD0MFog sf+jFLplq/yrOr0hkepnj5dRiPRd9cITVvKdyfgSNtTYY9DNqZ9UjSriVkVyl0TpsHpeNXg1u/hg yc5Eut4SpbmwXUJCzi4W1QXtVfWh26YaO1xf9PEk0/GPXV3nnPqYz1Eg6Evs2C1F4p1E4lMZ8tir /qDp1X46XfiBY6b4WA+LnwWLmcb+8sgPtMRVbdlNAnGKOL/56osfKFiKBwGG91jRFWK06xWctAl5 BcDi/ROlATx3bS7Vt/BFoeaAMnl7xcnayfVitCdsl5CQs4tFu0UW2ftLz190aOZHulV0nJJj7dVG /nhwePZy29PKAIMaABoExkJGO8SACpHtm9fgLHGp1x4oVL5Xn35Sc6yTvzFyx28s6tMuMDGCIuhO hv7d3RusPj71zPpde77X/N1WuLmnuvPyPS98tfqab0dgjn62Vv2RUntMP+F+zzmQDTwTQQOil+u2 9f8afHrL/rEn9N95MUNCQs4UiyXAwDp0XcEhcKaXS707kbkmQtM4UoD2SMPyMOj4w1AwRvnSGlzI dOxwhfxfuAg60KkEV0XgZ+rmeRSU5OVTQXQ6yY75yCuSGn5VRN4oRnqY4KCoBVoRc1p15Rz1+Kap tOL6CZck1v1s9QV3dAupY50D6PSWIPx3Bwh6CM1eCeo/xfOqD+uuA9RvlDTzBP1AR16qVSHHPBE7 Ku0xf/X/4gL1BdOadrWvzTQMCFuBFPzMj84BwQWKjE7zRf4v+IWxiratnUw9j06KYQtMCgl5sxjZ KPDdJ993fxrrMK2ad6e/obplu+l/X+zjvyAhISGvURbLBY1T6Y+k+QYmvzmW2ijCanPXT3XXQziL Y7Y9899VbQrJW0Q4YttNQKS4trfFOQHHANQOqM2dpqMhgsT1F4N7rJgcfToaDG2gH1LVAy60EJGi xDUChTz1Nya1KZpaOucPdCa1yq9NcrmU2cwjw2nu0owhzx/diCQlrhMjnSxuWTM/UvBOlk0ic78D dEQk2dQfxNgFnYUQ1J+pqwe94PZ+/4kXyLEcHQzjZaux088d4iQhnBuJ9tDOmF57zqTWiZRqGUMu tDFmg9y2iQ8soqLZfNZwGjCosh5GXicJyYX96UyvHH8rTF4gUo459u8VxNPiCtYbs10DkZ1C2xWy O6FpL9atVrgnqp3WtzecfiG5mbd21RsjiF/NgWnLygMEcGlrPNFLYxAaw1rjRQtaGB4n+RVCtI8j SVDf0dQHPNCaGOEEEbkizpS16m+M+m4Hg5inGJN3TYtJVlpKWKMeu1kiaqYx6kEX5y6IpvqIyiNV k2bbLpW5KOkV1ZlHDGadlNgoUoRXf6qhDgRXOlFZSjg/Klp64WFNe07zgqCQ9uSd0804FTmH82Zs q4Ql35+WRNyZ1GtPa25caL9UUJ6u2x7F5Qhr0HbrkEgysS2ymCK9mlHdobsVhFE41UHLm2RBfiWz NvtAbfDbdSwrdb4vFe85abApr27Xtjdcmc9skWiBgIbXfK6h18jkpXzyyohFM4k3iIHKIqjtbSoH gmDFVAcX3ywyJwQeRh7UDirqPsdvAownuJV8tI9uPtXUxi01iFyF9APKxN04m+TaP5QIHdYhIa91 FkuACTp3fQcEvsUN1N3V/H0l3YI4T7JrBUo3ij+sNve4pcdolHeB69trlErQa98lKjvKQ18qawO+ 8XskJ9q34V7u8h9g2IXvTJe2qfpwIG+ELyfnSzSLtJ+r5JomfU9/VMaRYebvnZ78vkqtSkbubqs9 MJ1/SLHGQSAzMVJYEen9u/a42Bj85wKeZdgYskZaWSVZ/NxIe9eJougVv5kff6BujLcC/skEtz62 5p4eclgZ+9JMbZ/pqsgvNn9htPujGWJ3deSOKt4vkJptTQDkYdQmO3l/l3dQGb1tuvaS6SrBFce+ eESvSvV9JC2lFnjc9J35wl4CJVh2rTlxd8WfypAJEpaCtV5MpnWrA/tFobrXA4GWY8r9MyqF01tT 0vLszF1TUy8gdikDS45Tgr7pFp3E5U9Gaw+VCz9pKPtt/zXxKMH2Cd1/3yWMzgzc3aqW+QcnRDpZ K4/eMecLRRoo3VPEKDaxFjb2uvQqAW/adqDrGH2RK32OH7u1YMREcbngC7A9WBu+tSpdl5NW0+Vv 5ycebJqTreryG2i91vteMPqVxuE3rP1HsUZQqbdw9qSp7ofosqTUR2gvNcdvnzEzyeRmKv/VqXqV ZNO4PeYCf4qW5Lo/TRErvPF7SpWnDa8eCDDZRkVWx1fe0XmC2L08OAH0Zw2roRvDdse16exFErXA 1wXZI+rYLXlT5Ii7+nNrGWuoOfL5KbXBEEl59IslmBOIFRFxHTF958z0kw1tOBBgMstG355e81fp 4/JqbCuMfLOuDwY9DeMItp/LXSWpv2lWn7BnEziDZmHQxBgxFQpwSMhrn8X15zrO2L+N7r5+svgz 01cd8cPtfe+UMXvOgemNuWQvG30jT7pe9b6aUTfHbp1W9jrUJdGV31my9O+jh++nfNnnVL4zOnZX Td3vclvjPTdIsA6M/Q5O4HQEs3+rDNw042Gosb1RelTzpZ3aIulPlka/3jArWPzPUukrCNQA+nOK OukAEFwMCaYdYxqJb+IIEUeW59gLFEDbPjP6rZoxhfjfT/T/S1ZqJ429tmt5418YK/5Sd8q4fJVA GtD4ZSP/ULVZBr7t6Ow2HA0XzucoFvNKrmeBya+NlZ400BI++/E46ZtDeafxrG6UFo4E5dYBpiPM wHyTK6gVG3nTQLg8Ii+jMMVtblOpPhrHsZbTmIj9WTL38UzvtQk2ggMFIBNaeyy8gxF7Amn3Tczq tsrwF0qNnTbslzr/Ic1R0HrRMCr2zHfr5jggV4t9d/Wv+eckyRJsD5e6unP1N7pz7xdwCiMTbM8d vev+s0vqoX0tt/cYgCSF9SxJY+60CxzoqhiRoqnW2rOxRwuctRBXHp0e+VbDnMHEdyT7b85wAqbv tpnz2td+q6f7r2N0PIgKlPty79p7e3NXRnCnFQTQzwECc8x1akFkAhwhaEJQdI29DrdV4mMYtKCX V0buLBZ/pgOOylwfE5dgIO82Hqtp1ivpreyqzDn/0Sl2IPPJxujHR/b864y9wGIuzrRx8jkkmrHG HlSQi5q/LGt5SK4UeBK59uyyCqz8eGb8vyrKPpeI0eJ6Bo5Z1XvyY6PHtCycLu3/bFkdAuKV0cx7 GMyC9j5TncDa/6Zr5d1d6Tf74o/z58lLv9677r7uhQJvhISEvMZYvF3QyDEPXH+gvAPDaZzoF/pu 7u3cENyJAefDn5LtbO/XV9JPFIZ2mjaNYMNQByBxbnzNpzqjPTRcIzgvaRPbsEiWOcWm3wC7Ofxl AxB49MPZ5X+b5fKF8a9qTJZuv6G9aYH8Ns18pjL6OEs80zDLCGe5ZdfFGp8rAAthWRrsU2pPQt9U JXIc10bNHXaS6c5Pd/VdQe58z7ijIOrEWOuOXbhfs6uISstrb+sVGazr3Tl/uPRGinufBoikOz/X veTqqHPV6LPX1Y0Bh8m2zD6J6rl7ZcpQhv4lr7Ak1lTL24KZCC3Bxr2B49ivKK6bZhcwf1v4lZCm 2TaKplsJcEy4LL78pu76rYeUQY/MMEtu7Ol4Y37Pp0tmke77WE90rqnB7KSLvyS2/OZu9MjovrsM jATN7TXbQNTFyQvu7YEThv79sonz0RwHzqOKA563X5+8o9Dxl+0X7uiipMD/kMmKgqmVHjRIjkpv TUg0NB8J8g2e+7UV0mhl4LaS2UZiahApkIiRROvsEwj0F4O6Mflt09MQ2xdbc0uPQGNd13TMhfp9 AydJsPYTxa0TmTcn4iymPWOhYIJB8HIQrxB5rRXQva7XemUMx+Mf61z90VTp83tGniGcvGkNWYEP I8MYv1b1ARR0tmWicBK90p6a3v2JYsvhP0fk7/o2/2l87geS4JYl1tykPX9dDTQ99X7F+UiKFY/v fHSOi22JlZ+p2t8t1T7EFu40EEGkr5S5TGC2khGSTcD6fYbdRBgrrv/5CklRDv3DZPFXdvFhNbXx SD71h8qBmyRFwZJV3e0G7xelmCVCdJVMrcK4iVL5ccC1c+k3JcLoRyEhrw8WS4ARzN8y7KsvGWcS 12aWXJvko3OjiO0bmmpgCkgf6GzvJspzUeJ9ey6w7Pg+hpRnBQYPFowxOLvJ6JQ+aMJ/K7eDS14S FUXcO5yUZLtvSDQOmtqYW/iLsdmUic90RmkwPR2M59iYpdZJbpUgrhSzf5ROruDgYBDvlukOFhdJ gdj0/eWuS3AnRHyFTdvSA9di5MZ28ajI8W5R9/Ml1wryWj4Ih5flKayO8LnSE/3x9rUMhZKr7pUR Q6OByVlHu7nDJtOUtEmQtkY7r0lJsZMPtwZEFtQPBOFi8QSTfFtajmOzMduxllMhkK6W5CHn2KZm qciaaDRHEdf1n/d21/97/pamX6LsB5O03yIIIn/8pxFOYNlPrbClqcp2y5y0xv9qeHKjvObLvcn2 Vngpd26zFXARNu8PpZbFM0tpcknbunOTuMDAqaqfFDiteIRBG7b6gmI7rc3qkU9kBfpIdc0SmOyt LuDZvmLhJIvj1OEXCnIIkorz58DjfHaTSLF4+02rUxrUdlSHn1SDTHbrVhstnsNHLot1X5s8if4i pwS4HobKBs8PciRw6sghaWQN6NM/nBq/18AY3+4XOj/RLrYt9H0hqdiFkeiaRm2PveeKIJYivSGS ukCiqVm/MYK645pB92A/2iZz/s8UJbRiKx9z7TZUBwPRxSquYRJ0jpWSTPKj2Y43SrPND1uZQRD8 h4UCHBLyumCxBNgxiz8NRI7qZvgkXt9Wq5qIkElps0yCuW2x4kXBODm3n3TGAdG4XzjzOaX0Cx6/ RHCGVGUIBuZTLdgndcoxKBijMAWYY5a9mbFb4uprvFN2mXWJng809t2izDqRqdVyz6UihiOyFQ3e H4Cj1yRzb4txHtB2NmcqXjLeSojmYsqSEWbhx5L47L4wMGzoVZqCnrrLsAp4ZEOw8ghLjnbQiMSc yn11vyhcnKTkoz6L43Q0EG2nFeXHfzNiCZf9o1TbxZI7ZNQfqnkXydHlJ1w8MguNYxSOWmYlKRHc Kg6b340LS667sOv6WAiCy7CgOuuiRfqg6b6Rd6tWsBLf9IyGq+yBka2Z6Fav8Wit8IDqvKiM3deI fzJ12AyEwDUbMCrgx2XLBCH2fC0PygNHLGXAIEnSqAY67Ne21/q8N2LoNYpyPeW3ul0mUu9PcEe2 OrlqEaRlak4aMa/2gsr1YmY1UDKsmzquIXCaYuPI5vDZI+A4Q2VuyKY38nDSrj1QUS+Ot604cRcV nnhnjjs/Afwe6E/vSJygCTo2nwx4U18qFLYbeIRO/mEie3UyseKk68jcMlHeIDQPqkG98WT8Ylle wmATs5Xqz+BIshXjwtupNMZYbLipDgZedWEF63fwIA0ZdANKnK1DXLxEzn04Fc8RyrPGzM+8xBaZ j82FwHIN1zUgz5ypkwAhISG/SxZLgGHLj+iPyAf1qS/q/g/IQoRExq7J5DbNnyBpBWinIv7gjWNV 25Gl1KX09BPm1O35xqMsmDH1gVMcv0BzJ2F81aG42Aa8+JJb/d6M/ULdLQRHjb1xS9mhplemUle3 J36o1AaCR2XelxATJIHD6PmR4tPNIC79XrM0ZduTpj7okG/NRd97WkdbiAgb6WfqOx3124VD+xoU AvpB0y7iPT9emlxbKu+1pu8pKD/F1adNTKTkjaJk67XZQh+VCdUZT24olV+CmA717crEEw1ftq1J rOuf6MjyBZyOhz971BGgYA7BJoPRGdYc28JOHR/+8McInmC7ORzTGvcXDw1poGQapSCI4Mz/VEt7 NEARXJYlHG/2eBVO4cflgsDC2QY5S5zQjTUnjMnb8+UEZh5sJZU4eQmsjXnKNwsDL9VJf7qz13Rq ONoa6+o6UmLY6jF0G91ygbjlL05qCcIetY/rBEc9DhdWCHyW0fO2by8bv1CmHqvrA6ZdAMKNwkIC HASgELpOYh4TZPI9CXxdRFgmxC+OcNIpq5JhM5dLxcd0cwbSnVzi8hhDY97hYolcbD1X+bXh7qgN fsbEKo4x4mH9Us+FHPbb2fIHN9Ok354Y/X5waMwbd2rfLVcUW33JQitjzDJxXoB96xkLzyCFhLxu WCwBZpnkZdTUQw5OYUQbSdAYZiBPhwjibDtFBDt0QGufDs6mSTK4HQu4FNv9iS5Hn6o97ygz7uGc 8AXj5VE4lQucnXzc/xfbc2On/qkpbcSqjc1vvzGBPmHbBmSiDNUKx8BcFEldIJJBBRCpd+WsBpz6 gartULVWcnI53/mOCMXWZ59InDqCEs10/Hm7VRudedRVnlBmf8e/K5NdwrufzFmfL6hDVmM0MJTF 3092Xx1X/j2YgmDJY9ayCZHr/Uw3uC1fe9ZuFOzZlxIvTyQuFBfa9I0TbJDAl0O2dbMVTuAtOx7n u4NcEQCOBUEFgJZf++hBGxRbx0+lI0Y1ztOpd2Tqu5zqc07l4SM7zo1fWbG4o+3BzD3z1bhM7P3g vBq0tIOgSD5Ots5gtWQkfsxLUXE2+66I8hXV3m/a879EFNP1t3HSGy/90m1un2tZ/n3ZdAafzzbY KSznglkHlZVSbxIbuxrugHWkEzRg4Ixt+FYkjjNHXoTKSf035uAXJmvPg8bjzbnGuSy29A/EhRvu FOBE7NKE/AaM4E4r4C6/MRHrqpllhz8vllzWapHZSROBEQyVvKZNnzQm7rf051u7x7uF/s92yCKm M5SfFLazFEewG3Mrb0ZDt1esA4Z1oFUEmcq8Iyr3zH5Jg5NptEjRJyxCh4SEvEZ5NQRjgNo+RXfp 9IbW0GLa07+oqibXf3VrrdU3j0Z1vQnYNk5KMUB1qRhLnrgNyk+o2tq0J3TyjBBkAzS3sbtpapDv i8S76NJTZbIjnlzNodGZp64oBJts/7Kj/2Opo805t26pYzbGIFxgIx08xQQx68fuL5HLEp0XS6cz ChtD9dJek4jT8rJoNDenDF7drh/S7LJL9UXb1gbR7u3JxuTjavSt7em2EyxbAMy8aTSC+yn4nChk Tqr80HRtHbFJhsBBY0fdS0rJ5a3bhFV95EcVsjPe9Wa59t2xga/UHFU6/8ByYf5R+q7p/G4s+7Y2 OXbsUO65jb1KYwLw3WJ8KdN8rubEIx2beOVAvXnI8hhSWhpJLRWOHMJ27MIPS97KZNemwAFtDVfH fq6n392RzBx31wc0J3RlykZE4CUuPlyL/F5b9lzJn0dph+qVg351MbHVscjhpvDc8s8ralTq3RI5 /Cg7r9WHLYwjaQpUtjep38suOce3KWd0JOa2RNkTblG28ppe8oK127QgpqlFCsBh2NVhR1oRYeeN bbdieDjLz5/kNgfq1TEPZ8jYellMzK6jA2PSAAIntdGzOg90Vxs3AYCQoCJ9InvYt28Zkw/W2fNS 6aXhXd4hIa8TXg0CvJjA/M2HBv/TpNdG+m/tzS5/vZ+l9KcvYwaShUgm3LcTEhIS8uriLIkHPAcy 9PJjLkbiwgoxvuT1rr4+VGC2nulChISEhIQswFm2nuS19ilFyOhbY8zZNfcICQkJCXl1cZa5oCE0 R2zXxvhlHL3QQnJISEhISMjicJYJcEhISEhIyKuDs8wFHRISEhIS8uogFOCQkJCQkJAzQCjAISEh ISEhZ4BQgENCQkJCQs4AoQCHhISEhIScAf4XFJochEBiW/QAAAAASUVORK5CYII= --Apple-Mail-130-792445274 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sep 1, 2009, at 11:12 AM, Robin Whittle wrote: > Short version: Since WG participants presumably believe that > LISP-ALT is either the only possible solution to > the scalable routing problem, or that it is > clearly superior to the alternatives (LISP-NERD, > APT and Ivip), then AFAIK the WG must be planning > to make LISP-ALT work in a future scenario in > which the great majority of its hundreds of > millions of EIDs are for individual mobile devices. > > If the scalable routing solution doesn't need to > handle mobile devices, then there will never be > more than a few million, perhaps 10 million, EIDs. > > LISP-NERD, APT or Ivip could scale to 10M EIDs > without any fuss. Any of these would all be > superior to LISP-ALT since none of them involve > delaying initial packets or depending on a > global-scale query server system - as ALT does. > NERD is nice and simple - nice and fast. If we > are not trying to do mass-market mobility, NERD > would be a better solution than ALT. > > > To complete this initial phase of work the WG > needs to establish a coherent plan for how LISP > would be deployed - how it would work in the next > few years and in the decades to come. That means > you need to plan how LISP will handle hundreds of > millions or billions of mobile devices, each with > its own EID. > > > > While I understand that development of LISP-mobile is out of scope > for the WG as currently chartered, I want to make two points. > > Firstly, anyone who is interested in LISP-mobile will probably find > it interesting to read my critique a month ago: > > Critique of Mobile LISP: draft-meyer-lisp-mn-00 - why not use the > TTR approach instead? > http://www.ietf.org/mail-archive/web/lisp/current/msg00772.html > > No-one has responded to this on list or privately. If Mobility is > out of scope for the WG, the RRG would be a good place to discuss it. > > > Secondly, as part of developing a well documented and hopefully > widely shared set of principles about what LISP is, how it is to be > deployed etc.: > > Discussing LISP deployment > Sam Hartman 2009-08-22 > http://www.ietf.org/mail-archive/web/lisp/current/msg01092.html > > I believe the WG must plan how LISP will do mobility. (I believe it > can, but only with the TTR mobility approach and not at all with the > approach of the recent LISP-mobile I-D.) > > > The entire WG effort to develop LISP is based on using the ALT > mapping distribution system, which is a successor to CONS. > > Both ALT and CONS go to a lot of trouble to avoid any one device > having to store the entire mapping database. The primary or perhaps > only reason for doing this is so that LISP can scale to very large > numbers of EIDs. > > AFAIK, the *only* reason you are pursuing ALT, instead of the > alternatives, is because of this goal of seemingly endless EID > scalability. > > I think everyone currently working on LISP ALT, or any similarly > endlessly scalable successor to ALT, needs to justify all this > effort, and all the difficulties this goal entails for scalable > routing and therefore all future Internet users, in terms of there > actually being a need, albeit in the long-term, for such large > numbers of EIDs that no other simpler alternative would be able to > cope. > > The most obvious alternative is LISP-NERD: every ITR downloads the > entire mapping database via HTTP or whatever from a bunch of servers. > Then it is pretty easy for end-user networks to update the mapping > in the central servers and let the changes propagate to all ITRs. > > NERD is simple and fast. There are no delayed or dropped packets as > there are with ALT. There is no fancy mapping distribution network - > no complex ALT network of routers with their long-paths, bottlenecks, > etc. > > NERD sits at the "simple" extreme of the spectrum. ALT sits at the > other end. > > In between are two systems - APT and Ivip - which involve ITRs > getting mapping in a few milliseconds, via a local query server. > This gives APT and Ivip the same major advantage as NERD compared to > ALT: no significant delays in ITRs tunneling initial packets. > Likewise, these three systems have the advantage over ALT that there > is no real-time, moment-to-moment, dependency on a global query > server system, with all its potential and likely delays and packet > loss problems. > > Both APT and Ivip enable most or all ITRs to be caching ITRs - since > they use local (such as in the same ISP) full database query servers. > So APT and Ivip ITRs are simpler and cheaper than NERD ITRs. > Therefore they can be more plentiful, closer to sending hosts - or in > the case of Ivip, *in* sending hosts (not behind NAT). > > ALT incurs major costs of complexity, global dependencies for ITRs to > work at all moment-to-moment - and most seriously it will delay > initial packets of a significant number of new communication flows, > by times such as fractions of a second to one or two seconds. That > will make it very hard for us to get it widely adopted. > > In order to justify pursing ALT, I understand you all must be > proceeding on the basis that none of the alternatives (LISP-NERD, APT > or Ivip) could possibly do the job. > > ALT has a bunch of disadvantages over these three, and AFAIK only one > potential advantage: the mapping database is entirely distributed, so > it can (in principle) handle vast numbers of EIDs without scaling > problems in any one device. > > To establish that ALT is the only realistic approach to scalable > routing, AFAIK, you need to prove to yourselves that ALT's endless > scalability is absolutely essential to the successful long-term > resolution of the routing scalability problem. > > In order to do this, I think you would need to establish three things > at least: > > 1 - That there will be a demand for a very high number of EIDs - > say YYY million EIDs. > > 2 - That ALT can scale well, solving the routing scalability > problem, handling this number YYY million EIDs, at some time > in the future when this number will be needed. > > 3 - That no other alternative (currently LISP-NERD, APT or Ivip) > could be developed to the point where it could handle YYY > million EIDs, whenever in the future (2020, 2030 etc.) these > will be required. > > > Lets toss some numbers around. > > At what number of EIDs would LISP-NERD encounter serious scaling > problems? Lets think IPv6 mapping with (I guess) about 100 bytes per > EID. PCs today (and therefore today's servers and dedicated routers > in a few years time) have 8, 12 or whatever GB of RAM. They have > terabyte hard drives too. Even for ECC RAM, the cost is > insignificant in the scheme of things. > > A LISP-NERD ITR will be a caching ITR with packet switching in > hardware or software - co-located with a full database query server. > The query server would be in the same box, including the same > server/router, or in the same rack just one or two patch cables away. > I will assume the full mapping database sits in RAM. > > Even if every EID consumed 256 bytes of RAM, a 12GB machine can > handle 48 million EIDs. > > The task of sending all the world's mapping data to these LISP-NERD > ITRs will not be a problem. By the time we have 48M EIDs, bandwidth > will be even cheaper than it is today. The update traffic is not > going to be high, since LISP mappings don't change all that often. > The whole of LISP is built on the relative stability of mappings, > with ITRs handling the moment-to-moment changes in reachability, > making their own decisions about which of multiple ETRs to tunnel the > packets to. (APT makes the same assumption. Ivip is totally > different in this regard.) > > So for LISP-ALT to be chosen in preference to the simple, chunky, > fast, LISP-NERD, you must be planning to handle more than 10s of > millions of EIDs. You must be requiring the scalable routing > solution to cope with hundreds of millions of EIDs - billions or even > 10 billion. > > With equivalent hardware and communication costs, both APT and Ivip > can scale to a much larger number of EIDs than LISP-NERD, because > only the local query servers have to store the full mapping database > and get all the updates. Dozens or hundreds of much simpler ITRs can > work from a single local query server - so for the same or more > likely much lower total cost you can make these local query servers > more expensive, with massive RAM, multiple CPUs etc. > > Its hard to put a figure on it, but lets say that with 2025 > technology and communication costs, APT or Ivip could scale nicely to > handle 200M EIDs, 500M EIDs or the like. > > If you are still sure that ALT is the only way to solve the routing > scaling problem, then you must be planning on handling 500M, 1B, 5B > or more EIDs. > > This means you must be planning on most of those EIDs being for > individual mobile devices, because there is never going to be demand > for non-mobile EIDs in anything like these numbers. > > There's only a subset of non-mobile Internet customers who have any > significant motivation to use a scalable routing solution - for the > benefits of multihoming, and/or portability between ISPs and/or > inbound traffic engineering if they are multihomed. > > If the population grows to 10B people, there are only going to be a > finite number of businesses or other organisations big enough to want > any of these benefits of scalable routing. Let's assume there is one > such organisation for every 1000 people (10,000 people seems more > realistic to me). > > As long as the scalable routing solution doesn't have to provide an > EID for mobile devices, then the maximum number of end-user networks > it needs to support will be 10M. Some will have two or more EIDs, > but most will only have one. > > So if the scalable routing solution is not directly involved in > mobility, then you simply don't need something as complex and > problematic (initial packet delays ...) as ALT, because the > alternatives LISP-NERD, APT and Ivip will scale just fine to 10M EIDs. > > Therefore, if you are convinced that LISP-ALT is the only viable > approach to scalable routing, AFAIK, you must believe: > > 1 - The scalable routing solution must provide an EID for each > mobile device. > > AND > > 2 - There will be hundreds of millions or billions of these mobile > devices - enough that NERD, APT or Ivip couldn't possibly scale > to this number of EIDs, even with the technology of 2020, 2030 > etc. > > AND > > 3 - LISP-ALT will scale nicely when it does handle hundreds of > millions or billions of EIDs - and the great majority of those > EIDs are going to be for hand-held mobile devices. > > > As I wrote in my critique, I believe you can't make LISP work with > mobile devices as per the current I-D. I believe you could make > LISP-ALT support mobility, including for billions of EIDs, using the > TTR approach to mobility: > > http://www.firstpr.com.au/ip/ivip/#mobile > > I explained this over two years ago and Steve Russert and I wrote up > this nice documentation of it a year ago. > > So as far as I can see, as long as you believe LISP-ALT is the only > viable solution to the scalable routing problem, in order to > establish how LISP will really work in the long-term, you need to > plan now for how LISP-ALT will handle hundred of millions of EIDs for > individual mobile devices. > > - Robin > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-130-792445274-- From hartmans@mit.edu Tue Sep 1 12:04: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 5733D28C9A9 for ; Tue, 1 Sep 2009 12:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O34V3IJrfTTU for ; Tue, 1 Sep 2009 12:04: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 88FA628CA10 for ; Tue, 1 Sep 2009 12:03:35 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B318D646C1; Tue, 1 Sep 2009 15:02:51 -0400 (EDT) To: Robin Whittle References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> <4A9D641F.3090209@firstpr.com.au> From: Sam Hartman Date: Tue, 01 Sep 2009 15:02:51 -0400 In-Reply-To: <4A9D641F.3090209@firstpr.com.au> (Robin Whittle's message of "Wed\, 02 Sep 2009 04\:12\:47 +1000") 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] 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: Tue, 01 Sep 2009 19:04:20 -0000 >>>>> "Robin" == Robin Whittle writes: Robin> Short version: Since WG participants presumably believe Robin> that LISP-ALT is either the only possible solution to the Robin> scalable routing problem, or that it is clearly superior to Robin> the alternatives (LISP-NERD, APT and Ivip), then AFAIK the Robin> WG must be planning to make LISP-ALT work in a future Robin> scenario in which the great majority of its hundreds of Robin> millions of EIDs are for individual mobile devices. Robin> If the scalable routing solution doesn't Robin> need to handle mobile devices, then there will never be Robin> more than a few million, perhaps 10 million, EIDs. I don't think there is a consensus that lisp-alt is superior. It's simply what we have to experiment with today and what this WG is chartered to specify. I think that the people I've talked to suspect that the mapping system is going to require a lot of work and that is probably one of the bits that may well be revised between experimental and standards track. So, while working on alt, we're also working on requirements for a standards-track mapping system. From mrw@sandstorm.net Tue Sep 1 12:44: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 804D83A6E5F for ; Tue, 1 Sep 2009 12:44:27 -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 8MfeUoehn3zF for ; Tue, 1 Sep 2009 12:44:26 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id E33A33A6910 for ; Tue, 1 Sep 2009 12:43:14 -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 n81Jf0P5092704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2009 15:41:00 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <2401CD13-AD64-449A-BE2A-DBB4FDE901DD@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090901180923.078696BE60E@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, 1 Sep 2009 15:40:59 -0400 References: <20090901180923.078696BE60E@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) 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: Tue, 01 Sep 2009 19:44:27 -0000 On Sep 1, 2009, at 2:09 PM, Noel Chiappa wrote: > > The difference is that in your alternative scenario, while you may > (see > below) have preserved a bit of flexibility for the future (i.e. > being able to > have instances in which both R and one of {N,L} are set), you have > done so at > the cost of making it harder to incrementally deploy in general > service some > new mechanism which uses the R-bit, since in your scenario non- > upgraded boxes > would (I assume) toss packets with that bit set (since it would be > 'reserved'). Actually, the specification says that the reserved bit are set to zero on transmit and ignored on receipt. So, they can be used for extensions that are non-harmful to existing nodes without any need to explicitly document those reasons on the specification unless/until we are ready to document what they are actually being used for. Margaret From mrw@sandstorm.net Tue Sep 1 12:57: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 B795828C9CF for ; Tue, 1 Sep 2009 12:57:27 -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 PiBFNGdkJDKa for ; Tue, 1 Sep 2009 12:57:26 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id BAB5C28C739 for ; Tue, 1 Sep 2009 12:57:26 -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 n81JuiKI093577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2009 15:56:44 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <8D8ECB5B-C6EE-4708-9C6A-00C4DC3BE543@sandstorm.net> From: Margaret Wasserman To: Margaret Wasserman In-Reply-To: <2401CD13-AD64-449A-BE2A-DBB4FDE901DD@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, 1 Sep 2009 15:56:44 -0400 References: <20090901180923.078696BE60E@mercury.lcs.mit.edu> <2401CD13-AD64-449A-BE2A-DBB4FDE901DD@sandstorm.net> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , 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: Tue, 01 Sep 2009 19:57:27 -0000 On Sep 1, 2009, at 3:40 PM, Margaret Wasserman wrote: > > Actually, the specification says that the reserved bit are set to > zero on transmit and ignored on receipt. So, they can be used for > extensions that are non-harmful to existing nodes without any need > to explicitly document those reasons on the specification unless/ > until we are ready to document what they are actually being used for. On re-reading, I realized that this is at least semi-incomprehensible... The second sentence should have read: So, the reserved flags can be used for extensions that are non-harmful to existing nodes. When we want to try out a new extensions that isn't ready to be formally considered by the WG, we can do that without the need to reserve a specific flag in the document. We can wait to define a new flag in the document until we know what that flag will be used for, and how nodes that send/receive that flag are supposed to behave. In the case of the R-bit, I think it would be better to wait (leaving the flag reserved until we are ready to fully document it) than to reserve a flag without any real explanation of how it will be used. I have the same thought about the M bit in the mapping replies. Margaret From rw@firstpr.com.au Tue Sep 1 21:46: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 436AC28C418 for ; Tue, 1 Sep 2009 21:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE8JAHRXZ7Uo for ; Tue, 1 Sep 2009 21:46:27 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 0A18528C27F for ; Tue, 1 Sep 2009 21:46:25 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 299B8175C35; Wed, 2 Sep 2009 14:43:52 +1000 (EST) Message-ID: <4A9DF80A.8010508@firstpr.com.au> Date: Wed, 02 Sep 2009 14:43:54 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: lisp@ietf.org References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> <4A9D641F.3090209@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Noel Chiappa 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, 02 Sep 2009 04:46:28 -0000 I am replying to Noel, Dino and Sam. Short version: If the purpose of the WG is to explore LISP on an experimental basis, then that's fine - Mobility can be ignored. However, since the purpose of this exploration is to devise a lasting system for the Internet, then in laying the experimental foundations of LISP-ALT, we need to ensure this basis is correct for the long- term task of solving the routing scaling problem. Mobility is a vital part of the future of the Internet. Conventional mobility techniques don't provide global mobility, in any access network, with generally optimal path lengths and full compatibility with existing non-mobile hosts. The TTR Mobility approach solves these problems - for IPv4 and IPv6. So I think the current work of the WG needs to at least involve some plan for how LISP-ALT will handle mobility. Without this, the work risks being irrelevant to the final design of the optimal routing scaling problem. If there's no need for mobility, the total number of EIDs is limited - so it is not so hard to design a good system. Then, something simpler like NERD would be preferable to ALT. Mobility in the form of the TTR approach will definitely happen, because this is the only mobility system (AFAIK) which provides global mobility, in any access network (including behind NAT), with generally optimal path lengths and with session continuity - while remaining compatible with existing apps and stacks. (Also, it will work fine for IPv4 and IPv6.) Conventional mobile IP can't do these things. TTR mobility will happen irrespective of the routing scaling problem, so any solution to the routing scaling problem needs to integrate it, rather than let it run as a separate system. The TTR approach should work fine for LISP. The current LISP-mobile approach has many problems: http://www.ietf.org/mail-archive/web/lisp/current/msg00749.html http://www.ietf.org/mail-archive/web/lisp/current/msg00772.html not least that each IPv4 MN using this approach would require not just its EID address, but a full public RLOC address to for its CoA. It can't work with the MN behind NAT, which is the typical connectivity arrangement for IPv4. The TTR approach works fine with the MN behind NAT. Noel wrote: > Actually, ALT is generally considered a short-medium term thing - > for the long term, the concept is to replace it. Is this the consensus view? If so, then why bother with ALT at all? The whole challenge is to devise an architecture which will work for decades. Why not develop the proper solution, if ALT is not it? Thanks Dino for the diagram. You wrote: > Robin, I just want to make one technical response with a few > points: > > (1) LISP-ALT does not carry mappings. The entire scalable routing system needs to scale to some number of EIDs. LISP-ALT's major - perhaps only - claim to superiority is that it can, supposedly, scale to arbitrary numbers of EIDs since there is no need to have any one device or communication path handle the total mapping data for all EIDs, or updates to that. The LISP ALT network needs to convey a packet sent by an ITR, with a destination address being the EID of the destination host, to either: 1 - The ETR (or one of multiple ETRs) which is currently authoritative for the mapping for the EID prefix which the destination host's EID address is part of, or: 2 - To some device which, while not being authoritative or an ETR, does know the current mapping and can send the mapping back to ITR via the Internet. Therefore, the ALT network needs to be able to handle these packets from ITRs (whether they are map requests, or initial traffic packets which also function as map requests) and have all its ALT routers already set up, via the ALT BGP system, to forward those packets correctly. > (2) LISP-ALT carries EID-prefixes registered from sites to a > specific aggregation boundary. > > (3) LISP-ALT also carries aggregated EID-prefixes into the core > (the LISP-ALT core), upstream from the aggregation boundaries. I don't think the LISP-ALT network physically carries either mappings or EID prefixes. It carries map-request packets from any ITR, ideally via a short path, to a device such as an ETR which can reliably answer the request and send mapping information directly to the ITR. > (4) When a mobile-node changes locations and gets a new locator, > nothing in LISP-ALT changes. The mobile-node keeps > Map-Registering to its Map-Server which is the same ALT > topological point regardless where the mobile-node moves to > or how often it moves. Mobile-node roaming causes no route > injection or withdrawal in the BGP that runs on the ALT. Yes - I understand this. > I have enclosed a picture of how the mapping database architecture > is modular. So if you want to remove the center piece (labeled > ALT), you can insert your favorite solution and the outer elements > don't have to change (i.e. xTRs and CPE devices). I don't find the diagram very helpful. The problems with the current LISP-mobile approach do not result directly from LISP-ALT - they are inherent in the core principle of LISP-mobile which is to make the MN become its own ETR. The TTR approach works differently. The particular TTR which any one MN is using as its ETR remains stable as the MN moves around, gaining new and often multiple CoAs. If the MN moves far away (such as 1000km or more) from that TTR, then it still has connectivity. However, to reduce overall path lengths, the MN will find another TTR which is closer to its new CoA. There is only a change to the the mapping of the MN's EID when it starts to use a new TTR like this. While the mapping change is propagating, the MN can receive packets via the old and the new TTRs simultaneously, and via its 2-way tunnel to each of them, use either one for its outgoing packets. With the TTR approach there are few mapping changes and there is continual continuity via one or more CoAs to the current TTR, no matter how rapidly CoAs are gained and lost. With the current conception of LISP-mobile, when the MN goes to another address (which I call a Care of Address - CoA - meaning just that the MN gets a new point of attachment to the Net) in order to maintain connectivity it needs to change the mapping of its own individual EID prefix: to this new CoA. Only when all ITRs which are tunneling packets to the MN have this new RLOC can communication continue. The MN would need to send (or cause something else to send) a secure map update message to every ITR which is caching its old mapping. Caching times need to be long in order to avoid burdening the ALT network with too much map-query traffic. So the MN (or whatever other devices help it) has a lot of work to do as soon as it gets a new CoA. The longer the ITRs caching time and the more ITRs have been sending packets to the MN during the caching time, the more updates need to be sent and so the more management traffic and overall burden on ITRs there will be. There are time delays, computational and communication costs, reliability problems etc. involved in the MN telling a potentially large number of ITRs about its new CoA. This has to happen every time there is a new CoA. With the TTR approach, when the MN gets a new CoA the MN only needs to establish a 2 way tunnel with its current TTR (or one of its current TTRs) in order to maintain connectivity. The ITRs and the mapping system are not affected by the new CoA. A mobile device might gain and loose CoAs automatically and so, change them every few seconds according to radio propagation changes while travelling in urban environments. So the TTR gets a workout - but nothing else needs to know about each new CoA. LISP was devised with the assumption that mappings would change infrequently. LISP-mobile can only work if they change frequently and instantly. LISP-ALT can't do either of these things. The TTR approach will work fine within these constraints - the mappings do not change frequently and it doesn't matter so much if the ITRs take a while to get the updated mapping. My understanding of the purpose of this WG is that it is to do early development work on a particular approach to the core-edge separation scheme - LISP-ALT. You have chosen this over the alternatives because you believe it is superior to them all, and to anything else you can currently think of. Therefore, the WG's goal is to lay the foundation for the future of the Internet - which will include Mobility. All I am saying is that in the current scenario where there is great confusion about what LISP-ALT is supposed to do - how it is to be deployed etc. http://www.ietf.org/mail-archive/web/lisp/current/msg01092.html you need to plan for mobility, because it will be part of the final total system. I am also saying that the current LISP-mobile approach won't work and the TTR approach will. Hi Sam, you wrote: > I don't think there is a consensus that lisp-alt is superior. It's > simply what we have to experiment with today and what this WG is > chartered to specify. But few if any of the people in this WG would be putting any effort into LISP-ALT if they did not think it was the best solution. There are other solutions - NERD, APT and Ivip at least. The fact that many people spend a huge amount of effort here working on LISP-ALT, in preference to helping with or even publicly critiquing APT or Ivip signifies to me that those people believe that LISP-ALT is and will remain the best solution to the routing scaling problem. > I think that the people I've talked to suspect that the mapping > system is going to require a lot of work and that is probably one > of the bits that may well be revised between experimental and > standards track. > So, while working on alt, we're also working on requirements for a > standards-track mapping system. APT, Ivip and LISP have all been around for more than two years. The TTR mobility approach was first described with the initial Ivip description in June 2007 - but it has always been a modular concept which can work fine with LISP or APT. I observe a bunch of people devoting all their attention to LISP, not even bothering to critique APT or Ivip. To me, this means that these people must believe that LISP-ALT is the way forward. You are different, in that you were asked to participate in this WG - and you have graciously devoted great efforts to the task. I recognise you don't necessarily think that LISP-ALT is the best approach. I am different in that I think Ivip is the best approach, but I want to keep an eye on LISP development and learn from it. I will contribute to discussions when I see a problem with LISP-ALT which seems not to be properly recognised. - Robin From jari.arkko@piuha.net Wed Sep 2 01:15: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 B7E2A3A6992 for ; Wed, 2 Sep 2009 01:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[AWL=-0.114, 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 e8ItmuqBmbJE for ; Wed, 2 Sep 2009 01:15:12 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D9B973A68DB for ; Wed, 2 Sep 2009 01:15:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 46259D62D5; Wed, 2 Sep 2009 11:15:26 +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 PqPwjjudMayD; Wed, 2 Sep 2009 11:15:25 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 8019DD620E; Wed, 2 Sep 2009 11:15:25 +0300 (EEST) Message-ID: <4A9E299D.7000909@piuha.net> Date: Wed, 02 Sep 2009 11:15:25 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Sam Hartman References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> <4A9D641F.3090209@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robin Whittle , 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, 02 Sep 2009 08:15:12 -0000 Sam, Robin, > I don't think there is a consensus that lisp-alt is superior. It's > simply what we have to experiment with today and what this WG is > chartered to specify. That's right. The mapping system is the area where I at least am most uncertain about what really works and what doesn't. But the approach we are taking with this working group is not that we decided a prior that ALT (or even LISP itself) is the right answer. Our approach is that to fully understand the proposals we have we should develop them into completion and implement and test them -- only then we can decide if ALT actually is the right way to build mapping systems. There's definitely room for exploring other designs as well -- but this working group has to first focus on the small slice it has decided to take on. Jari From luigi@net.t-labs.tu-berlin.de Wed Sep 2 03:59: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 5F4433A69A1 for ; Wed, 2 Sep 2009 03:59:35 -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 4TBQbrP4221x for ; Wed, 2 Sep 2009 03:59:34 -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 C11143A689A for ; Wed, 2 Sep 2009 03:58:28 -0700 (PDT) Received: from [192.168.0.10] (ivr94-2-81-56-53-60.fbx.proxad.net [81.56.53.60]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id E110C705CC82; Wed, 2 Sep 2009 12:57:05 +0200 (CEST) Message-Id: From: Luigi Iannone 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: Wed, 2 Sep 2009 12:57:05 +0200 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [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: Wed, 02 Sep 2009 10:59:35 -0000 On Aug 27, 2009, at 16:56 , Sam Hartman wrote: > > > 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? Yes > If so, why? Interoperability. Let me try to explain the idea about the R-bit (and hopefully addressing Joel's concerns). The basic idea is to have a bit that allows to overload two fields of the LISP header: Nonce and Loc-bits. In this way, when R = 1 we can put version numbers in the overloaded fields. Concerning draft-iannone-lisp-versioning-00, will update it in order to respect bit's position of the new header and to be coherent with draft-ietf-lisp-04. Having said that, we have also to keep in mind interoperability with boxes that do not support the R-bit. Those boxes will ignore the R bit, thus making mandatory that when R=1 then N and L must be 0 allows to safely make the ETR ignore the overloaded fields. Doing otherwise would lead to totally incompatible headers and implementations. We really do not need that. About Joel's concern on the case R=1 and L and N any combination that is not 00: For boxes that do not understand R bit: These boxes will ignore the R-bit and behave normally with the other two bits (and consecutive actions). I do not see any harm here. What if the R bit is set due to an error on the wire? This can always happen, even with other reserved flags. On the other hand, I do not think that this introduces any additional security issue. (spoofing is always possible whatever header we define) For boxes that understand the R-bit: Let me start by saying that this issue should not be tackled IMHO in draft-ietf-lisp-04. I think it belongs to documents that define the meaning of the overloaded fields (draft-iannone-lisp-versioning). Now, since it is not possible to know the real meaning of the fields I would suggest to silently drop the packet, because: - If it is the result of an error on the wire, this is so rare that dropping a packet once in a while causes no harm. - If it is someone sending ill formed packets, thus playing with the rules, we do not need to consider it. At the end, I do not think that we need any error message, as suggested by Joel. About the issue of just making it a reserved bit, I do not see why we should do that. I do not remember by heart the wording in draft-ietf-lisp-04 (apologies I am on holiday and would like to spend my last days in a different way rather then going again over the document) but as far as I remember it was clear (to me at least). The document clearly state that the R bit is used for research purposes and how to deal with the N and L bits. It is not in the scope of that document to describe in details the content of the overloaded fields, but just to assure that there is interoperability. In this way, different "flavours" of lisp can still talk to each other. Making the bit reserved could open the door to problems (as Noel suggested in one of his mails) that later on packet with the R bit set will be just dropped. Hope this clarifies things. Luigi > > Comments from others on this issue would also be very useful. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Wed Sep 2 06:29: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 3D9223A6B8D for ; Wed, 2 Sep 2009 06:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 WZln6WdLTDxN for ; Wed, 2 Sep 2009 06:29:09 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 6AC5228C0F5 for ; Wed, 2 Sep 2009 06:29:08 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D805251C5; Wed, 2 Sep 2009 09:14:53 -0400 (EDT) To: Robin Whittle References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> <4A9D641F.3090209@firstpr.com.au> <4A9DF80A.8010508@firstpr.com.au> From: Sam Hartman Date: Wed, 02 Sep 2009 09:14:53 -0400 In-Reply-To: <4A9DF80A.8010508@firstpr.com.au> (Robin Whittle's message of "Wed\, 02 Sep 2009 14\:43\:54 +1000") 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, Noel Chiappa 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, 02 Sep 2009 13:29:10 -0000 >>>>> "Robin" == Robin Whittle writes: Robin> However, since the purpose of this Robin> exploration is to devise a lasting system for the Internet, Robin> then in laying the experimental foundations of LISP-ALT, we Robin> need to ensure this basis is correct for the long- term Robin> task of solving the routing scaling problem. Robin> Mobility is a vital part of the future of Robin> the Internet. Conventional mobility techniques don't Robin> provide global mobility, in any access network, with Robin> generally optimal path lengths and full compatibility with Robin> existing non-mobile hosts. The TTR Mobility approach Robin> solves these problems - for IPv4 and IPv6. I don't know what the TTR mobility approach is. However, determining whether we agree with the statement above is out of scope. Robin> So I think the current work of the WG Robin> needs to at least involve some plan for how LISP-ALT will Robin> handle mobility. Without this, the work risks being Robin> irrelevant to the final design of the optimal routing Robin> scaling problem. This is definitely out of scope as well. What is probably in scope is to contribute a section to the mapping analysis/requirements document on what the requirements might be for various mobility approaches if we decide LISP should support mobility. Any effort you want to expend towards that would be greatly appreciated. From dmm@1-4-5.net Wed Sep 2 07:45: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 801D13A68C4 for ; Wed, 2 Sep 2009 07:45: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 uckngBIbB1AC for ; Wed, 2 Sep 2009 07:45:30 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id D259828C8A1 for ; Wed, 2 Sep 2009 07:45:29 -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 n82EiPmj021479; Wed, 2 Sep 2009 07:44:25 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n82EiPXq021478; Wed, 2 Sep 2009 07:44:25 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 2 Sep 2009 07:44:25 -0700 From: David Meyer To: Robin Whittle Message-ID: <20090902144425.GA21452@1-4-5.net> References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> <4A9D641F.3090209@firstpr.com.au> <4A9DF80A.8010508@firstpr.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <4A9DF80A.8010508@firstpr.com.au> 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, Noel Chiappa 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, 02 Sep 2009 14:45:31 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable WG charis: Pursuant to this email: =46rom: Jari Arkko To: "Darrel Lewis (darlewis)" Cc: Robin Whittle , lisp@ietf.org Subject: Re: [lisp] LISP Mobility Architecture Date: Tue, 01 Sep 2009 21:27:48 +0300 Then maybe I need to be clearer. Mobility and many other advanced features are out of scope. For now. When you complete the base specifications, we can talk about rechartering to add more features. Can we kill this tread? Thanks, Dave --- On Wed, Sep 02, 2009 at 02:43:54PM +1000, Robin Whittle wrote: > I am replying to Noel, Dino and Sam. >=20 > Short version: If the purpose of the WG is to explore LISP on an > experimental basis, then that's fine - Mobility > can be ignored. >=20 > However, since the purpose of this exploration is to > devise a lasting system for the Internet, then in > laying the experimental foundations of LISP-ALT, we > need to ensure this basis is correct for the long- > term task of solving the routing scaling problem. >=20 > Mobility is a vital part of the future of the > Internet. Conventional mobility techniques don't > provide global mobility, in any access network, > with generally optimal path lengths and full > compatibility with existing non-mobile hosts. > The TTR Mobility approach solves these problems - > for IPv4 and IPv6. >=20 > So I think the current work of the WG needs to at > least involve some plan for how LISP-ALT will > handle mobility. Without this, the work risks > being irrelevant to the final design of the > optimal routing scaling problem. >=20 >=20 > If there's no need for mobility, the total number > of EIDs is limited - so it is not so hard to > design a good system. Then, something simpler > like NERD would be preferable to ALT. >=20 > Mobility in the form of the TTR approach will > definitely happen, because this is the only > mobility system (AFAIK) which provides global > mobility, in any access network (including behind > NAT), with generally optimal path lengths and with > session continuity - while remaining compatible with > existing apps and stacks. (Also, it will work fine > for IPv4 and IPv6.) Conventional mobile IP can't do > these things. >=20 > TTR mobility will happen irrespective of the > routing scaling problem, so any solution to the > routing scaling problem needs to integrate it, > rather than let it run as a separate system. The > TTR approach should work fine for LISP. >=20 > The current LISP-mobile approach has many problems: >=20 > http://www.ietf.org/mail-archive/web/lisp/current/msg00749.html > http://www.ietf.org/mail-archive/web/lisp/current/msg00772.html >=20 > not least that each IPv4 MN using this approach > would require not just its EID address, but a full > public RLOC address to for its CoA. It can't work > with the MN behind NAT, which is the typical > connectivity arrangement for IPv4. The TTR approach > works fine with the MN behind NAT. >=20 >=20 >=20 > Noel wrote: >=20 > > Actually, ALT is generally considered a short-medium term thing - > > for the long term, the concept is to replace it. >=20 > Is this the consensus view? If so, then why bother with ALT at all? > The whole challenge is to devise an architecture which will work for > decades. Why not develop the proper solution, if ALT is not it? >=20 >=20 > Thanks Dino for the diagram. You wrote: >=20 > > Robin, I just want to make one technical response with a few > > points: > > > > (1) LISP-ALT does not carry mappings. >=20 > The entire scalable routing system needs to scale to some number of > EIDs. LISP-ALT's major - perhaps only - claim to superiority is that > it can, supposedly, scale to arbitrary numbers of EIDs since there is > no need to have any one device or communication path handle the total > mapping data for all EIDs, or updates to that. >=20 > The LISP ALT network needs to convey a packet sent by an ITR, with a > destination address being the EID of the destination host, to either: >=20 > 1 - The ETR (or one of multiple ETRs) which is currently > authoritative for the mapping for the EID prefix which the > destination host's EID address is part of, >=20 > or: >=20 > 2 - To some device which, while not being authoritative or an ETR, > does know the current mapping and can send the mapping back to > ITR via the Internet. >=20 > Therefore, the ALT network needs to be able to handle these packets > from ITRs (whether they are map requests, or initial traffic packets > which also function as map requests) and have all its ALT routers > already set up, via the ALT BGP system, to forward those packets > correctly. >=20 >=20 > > (2) LISP-ALT carries EID-prefixes registered from sites to a > > specific aggregation boundary. > > > > (3) LISP-ALT also carries aggregated EID-prefixes into the core > > (the LISP-ALT core), upstream from the aggregation boundaries. >=20 > I don't think the LISP-ALT network physically carries either mappings > or EID prefixes. It carries map-request packets from any ITR, > ideally via a short path, to a device such as an ETR which can > reliably answer the request and send mapping information directly to > the ITR. >=20 >=20 > > (4) When a mobile-node changes locations and gets a new locator, > > nothing in LISP-ALT changes. The mobile-node keeps > > Map-Registering to its Map-Server which is the same ALT > > topological point regardless where the mobile-node moves to > > or how often it moves. Mobile-node roaming causes no route > > injection or withdrawal in the BGP that runs on the ALT. >=20 > Yes - I understand this. >=20 >=20 > > I have enclosed a picture of how the mapping database architecture > > is modular. So if you want to remove the center piece (labeled > > ALT), you can insert your favorite solution and the outer elements > > don't have to change (i.e. xTRs and CPE devices). >=20 > I don't find the diagram very helpful. >=20 > The problems with the current LISP-mobile approach do not result > directly from LISP-ALT - they are inherent in the core principle of > LISP-mobile which is to make the MN become its own ETR. >=20 > The TTR approach works differently. The particular TTR which any one > MN is using as its ETR remains stable as the MN moves around, gaining > new and often multiple CoAs. If the MN moves far away (such as > 1000km or more) from that TTR, then it still has connectivity. > However, to reduce overall path lengths, the MN will find another TTR > which is closer to its new CoA. There is only a change to the the > mapping of the MN's EID when it starts to use a new TTR like this. > While the mapping change is propagating, the MN can receive packets > via the old and the new TTRs simultaneously, and via its 2-way tunnel > to each of them, use either one for its outgoing packets. >=20 > With the TTR approach there are few mapping changes and there is > continual continuity via one or more CoAs to the current TTR, no > matter how rapidly CoAs are gained and lost. >=20 > With the current conception of LISP-mobile, when the MN goes to > another address (which I call a Care of Address - CoA - meaning just > that the MN gets a new point of attachment to the Net) in order to > maintain connectivity it needs to change the mapping of its own > individual EID prefix: to this new CoA. Only when all ITRs which are > tunneling packets to the MN have this new RLOC can communication > continue. The MN would need to send (or cause something else to > send) a secure map update message to every ITR which is caching its > old mapping. Caching times need to be long in order to avoid > burdening the ALT network with too much map-query traffic. So the MN > (or whatever other devices help it) has a lot of work to do as soon > as it gets a new CoA. >=20 > The longer the ITRs caching time and the more ITRs have been sending > packets to the MN during the caching time, the more updates need to > be sent and so the more management traffic and overall burden on ITRs > there will be. There are time delays, computational and > communication costs, reliability problems etc. involved in the MN > telling a potentially large number of ITRs about its new CoA. This > has to happen every time there is a new CoA. >=20 > With the TTR approach, when the MN gets a new CoA the MN only needs > to establish a 2 way tunnel with its current TTR (or one of its > current TTRs) in order to maintain connectivity. The ITRs and the > mapping system are not affected by the new CoA. A mobile device > might gain and loose CoAs automatically and so, change them every few > seconds according to radio propagation changes while travelling in > urban environments. So the TTR gets a workout - but nothing else > needs to know about each new CoA. >=20 >=20 >=20 > LISP was devised with the assumption that mappings would change > infrequently. LISP-mobile can only work if they change frequently > and instantly. LISP-ALT can't do either of these things. >=20 > The TTR approach will work fine within these constraints - the > mappings do not change frequently and it doesn't matter so much if > the ITRs take a while to get the updated mapping. >=20 >=20 > My understanding of the purpose of this WG is that it is to do early > development work on a particular approach to the core-edge separation > scheme - LISP-ALT. You have chosen this over the alternatives > because you believe it is superior to them all, and to anything else > you can currently think of. >=20 > Therefore, the WG's goal is to lay the foundation for the future of > the Internet - which will include Mobility. >=20 > All I am saying is that in the current scenario where there is great > confusion about what LISP-ALT is supposed to do - how it is to be > deployed etc. >=20 > http://www.ietf.org/mail-archive/web/lisp/current/msg01092.html >=20 > you need to plan for mobility, because it will be part of the final > total system. >=20 > I am also saying that the current LISP-mobile approach won't work and > the TTR approach will. >=20 >=20 > Hi Sam, you wrote: >=20 > > I don't think there is a consensus that lisp-alt is superior. It's > > simply what we have to experiment with today and what this WG is > > chartered to specify. >=20 > But few if any of the people in this WG would be putting any effort > into LISP-ALT if they did not think it was the best solution. >=20 > There are other solutions - NERD, APT and Ivip at least. >=20 > The fact that many people spend a huge amount of effort here working > on LISP-ALT, in preference to helping with or even publicly > critiquing APT or Ivip signifies to me that those people believe that > LISP-ALT is and will remain the best solution to the routing scaling > problem. >=20 > > I think that the people I've talked to suspect that the mapping > > system is going to require a lot of work and that is probably one > > of the bits that may well be revised between experimental and > > standards track. >=20 > > So, while working on alt, we're also working on requirements for a > > standards-track mapping system. >=20 > APT, Ivip and LISP have all been around for more than two years. The > TTR mobility approach was first described with the initial Ivip > description in June 2007 - but it has always been a modular concept > which can work fine with LISP or APT. >=20 > I observe a bunch of people devoting all their attention to LISP, not > even bothering to critique APT or Ivip. >=20 > To me, this means that these people must believe that LISP-ALT is the > way forward. >=20 > You are different, in that you were asked to participate in this WG - > and you have graciously devoted great efforts to the task. I > recognise you don't necessarily think that LISP-ALT is the best approach. >=20 > I am different in that I think Ivip is the best approach, but I want > to keep an eye on LISP development and learn from it. I will > contribute to discussions when I see a problem with LISP-ALT which > seems not to be properly recognised. >=20 > - Robin >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --gKMricLos+KVdGMg 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) iEYEARECAAYFAkqehMkACgkQORgD1qCZ2KdhggCfdrwny3MLIysttcIEUjIf3Ilt RCcAoIMLC5c4Dv+GX6O5PEcH95g30vyC =WMBY -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From rw@firstpr.com.au Wed Sep 2 09:48: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 2ED073A6B54 for ; Wed, 2 Sep 2009 09:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h1SUqj2Cyvq for ; Wed, 2 Sep 2009 09:48:52 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 5E84D3A67AD for ; Wed, 2 Sep 2009 09:48:51 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id AD5051755CE; Thu, 3 Sep 2009 02:47:14 +1000 (EST) Message-ID: <4A9EA195.70309@firstpr.com.au> Date: Thu, 03 Sep 2009 02:47:17 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: lisp@ietf.org References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> <4A9D641F.3090209@firstpr.com.au> <4A9DF80A.8010508@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Noel Chiappa Subject: Re: [lisp] LISP Mobility Architecture - mapping requirements for TTR mobility X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 02 Sep 2009 16:48:53 -0000 Hi Sam, You wrote in part: > I don't know what the TTR mobility approach is. I proposed the Translating Tunnel Router approach on 2007-06-15: http://www.ietf.org/mail-archive/web/ram/current/msg01518.html It is fully described here: TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem Robin Whittle (First Principles) and Steven Russert (Boeing) http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf 2008-08-25 Briefly, a TTR behaves to LISP etc. just like any ETR. MNs make a 2-way tunnel from their CoA (including from behind NAT) to a nearby TTR. The TTR also sends the MN's outgoing packets to the rest of the world, so it may include an ITR function too. TTRs are typically located outside access networks, so a MN using multiple access networks in the one city or region can keep using the same TTR. No mapping changes for the MN's EID are required as long as it keeps using the same TTR. The MN can still use that TTR from a CoA on the other side of the world, but for efficiency it would be best to use a TTR near where it is currently located. Then, with a new TTR, there needs to be a mapping change. The MN doesn't need any conventional Mobile IP capabilities, or to be in a mobile-ready access network. The MN gets its CoA like any other host - WiFi, cabled Ethernet, 3G or whatever - including behind one or more layers of NAT and including with DHCP assigned and potentially unstable addresses. If the MN's address lease expires and it gets another CoA, it needs to establish a fresh tunnel from the new CoA to its one or more current TTRs. No mapping changes are needed for this. The TTR system should work fine for IPv4 and IPv6. It provides global mobility, with the MN retaining the one EID address for all application traffic. The main IP stack in the MN is unchanged, as are the applications. The MN communicates normally with all correspondent nodes - fixed and those using TTR mobility. Path lengths between CNs and MNs is generally optimal, assuming there is an ITR (or PTR) near the CN and the MN is using a TTR reasonably nearby (< 1000 km or so). There is no fixed "home agent", but the system does require a sophisticated global network of TTRs. Most likely multiple companies will run such networks, charge for access and compete for business. Since one TTR, with one RLOC address, can serve thousands of MNs, there is no wastage of RLOC space as would occur with the current LISP-mobile approach. Also, since MNs can be behind NAT, each MN only consumes from the global unicast address pool its own, unique, single IP address EID address. With the current LISP-mobile, each MN needs a global unicast EID address and its own global unicast (RLOC) CoA. > What is probably in scope is to contribute a section to the mapping > analysis/requirements document on what the requirements might be for > various mobility approaches if we decide LISP should support mobility. > Any effort you want to expend towards that would be greatly > appreciated. OK, here goes: For the TTR approach, there are no additional mapping requirements for LISP. Each MN has its own EID, which may be a single IP address for IPv4 or probably a /64 for IPv6. The mapping only needs to change as noted above - when the MN uses another TTR. Exactly how MNs find TTRs, how they securely establish their 2-way encrypted tunnels to the TTR, the commercial arrangements for using TTRs from any one TTR network etc. are all quite separate from the core-edge separation scheme (LISP, APT, Ivip or whatever) itself. The TTR behaves like any ETR. Each TTR network can have its own arrangements for tunneling, managing MNs etc. and so would provide each MN with its own software to implement this. Ideally there would be IETF standards for all this, but this is a separate matter entirely from the core-edge separation scheme. To the core-edge separation schemes data plane, the TTR is simply an ETR and also a source of packets, probably with an ITR integrated in it as well. As long as the MN has a single TTR, the mapping of the MN's EID is no different from that of any single-homed EID - it consists simply of the TTR's address. If the MN has two or more active TTRs, which is possible, then the mapping would be like a multihomed end-user network with two or more ETR addresses in two or more ISPs. Alternatively, the mapping can be just for the newest, closest, TTR and it is fine for some ITRs to be running from their cached version of the old mapping, and so tunneling packets to the old, and now more distant, TTR. In principle, the MN itself could control the mapping of its EID. However, this would be very tricky and I expect the TTR system to work best when the MN uses a commercial TTR network, whose servers would control the mapping of the MN's EID and coordinate the way the MN tunnels to TTRs. That distributed network of servers would be the best place to decide on the mapping of the the MN's EID, since that network is robust and always connected to the Net, which the MN is not. That network can probe reachability of its TTRs and it will know which of potentially several TTRs has the best connectivity to the MN. Also, the MN has restricted, unreliable and possibly expensive connectivity, so it would be best if the TTR company's network of servers managed the MN and the mapping of its EID. The TTR company's network of servers can interface to the LISP-ALT network just like any other LISP-using end-user network - in whichever way makes most sense for LISP. Typically a MN would choose a single TTR company to manage its EID. The most likely arrangement would be for that company to have a slab of address space which it splits into individually mappable EIDs, one for each of its MN customers. So a single TTR network company might control the mapping for millions or hundreds of millions of small EIDs. From the point of view of LISP's mapping system, this would be exactly like a non-mobile end-user network with a large EID address space which has chosen to split that address space into many independently mapped EIDs. Because mapping changes will only typically occur when the MN connects to the Net somewhere very distant (such as > 1000km) from its current TTR, mapping changes will not be particularly frequent. If the mapping change takes some time to propagate to all ITRs, such as by simple cache expiry, this is fine, since the MN can still have tunnels to its old, and now distant, TTR, while it has tunnels to a new, closer TTR. Unlike the LISP-mobile approach, there is no need for mapping changes every time the MN gets a new CoA. Nor is there any need for the MN to directly update the mapping cache of ITRs which are tunneling packets to an initial, and now distant, TTR. The current LISP-mobile I-D involves some mapping system requirements, such as the ability of the MN to rapidly update the mapping of ITRs which are tunneling packets addressed to its EID. I can't advise on this and I believe this approach to mobility - making the MN be its own ETR - will not work. - Robin From dino@cisco.com Wed Sep 2 12: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 53DE13A708F for ; Wed, 2 Sep 2009 12:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 Lpf-CSospPwV for ; Wed, 2 Sep 2009 12:10:19 -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 B06FF3A6971 for ; Wed, 2 Sep 2009 12:10:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALdfnkqrR7PE/2dsb2JhbADDWohBAZBiBYQb X-IronPort-AV: E=Sophos;i="4.44,319,1249257600"; d="scan'208";a="236501343" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 02 Sep 2009 19:08:13 +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 n82J8Djv020887; Wed, 2 Sep 2009 12:08:13 -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 n82J8Dts001675; Wed, 2 Sep 2009 19:08:13 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, 2 Sep 2009 12:08:13 -0700 Received: from [192.168.1.4] ([10.21.70.172]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 12:08:12 -0700 Message-Id: <137C5442-2AFB-4455-AAEC-827FF287458B@cisco.com> From: Dino Farinacci To: Luigi Iannone 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, 2 Sep 2009 12:08:12 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Sep 2009 19:08:13.0137 (UTC) FILETIME=[B7F4B410:01CA2C00] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3999; t=1251918493; x=1252782493; 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#16=3A=20map=20versioning=20re solution |Sender:=20; bh=TJJMNfBHilMnJyHrpBNXUW4jGjRUuMjQKc5LdMAQaKM=; b=SS0wVuQQM4jXuBbJsd884v6GUsbMH/qG1eV3C/sHSDRCrEygo7VDGX8og7 mVSeGEfb5SThqg9K8jb1Kvky9F08tIGj/AJwt2L06fkdGbof2np5EN5bCnMX bMYcqoBfOD; 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] #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: Wed, 02 Sep 2009 19:10:22 -0000 Based on this response, I propose no changes to the spec. Any objections? Dino On Sep 2, 2009, at 3:57 AM, Luigi Iannone wrote: > > On Aug 27, 2009, at 16:56 , Sam Hartman wrote: > >> >> >> 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? > > Yes > >> If so, why? > > Interoperability. > > Let me try to explain the idea about the R-bit (and hopefully > addressing Joel's concerns). > > The basic idea is to have a bit that allows to overload two fields > of the LISP header: Nonce and Loc-bits. > > In this way, when R = 1 we can put version numbers in the overloaded > fields. > > Concerning draft-iannone-lisp-versioning-00, will update it > in order to respect bit's position of the new header and to be > coherent with draft-ietf-lisp-04. > > Having said that, we have also to keep in mind interoperability with > boxes that do not support the R-bit. > Those boxes will ignore the R bit, thus making mandatory that when > R=1 then N and L must be 0 allows to safely make the ETR ignore the > overloaded fields. > Doing otherwise would lead to totally incompatible headers and > implementations. We really do not need that. > > About Joel's concern on the case R=1 and L and N any combination > that is not 00: > > For boxes that do not understand R bit: > These boxes will ignore the R-bit and behave normally with the other > two bits (and consecutive actions). > > I do not see any harm here. What if the R bit is set due to an error > on the wire? This can always happen, even with other reserved flags. > On the other hand, I do not think that this introduces any > additional security issue. (spoofing is always possible whatever > header we define) > > > For boxes that understand the R-bit: > Let me start by saying that this issue should not be tackled IMHO in > draft-ietf-lisp-04. I think it belongs to documents that define the > meaning of the overloaded fields (draft-iannone-lisp-versioning). > > Now, since it is not possible to know the real meaning of the fields > I would suggest to silently drop the packet, because: > > - If it is the result of an error on the wire, this is so rare that > dropping a packet once in a while causes no harm. > > - If it is someone sending ill formed packets, thus playing with the > rules, we do not need to consider it. > > > At the end, I do not think that we need any error message, as > suggested by Joel. > > About the issue of just making it a reserved bit, I do not see why > we should do that. > I do not remember by heart the wording in draft-ietf-lisp-04 > (apologies I am on holiday and would like to spend my last days in a > different way rather then going again over the document) but as far > as I remember it was clear (to me at least). > The document clearly state that the R bit is used for research > purposes and how to deal with the N and L bits. > It is not in the scope of that document to describe in details the > content of the overloaded fields, but just to assure that there is > interoperability. > In this way, different "flavours" of lisp can still talk to each > other. Making the bit reserved could open the door to problems (as > Noel suggested in one of his mails) that later on packet with the R > bit set will be just dropped. > > Hope this clarifies things. > > Luigi > > > >> >> Comments from others on this issue would also be very useful. >> _______________________________________________ >> 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 Wed Sep 2 12:22: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 82AB028C113 for ; Wed, 2 Sep 2009 12:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 j0s+cV-bYCgV for ; Wed, 2 Sep 2009 12:22:44 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2296C28C8CC for ; Wed, 2 Sep 2009 12:22:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C49F043075B; Wed, 2 Sep 2009 12:23:00 -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 A747B430746; Wed, 2 Sep 2009 12:22:59 -0700 (PDT) Message-ID: <4A9EC611.2070300@joelhalpern.com> Date: Wed, 02 Sep 2009 15:22:57 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <137C5442-2AFB-4455-AAEC-827FF287458B@cisco.com> In-Reply-To: <137C5442-2AFB-4455-AAEC-827FF287458B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [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: Wed, 02 Sep 2009 19:22:45 -0000 I do not see why, based on this note, this document should mandate anything about the relationship of the N and L bits to the R bit. Everything works if we say nothing about that relationship. (Sorry, I guess I do not understand eithe ryours or Luigi's reasoning for defining a relationship between defined bits and undefined bits.) Just treat the R bit the way we do all reserved bits. (Until redefined by some other document, the bit MUST be set to zero on transmission, and the value in that bit position MUST be ignored upon reception.) Then, wherever we define the R bit, we can describe what is bits may be set along with the R bit. And we can specify what error checks and error behaviors a node which understands the R bit will apply. To do otherwise is to fold into this document decisions about the usage of the R bit that belong in some other document. In a way that can not be reviewed, since there is no meaning. Please explain what harm is done by following the usual IETF protocol definition practice in this case. (I have already attempted to explain what harm I believe is done by not doing so, and why I do not see any harm in doing so.) Yours, Joel Dino Farinacci wrote: > Based on this response, I propose no changes to the spec. Any objections? > > Dino > > On Sep 2, 2009, at 3:57 AM, Luigi Iannone wrote: > >> >> On Aug 27, 2009, at 16:56 , Sam Hartman wrote: >> >>> >>> >>> 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? >> >> Yes >> >>> If so, why? >> >> Interoperability. >> >> Let me try to explain the idea about the R-bit (and hopefully >> addressing Joel's concerns). >> >> The basic idea is to have a bit that allows to overload two fields of >> the LISP header: Nonce and Loc-bits. >> >> In this way, when R = 1 we can put version numbers in the overloaded >> fields. >> >> Concerning draft-iannone-lisp-versioning-00, will update it >> in order to respect bit's position of the new header and to be >> coherent with draft-ietf-lisp-04. >> >> Having said that, we have also to keep in mind interoperability with >> boxes that do not support the R-bit. >> Those boxes will ignore the R bit, thus making mandatory that when R=1 >> then N and L must be 0 allows to safely make the ETR ignore the >> overloaded fields. >> Doing otherwise would lead to totally incompatible headers and >> implementations. We really do not need that. >> >> About Joel's concern on the case R=1 and L and N any combination that >> is not 00: >> >> For boxes that do not understand R bit: >> These boxes will ignore the R-bit and behave normally with the other >> two bits (and consecutive actions). >> >> I do not see any harm here. What if the R bit is set due to an error >> on the wire? This can always happen, even with other reserved flags. >> On the other hand, I do not think that this introduces any additional >> security issue. (spoofing is always possible whatever header we define) >> >> >> For boxes that understand the R-bit: >> Let me start by saying that this issue should not be tackled IMHO in >> draft-ietf-lisp-04. I think it belongs to documents that define the >> meaning of the overloaded fields (draft-iannone-lisp-versioning). >> >> Now, since it is not possible to know the real meaning of the fields I >> would suggest to silently drop the packet, because: >> >> - If it is the result of an error on the wire, this is so rare that >> dropping a packet once in a while causes no harm. >> >> - If it is someone sending ill formed packets, thus playing with the >> rules, we do not need to consider it. >> >> >> At the end, I do not think that we need any error message, as >> suggested by Joel. >> >> About the issue of just making it a reserved bit, I do not see why we >> should do that. >> I do not remember by heart the wording in draft-ietf-lisp-04 >> (apologies I am on holiday and would like to spend my last days in a >> different way rather then going again over the document) but as far as >> I remember it was clear (to me at least). >> The document clearly state that the R bit is used for research >> purposes and how to deal with the N and L bits. >> It is not in the scope of that document to describe in details the >> content of the overloaded fields, but just to assure that there is >> interoperability. >> In this way, different "flavours" of lisp can still talk to each >> other. Making the bit reserved could open the door to problems (as >> Noel suggested in one of his mails) that later on packet with the R >> bit set will be just dropped. >> >> Hope this clarifies things. >> >> Luigi >> >> >> >>> >>> Comments from others on this issue would also be very useful. >>> _______________________________________________ >>> 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 hartmans@mit.edu Wed Sep 2 12:34: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 B540828C926 for ; Wed, 2 Sep 2009 12:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 2vtHNuH+c8rx for ; Wed, 2 Sep 2009 12:34: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 E6A7D28C159 for ; Wed, 2 Sep 2009 12:34:40 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CF51451C5; Wed, 2 Sep 2009 15:33:26 -0400 (EDT) To: Luigi Iannone References: From: Sam Hartman Date: Wed, 02 Sep 2009 15:33:26 -0400 In-Reply-To: (Luigi Iannone's message of "Wed\, 2 Sep 2009 12\:57\:05 +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] #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: Wed, 02 Sep 2009 19:34:43 -0000 >>>>> "Luigi" == Luigi Iannone writes: >> If so, why? Luigi> Interoperability. Luigi> Let me try to explain the idea about the R-bit (and Luigi> hopefully addressing Joel's concerns). Luigi> The basic idea is to have a bit that allows to overload two Luigi> fields of the LISP header: Nonce and Loc-bits. Luigi> In this way, when R = 1 we can put version numbers in the Luigi> overloaded fields. Luigi> Concerning draft-iannone-lisp-versioning-00, will update it Luigi> in order to respect bit's position of the new header and to Luigi> be coherent with draft-ietf-lisp-04. Luigi> Having said that, we have also to keep in mind Luigi> interoperability with boxes that do not support the R-bit. Luigi> Those boxes will ignore the R bit, thus making mandatory Luigi> that when R=1 then N and L must be 0 allows to safely make Luigi> the ETR ignore the overloaded fields. Doing otherwise Luigi> would lead to totally incompatible headers and Luigi> implementations. We really do not need that. OK. So, what you're saying is that we want to have two mechanisms for handling map data. One works through the control plane and will be specified in draft-ietf-lisp-lisp. Everyone has to implement that. The other one is specified in your draft; it's turned on by setting the r bit. We could potentially do something like that, although I don't think the text in Dino's proposed changes for 04 actually accomplishes that. However before we start discussing specific text I'd like to understand why we want to do that. Originally I thought you wanted everyone to implement map versioning. The impression I get from the Stockholm minutes is that one of Dino or Darrel (unclear who) was going to propose some hybrid mechanism. Now, we're ending up with two mechanisms, one specified in a WG document, one specified in a non-WG document. One of them is optional. I'm missing the chunk of reasoning where you decided that your mechanism should be optional and was something only some boxes would implement. From dino@cisco.com Wed Sep 2 12:43: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 E0D5528C1EF for ; Wed, 2 Sep 2009 12:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 qSniJQ2ZI5ax for ; Wed, 2 Sep 2009 12:43: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 B69B628C1E2 for ; Wed, 2 Sep 2009 12:43:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKNnnkqrR7MV/2dsb2JhbADDWIhBAZBjBYQb X-IronPort-AV: E=Sophos;i="4.44,320,1249257600"; d="scan'208";a="236518139" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 02 Sep 2009 19:41:23 +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 n82JfNwk024925; Wed, 2 Sep 2009 12:41:23 -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 n82JfNNB028644; Wed, 2 Sep 2009 19:41:23 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, 2 Sep 2009 12:41:23 -0700 Received: from [192.168.1.4] ([10.21.70.172]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 12:41:23 -0700 Message-Id: <33479B07-61C8-452C-A9DB-1B504D1433E0@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A9EC611.2070300@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, 2 Sep 2009 12:41:21 -0700 References: <137C5442-2AFB-4455-AAEC-827FF287458B@cisco.com> <4A9EC611.2070300@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Sep 2009 19:41:23.0147 (UTC) FILETIME=[5A1821B0:01CA2C05] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1088; t=1251920483; x=1252784483; 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#16=3A=20map=20versioning=20re solution |Sender:=20; bh=/NXDUz1m+87kbGudnUm9kvUCa+y7kY3CVlm3AncGhmc=; b=dSnlnJ6Lplo9Tz3tvfZLMU4kV17N9tk1jqgd2A4iAqJxzuX7w9iI+gSczw ncEWw2snHOkgENQPow1+tPGWaMYX2mdOD4/GhozDd8dPV39Msx0HIHInw01q M/1Vqxq1pNVyqBcWdtiHHSC4xTIUzBTLwNf9/3PTpG4p+aVTF2/rw=; 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] #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: Wed, 02 Sep 2009 19:43:35 -0000 > I do not see why, based on this note, this document should mandate > anything about the relationship of the N and L bits to the R bit. > Everything works if we say nothing about that relationship. Okay, so how about this text: R: this is the Research bit. This bit is reserved and it's usage is not documented in this specification. L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See section Section 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. No other reference to relationships of R, L, and N bit. Converged? Dino From dino@cisco.com Wed Sep 2 13:07: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 887753A7023 for ; Wed, 2 Sep 2009 13:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 nJUF8JvTvrMA for ; Wed, 2 Sep 2009 13:07:32 -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 751F53A6C2C for ; Wed, 2 Sep 2009 13:06:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAdtnkqrR7O6/2dsb2JhbADDW4hBAZBeBYQbimI X-IronPort-AV: E=Sophos;i="4.44,320,1249257600"; d="scan'208";a="380685128" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Sep 2009 20:04:52 +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 n82K4qKH019249; Wed, 2 Sep 2009 13:04:52 -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 n82K4qhF024572; Wed, 2 Sep 2009 20:04:52 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, 2 Sep 2009 13:04:51 -0700 Received: from [192.168.1.4] ([10.21.70.172]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 13:04:51 -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: Wed, 2 Sep 2009 13:04:51 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Sep 2009 20:04:51.0743 (UTC) FILETIME=[A1AED2F0:01CA2C08] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2928; t=1251921892; x=1252785892; 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]=20#16=3A=20map=20versioning=20re solution |Sender:=20; bh=+/8oO/AglsQgMeZDIV/Ze7pGm9VIPNnmmnb9ic4OVHA=; b=odztWyvCb/xiz3MCPZexAhzpzRr+8cvHmXjlHBkBQvMFIh13h5TGG1B2ZW w2jLevNXqwFXT6tuvmAqPApBuf7FPiq9WRPHYLknW6hu+C4eehMOqL3Y9+OC CBXZZHgxX5; 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] #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: Wed, 02 Sep 2009 20:07:33 -0000 >>>>>> "Luigi" == Luigi Iannone writes: > > >>> If so, why? > > Luigi> Interoperability. > > Luigi> Let me try to explain the idea about the R-bit (and > Luigi> hopefully addressing Joel's concerns). > > Luigi> The basic idea is to have a bit that allows to overload two > Luigi> fields of the LISP header: Nonce and Loc-bits. > > Luigi> In this way, when R = 1 we can put version numbers in the > Luigi> overloaded fields. > > Luigi> Concerning draft-iannone-lisp-versioning-00, will update it > Luigi> in order to respect bit's position of the new header and to > Luigi> be coherent with draft-ietf-lisp-04. > > Luigi> Having said that, we have also to keep in mind > Luigi> interoperability with boxes that do not support the R-bit. > Luigi> Those boxes will ignore the R bit, thus making mandatory > Luigi> that when R=1 then N and L must be 0 allows to safely make > Luigi> the ETR ignore the overloaded fields. Doing otherwise > Luigi> would lead to totally incompatible headers and > Luigi> implementations. We really do not need that. > > OK. So, what you're saying is that we want to have two mechanisms for > handling map data. One works through the control plane and will be > specified in draft-ietf-lisp-lisp. > Everyone has to implement that. > > The other one is specified in your draft; it's turned on by setting > the r bit. The one in Luigi's draft is going to be researched. ;-) > We could potentially do something like that, although I don't think > the text in Dino's proposed changes for 04 actually accomplishes that. > However before we start discussing specific text I'd like to > understand why we want to do that. > > Originally I thought you wanted everyone to implement map versioning. > The impression I get from the Stockholm minutes is that one of Dino or > Darrel (unclear who) was going to propose some hybrid mechanism. And the mechanisms are: (1) SMR-based Map-Requesting (the control plane you refer to above). (2) RLOC-probing (when in use you get map-updates at the frequency of the poll interval, also control plane). (3) Use short TTLs. And the ETR doesn't have to keep multiple locator-sets and required to do versioning. It always sends Map-Replies for the latest it has. > Now, we're ending up with two mechanisms, one specified in a WG > document, one specified in a non-WG document. One of them is > optional. This is the sort of thing where part of LISP is doing engineering and other ideas are still in research. Dino > I'm missing the chunk of reasoning where you decided that your > mechanism should be optional and was something only some boxes would > implement. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Wed Sep 2 14:30: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 05D2128C9E4 for ; Wed, 2 Sep 2009 14:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 3PNu6Bk5-LlE for ; Wed, 2 Sep 2009 14:30:56 -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 BE8563A7167 for ; Wed, 2 Sep 2009 14:29:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPKAnkqrR7PE/2dsb2JhbADDU4hBAZBbBYQb X-IronPort-AV: E=Sophos;i="4.44,320,1249257600"; d="scan'208";a="380743896" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Sep 2009 21:29:28 +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 n82LTSSq026037; Wed, 2 Sep 2009 14:29:28 -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 n82LTSwY001145; Wed, 2 Sep 2009 21:29:28 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, 2 Sep 2009 14:29:28 -0700 Received: from [192.168.5.47] ([10.21.127.5]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 14:29:27 -0700 Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A9EDAE0.1080202@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, 2 Sep 2009 14:29:25 -0700 References: <137C5442-2AFB-4455-AAEC-827FF287458B@cisco.com> <4A9EC611.2070300@joelhalpern.com> <33479B07-61C8-452C-A9DB-1B504D1433E0@cisco.com> <4A9EDAE0.1080202@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Sep 2009 21:29:27.0993 (UTC) FILETIME=[735D1A90:01CA2C14] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1521; t=1251926968; x=1252790968; 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#16=3A=20map=20versioning=20re solution |Sender:=20; bh=fSudx829ig8rxiQjFXFiT8qq3fNKJGtAR81oSGY/mbY=; b=V0hGsMQrqjdSxjO7trnDbn2y0hApmdIB05Zz4DgfkS9GAQ7bJXRN2MqPKj 69tmz5evw0JuzXGCFvJpVd/AtxmYFdteFpZqsaZf6GfYa76EmATE28J5aDsN wUpfq4YxuY; 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] #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: Wed, 02 Sep 2009 21:30:57 -0000 I am sorry, it was a typo. I didn't remove it. I will remove the sentence that references the R-bit. Dino On Sep 2, 2009, at 1:51 PM, Joel M. Halpern wrote: > Still (slightly) confused. Why reference the R bit in the E bit > description? The other two look great. I understand why the E and > N interaction is specified, and appreciate it. > Joel > > Dino Farinacci wrote: >>> I do not see why, based on this note, this document should mandate >>> anything about the relationship of the N and L bits to the R bit. >>> Everything works if we say nothing about that relationship. >> Okay, so how about this text: >> R: this is the Research bit. This bit is reserved and it's usage >> is >> not documented in this specification. >> L: this is the Locator-Status-Bits field enabled bit. When this >> bit >> is set to 1, the Locator-Status-Bits in the second 32-bits of >> the >> LISP header are in use. >> N: this is the nonce-present bit. When this bit is set to 1, the >> low-order 24-bits of the first 32-bits of the LISP header >> contains >> a Nonce. See section Section 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. >> No other reference to relationships of R, L, and N bit. >> Converged? >> Dino From hartmans@mit.edu Wed Sep 2 14:44: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 D84533A7135 for ; Wed, 2 Sep 2009 14:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 Em7Xj-gxzsfj for ; Wed, 2 Sep 2009 14:44: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 2B4233A7156 for ; Wed, 2 Sep 2009 14:44:45 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3C49951C5; Wed, 2 Sep 2009 16:27:33 -0400 (EDT) To: Dino Farinacci References: From: Sam Hartman Date: Wed, 02 Sep 2009 16:27:33 -0400 In-Reply-To: (Dino Farinacci's message of "Wed\, 2 Sep 2009 13\:04\:51 -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] #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: Wed, 02 Sep 2009 21:44:45 -0000 >>>>> "Dino" == Dino Farinacci writes: >> Now, we're ending up with two mechanisms, one specified in a WG >> document, one specified in a non-WG document. One of them is >> optional. Dino> This is the sort of thing where part of LISP is doing Dino> engineering and other ideas are still in research. Right. However, as far as I can tell, the WG hasn't come to the conclusion that map versioning needs additional research. When it was presented to us, it was presented at least as far as I could tell as an idea we should integrate into our specs. I'm not following the reasoning or discussion that lead from where I think we were in Stockholm to a conclusion that map versioning needs research but the other mechanisms do not. If Luigi has been convinced of that, it will certainly go a long way to convincing me as an individual, but I'm suspecting we won't get there as a WG without someone actually explaining the reasoning on the list and others agreeing with it on the list. From dino@cisco.com Wed Sep 2 14:47: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 E89133A7156 for ; Wed, 2 Sep 2009 14:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 3h9JvECABj-z for ; Wed, 2 Sep 2009 14:47:30 -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 8B76C3A7161 for ; Wed, 2 Sep 2009 14:46:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHeEnkqrR7O6/2dsb2JhbADDU4hBAZBcBYQbimI X-IronPort-AV: E=Sophos;i="4.44,320,1249257600"; d="scan'208";a="380753295" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Sep 2009 21:45:44 +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 n82Ljiqv001168; Wed, 2 Sep 2009 14:45:44 -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 n82Ljiv0017976; Wed, 2 Sep 2009 21:45:44 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, 2 Sep 2009 14:45:44 -0700 Received: from [192.168.5.47] ([10.21.127.5]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 14:45:43 -0700 Message-Id: <4E34A33A-B098-45B5-9B7A-8A1645C3E3A4@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, 2 Sep 2009 14:45:43 -0700 References: <137C5442-2AFB-4455-AAEC-827FF287458B@cisco.com> <4A9EC611.2070300@joelhalpern.com> <33479B07-61C8-452C-A9DB-1B504D1433E0@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Sep 2009 21:45:43.0840 (UTC) FILETIME=[B9038A00:01CA2C16] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2038; t=1251927944; x=1252791944; 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]=20#16=3A=20map=20versioning=20re solution |Sender:=20; bh=fmRKcZP8BCFeBxxUOHG2ZA8HcUKI3ehk/eku7AYfyVE=; b=MXgAOUWbbAKmo4wrvtKPvSrRuEWYXnhtZrjsRTiQNXuFZP4aZydLcOTKE0 EqinJrubLpWsdDJte8p9DW+X3fVjDjhTziYm2OZtKp0GhBU0Ls9qad+eMEx8 IGPQM1SW5H; 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] #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: Wed, 02 Sep 2009 21:47:32 -0000 > Dino> Okay, so how about this text: > > Dino> R: this is the Research bit. This bit is reserved and > Dino> it's usage is not documented in this specification. > > Doesn't work because it fails to specify what you do if you get a > packet with this bit set. > > How about: The X bit provides an experimental [RFC 3692] flag for the > LISP header. If a ETR receives a packet with this bit set and has not > been explicitly configured to participate in an experiment, then [pick > from group a]. As described in [RFC 3692], this bit can only be set > when an implementation is configured to participate in an experiment. > > Group A: > > * drop the packet > * decapsulate and process the inner packet but ignore the LISP header > > I don't actually support this option, preferring that if we're going > to have a version field it be at least two bits wide. Howevver I > think it would be reasonable for the WG to decide on a one-bit version > field and if the WG did so, I think the above text is consistent with > how such things are handled in the rest of the IETF. How about this text: R: this is the Research bit. This bit is reserved and its usage is not documented in this specification. If an implementation does not participate in the research experiment, the bit can be ignored by an ETR and accepted for packet decapsulation. Folks, this doesn't have to be perfect at this point. We can rev future drafts. We need to capture the changes in a posted document. I am not trying to rush things, but I want to be practical too. This is an experimental protocol. We don't need to cross Is and dot Ts at this point. We need to get the specification written so we can implement and learn from our experiments. And we need interoperable implementations, so we need to get this out. Please don't take this the wrong way. Many seem to not like my email language so I am actually trying to be delicate here. Thanks in advance, Dino From hartmans@mit.edu Wed Sep 2 14:49: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 D106E3A7158 for ; Wed, 2 Sep 2009 14:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 QRZMutNRXb1v for ; Wed, 2 Sep 2009 14:49: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 60F573A7135 for ; Wed, 2 Sep 2009 14:49:43 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C49DD51C8; Wed, 2 Sep 2009 16:53:09 -0400 (EDT) To: Dino Farinacci References: <137C5442-2AFB-4455-AAEC-827FF287458B@cisco.com> <4A9EC611.2070300@joelhalpern.com> <33479B07-61C8-452C-A9DB-1B504D1433E0@cisco.com> From: Sam Hartman Date: Wed, 02 Sep 2009 16:53:09 -0400 In-Reply-To: <33479B07-61C8-452C-A9DB-1B504D1433E0@cisco.com> (Dino Farinacci's message of "Wed\, 2 Sep 2009 12\:41\: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] #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: Wed, 02 Sep 2009 21:49:45 -0000 >>>>> "Dino" == Dino Farinacci writes: >> I do not see why, based on this note, this document should >> mandate anything about the relationship of the N and L bits to >> the R bit. Everything works if we say nothing about that >> relationship. Dino> Okay, so how about this text: Dino> R: this is the Research bit. This bit is reserved and Dino> it's usage is not documented in this specification. Doesn't work because it fails to specify what you do if you get a packet with this bit set. How about: The X bit provides an experimental [RFC 3692] flag for the LISP header. If a ETR receives a packet with this bit set and has not been explicitly configured to participate in an experiment, then [pick from group a]. As described in [RFC 3692], this bit can only be set when an implementation is configured to participate in an experiment. Group A: * drop the packet * decapsulate and process the inner packet but ignore the LISP header I don't actually support this option, preferring that if we're going to have a version field it be at least two bits wide. Howevver I think it would be reasonable for the WG to decide on a one-bit version field and if the WG did so, I think the above text is consistent with how such things are handled in the rest of the IETF. From jmh@joelhalpern.com Wed Sep 2 15: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 CB45328C9CF for ; Wed, 2 Sep 2009 15:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=-0.505, 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 iSCCsTmJED9R for ; Wed, 2 Sep 2009 15:13:45 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by core3.amsl.com (Postfix) with ESMTP id 2680D28C9CE for ; Wed, 2 Sep 2009 15:13:45 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by morbo.tigertech.net (Postfix) with ESMTP id 789F1A38CC for ; Wed, 2 Sep 2009 13:52:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 582A24307A8; Wed, 2 Sep 2009 13:51:47 -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 8F5AE43078D; Wed, 2 Sep 2009 13:51:46 -0700 (PDT) Message-ID: <4A9EDAE0.1080202@joelhalpern.com> Date: Wed, 02 Sep 2009 16:51:44 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <137C5442-2AFB-4455-AAEC-827FF287458B@cisco.com> <4A9EC611.2070300@joelhalpern.com> <33479B07-61C8-452C-A9DB-1B504D1433E0@cisco.com> In-Reply-To: <33479B07-61C8-452C-A9DB-1B504D1433E0@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [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: Wed, 02 Sep 2009 22:13:45 -0000 Still (slightly) confused. Why reference the R bit in the E bit description? The other two look great. I understand why the E and N interaction is specified, and appreciate it. Joel Dino Farinacci wrote: >> I do not see why, based on this note, this document should mandate >> anything about the relationship of the N and L bits to the R bit. >> Everything works if we say nothing about that relationship. > > Okay, so how about this text: > > R: this is the Research bit. This bit is reserved and it's usage is > not documented in this specification. > > L: this is the Locator-Status-Bits field enabled bit. When this bit > is set to 1, the Locator-Status-Bits in the second 32-bits of the > LISP header are in use. > > N: this is the nonce-present bit. When this bit is set to 1, the > low-order 24-bits of the first 32-bits of the LISP header contains > a Nonce. See section Section 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. > > No other reference to relationships of R, L, and N bit. > > Converged? > > Dino > > From jnc@mercury.lcs.mit.edu Wed Sep 2 15:54: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 350F93A6AB9 for ; Wed, 2 Sep 2009 15:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 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 ZdISLLWlsmmc for ; Wed, 2 Sep 2009 15:54:54 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 3D59D28C1E4 for ; Wed, 2 Sep 2009 15:54:54 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 834666BE641; Wed, 2 Sep 2009 18:54:25 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090902225425.834666BE641@mercury.lcs.mit.edu> Date: Wed, 2 Sep 2009 18:54:25 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [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: Wed, 02 Sep 2009 22:54:55 -0000 > From: Sam Hartman > I'm not following the reasoning or discussion that lead from where I > think we were in Stockholm to a conclusion that map versioning needs > research but the other mechanisms do not. The problem is that we're operating in something of a vacuum, operational-data-wise. (Apologies in advance to the degree that any of the following is teaching of egg-sucking... And I also apologize in advance if I have mis-understood anything I've heard from various collaborators, so if I get something wrong, 'just shoot me'... :-) We have what everyone feels has the _potential_ to be a problem - i.e. outdated mappings. There are also a bunch of ideas on various different mechanisms to tackle that problem, each of which has plusses and minusses (complexity, operational overhead, etc). In the particular case of mapping-versioning, piggybacking it on user-data-trafffic has some big advantages (e.g. no extra packet traffic), but from an _implementation_ point of view, in one of our main testbeds (Dino's), my understanding is that it has a big downside, which is that getting the data plane to do anything control-oriented is really hard. (I got the impression that doing echo-noncing for reachabilty detection was fairly painful, for instance.) Which of course shouldn't weigh too heavily on a design decision (ask me sometime about the variable length IP addresses in IPv3, and the number of pointer registers available in TENEX at interrupt time - you can guess where that story goes :-( - unless it's a _typical_ kind of problem for high-end router boxes (i.e. piggybacking control operations on user-data traffic), which I get the sense it might be. Still, when you add to that the concept that a versioning-type solution (I personally prefer checksums to versions, but that's an engineering detail) can be incrementally added later, I think that's _part_ of why that one is still 'on the back burner'. The thing is that without more real-world data on i) how big a problem outdated mappings are, ii) how expensive various solutions are, iii) how well those solutions work, etc we're kind of shooting in the dark without a night-scope. This is also a case where I'm not sure simulation would even help much, since it depends a lot on other things which we also don't have a lot of data on, e.g. how often mappings will be changed. Yeah, people have an 'engineering sense' for a lot of this, but intuition is not a 100.000% substitute for actual experience. And when you add in the fact that it's something we can add later without too much pain, I think that's the thinking behind a position of 'let's add these mechanisms, and study that other one some more'. Noel From jnc@mercury.lcs.mit.edu Wed Sep 2 16: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 5AC4D28C328 for ; Wed, 2 Sep 2009 16:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 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 e0ZkmOGGaPQb for ; Wed, 2 Sep 2009 16:02:29 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id C0E3428C2A3 for ; Wed, 2 Sep 2009 16:01:48 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 755CB6BE63F; Wed, 2 Sep 2009 18:31:24 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090902223124.755CB6BE63F@mercury.lcs.mit.edu> Date: Wed, 2 Sep 2009 18:31:24 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [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: Wed, 02 Sep 2009 23:02:30 -0000 > From: Sam Hartman > If a ETR receives a packet with this bit set and has not > been explicitly configured to participate in an experiment, then > [pick from group a]. > ... > Group A: > * drop the packet > * decapsulate and process the inner packet but ignore the LISP header I thought we had converged on another choice: * process the packet normally, ignoring the R-bit Part of the rationale for this behaviour is that this allows easy incremental deployment of a new mechanism (possibly mapping-versioning [which I personally find to be a more apropos term than 'map versioning', but I digress]), since 'new' packets will be processed appropriately by 'old' devices. Also, use of the two header fields (24-bit and 32-bit) is controlled by 'positive' flag-bit semantics, i.e. the fields do not hold anything _unless_ the appropriate flag-bit it set. (I.e. unless L is set, the 32-bit field is free, and similarly for N and the 24-bit field.) So, an experiment with the R bit can use either of those fields for an 'experimental' use, provided that appropriate flag-bit for that field is clear. > if we're going to have a version field it be at least two bits wide. It's not a version field, as I think of them: see my previous message to Margaret: http://www.ietf.org/mail-archive/web/lisp/current/msg01161.html on this topic. > Howevver I think it would be reasonable for the WG to decide on a > one-bit version field As in that message, the thinking is that since header bits are such a scarce resource, we'd rather not devote them a priori to a 'version' field, and preserve maximum flexibility for the future. It's also worth pointing out that a packet with 'E' set and 'N' clear is currently illegal, and that pattern could serve as an escape to a new header format. (As an interesting historical aside, there is a _long_ history of this sort of thing in networking - the first ARPANet header was 32 bits, and it was replaced by a 96-bit header, use of which was flagged by an 'illegal' value of xF in a 4-bit field in the original 32-bit header!) Noel From dino@cisco.com Wed Sep 2 16:56: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 2B7D028C10C for ; Wed, 2 Sep 2009 16:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBr3b8OCIs5X for ; Wed, 2 Sep 2009 16:56:57 -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 C07843A63EC for ; Wed, 2 Sep 2009 16:56:41 -0700 (PDT) X-Files: rfcdiff-lisp-03-to-04.html, draft-ietf-lisp-04.txt : 163811, 149625 X-IronPort-AV: E=Sophos;i="4.44,321,1249257600"; d="txt'?html'217?scan'217,208,217";a="187289194" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2009 23:52:30 +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 n82NqTF8024638 for ; Wed, 2 Sep 2009 16:52:29 -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 n82NqTkB016642 for ; Wed, 2 Sep 2009 23:52:29 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); Wed, 2 Sep 2009 16:52:29 -0700 Received: from [192.168.5.47] ([10.21.127.5]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 16:52:27 -0700 Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-7-897923867 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 2 Sep 2009 16:52:27 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Sep 2009 23:52:27.0546 (UTC) FILETIME=[6D2CFFA0:01CA2C28] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=321701; t=1251935550; x=1252799550; 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:=20Revised=20proposed=20diffs=20for=20the=20-04=20 LISP=20draft |Sender:=20; bh=4+ak3C5yjGq9JOKhlQI6vI/3YV4Z1ZWg3LAylE+kyn0=; b=Vhfious6dvPWRyvEjXKXoZUxpGI/1aX0qAt2SQGb01UzmGT4QhdoiT/oYi ENtWR5clN5APEaFBzEI3YxjutlXO84qSLY7AxknDTHAAzcNtBk8vBNfI+35x cbQAAhJwcf; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [lisp] Revised proposed diffs for the -04 LISP draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 02 Sep 2009 23:56:58 -0000 --Apple-Mail-7-897923867 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks to everyone who sent me comments in the last 3 days. And thanks for the discussion on the list. I have updated the diffs, see enclosed. I tried to read and understand everyone's concerns, so hopefully they are captured in the changes at the same time as keeping the text simple and accurate. I have enclosed the draft as well. This draft has *not* been submitted and won't be until after the Friday deadline if there are no objections. We will have plenty of opportunities to make other changes but we want to latch on the packet format changes so we can start on interoperability testing. Thanks again, Dino/Dave/Darrel/Vince P.S. Note the title of the spec says "(PROPOSED)" and "(NOT SUBMITTED)". --Apple-Mail-7-897923867 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 6, 2010                                          D. Lewis
                                                           cisco Systems
                                                           July 27,
                                                       September 2, 2009

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

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 6, 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 22
       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 35
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 36
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 38 39
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 40
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 39 41
     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 43
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 43 45
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 44 46
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 45 47
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 45 47
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 46 48
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 47 49
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 50
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 50
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 48 50
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 50 52
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 50 52
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 52
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 52
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 52 54
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 52 54
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 54 56
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 55 57
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 56 58
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 61
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 59 61
     14.2. Informative References . . . . . . . . . . . . . . . . . . 60 62
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 63 65
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 66

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 statically 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 prepends 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
      statically 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 prepends 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

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

   OH

   Outer 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 the ETR. packet for decapsulation.
      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 decapsulation, otherwise, it is silently dropped.
      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: the Research bit.  This bit is reserved and its usage is
      not documented in this specification.  If an implementation does
      not participate in the LISP header are set research experiment, the bit can be ignored
      by an ITR to
      indicate to an ETR and accepted for packet decapsulation.

   L: this is the reachability Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the Locators
      LISP header are in use.

   N: this is the nonce-present bit.  When this bit is set to 1, the
      low-order 24-bits of the first 32-bits of the LISP header contains
      a Nonce.  See section Section 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.  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.

   rflags:  this 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
      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.  When the E-bit is clear but the N-bit
      is set, an ITR is either echoing a previously requested echo-nonce
      or providing a random nonce.  See section Section 6.3.1 for more
      details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator
      Reach Status Bits are numbered from 0 to n-1 from the right least
      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 is
      reachable. 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 Reach Status Bits
      setting in an encapsulated packet MUST reflect the mapping for the
      EID-prefix that the inner-header source EID address matches.

   S: this is the Solicit-Map-Request (SMR) bit.  See section
      Section 6.5.2 for details.

   E: this is the echo-nonce-request bit.  See section Section 6.3.1 for
      details.

   rsvd-flags:  this 6-bit

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The outer header Time to Live 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.
      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 is set to solicit the other side to send a Map-
      Request containing this nonce.  See section Section 6.5.2 for
      details.

   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 (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

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

   When doing Re-encapsulated Tunneling:

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

   o  The new OH outer header Type of Service field SHOULD be copied from
      the stripped OH header Type of Service field (with one caveat, see
      below)..
      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 that is labeled
      'Rec' above and occurs the number of times equal to Record count.
      For this version of the protocol specification, a receiver MUST
      accept and process a record count of one or greater but a sender
      MUST always set the record count to one.  Support for requesting
      multiple EIDs in a single Map-Request message will be specified in
      a future version of the protocol.

   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

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request, it may
   originate a "verifying Map-Request", addressed to the original ITR.
   If the ETR has a map-cache entry that matches the "piggybacked" EID
   and the RLOC is in the locator-set for the entry, then it may send
   the "verifying Map-Request" to the original Map-Request source.  If
   not, then it MUST send it to the "piggybacked" EID.  Doing this
   forces the "verifying Map-Request" to go through the mapping database
   system to reach the authoritative source of information about that
   EID, guarding against RLOC-spoofing in in the "piggybacked" 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|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.

   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.

   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: this bit is reserved for use by the LISP mobile-node design
      documented in [LISP-MN].

   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.

   o  A "gleaned" map-cache entry, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply and or that stored in the database
   mapping service does not database system provide any reachability status information for Locators.  This is done outside RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the mapping service.  See Routing Locator Reachability Algorithms described in the
   next section for details. section.

6.3.  Routing Locator Reachability

   There are 4 methods

   Several mechanisms for determining when a Locator is either
   reachable or has become unreachable:

   1.  Locator RLOC reachability is determined by an are currently
   defined:

   1.  An ETR by examining may examine the Loc-Status-Bits in the
       Loc-Reach-Bits from a LISP header of a an
       encapsulated data packet
       which is provided by received from an ITR when ITR.  If the ETR is
       also acting as an ITR encapsulates data.

   2.  Locator unreachability is determined by and has traffic to return to the original
       ITR site, it can use this status information to help select an
       RLOC.

   2.  An ITR by receiving may receive an ICMP Network or ICMP Host Unreachable messages.
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  Locator unreachability  An ITR which participates in the global routing system can also be determined by
       determine that an BGP-enabled
       ITR when there RLOC is down if no prefix matching a Locator address from the BGP RIB. RIB route exists that
       matches the RLOC IP address.

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

   5.  Locator reachability is determined by receiving  An ITR may receive a Map-Reply
       message from a ETR's Locator address ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  Locator reachability can also be determined by receiving packets  When an ETR receives an encapsulated by packet from an ITR, the ITR assigned to
       source RLOC from the locator address. outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   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 an encapsulating ITR closest to the Locators about
   reachability for all ETRs at the source site.  The  CE-based ITRs at the source
   site can determine reachability when running their
   IGP at the site.  When relative to each other using the ITRs are deployed on CE routers, typically site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route is injected into the site's IGP from each of the
   ITRs. site IGP.

   o  If an ITR goes down, the CE-PE link goes down, fails or if the upstream link to its PE
   router goes down, the CE router withdraws the fails, its
      default route.  This
   allows route will either time-out or be withdrawn.

   Each ITR can thus observe the other ITRs at presence or lack of a default route
   originated by the site others to determine one of the Locators
   has gone unreachable.

   The Locators Locator Status Bits it sets
   for them.

   RLOCs 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 encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit numbered as 0.  So,
   for bit.  For example, if the ITR with locator an RLOC
   listed as in the 3rd Locator position in of the Map-Reply goes down, down (ordinal value
   2), then all other ITRs at the site will
   have clear the 3rd least significant
   bit from (xxxx x0xx) of the right cleared (the bit that corresponds to
   ordinal 2). Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will look check for a any change in
   the
   Loc-Reach-Bits value. Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to the Locator an RLOC that has just gone
   unreachable. is indicated as
   down.  It can start will only resume using the Locator again when the bit that
   corresponds to RLOC if the Locator goes from 0 corresponding Loc-
   Status-Bit returns to a value of 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 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 ITR 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 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.

   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 more secure to reach an authoritative ETR,
   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 have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   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,  Two are the Echo-Noncing and
        RLOC-Probing algorithms which is are documented in this
        specification.  The other two are third is 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.

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

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.

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, Sam Hartman, Michael Hofling, and Pedro Marques.

   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-7-897923867 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-7-897923867 Content-Disposition: attachment; filename=draft-ietf-lisp-04.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-04.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: March 6, 2010 D. Lewis cisco Systems September 2, 2009 Locator/ID Separation Protocol (LISP) (PROPOSED) draft-ietf-lisp-04.txt (NOT SUBMITTED) 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 March 6, 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. Farinacci, et al. Expires March 6, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . 35 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 36 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 39 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 40 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 41 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 41 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 42 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 43 7. Router Performance Considerations . . . . . . . . . . . . . . 45 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 46 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 47 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 47 Farinacci, et al. Expires March 6, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 48 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 49 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 50 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 50 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 50 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 52 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 52 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 52 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 52 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 54 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 54 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 56 12. Security Considerations . . . . . . . . . . . . . . . . . . . 57 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 58 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 14.1. Normative References . . . . . . . . . . . . . . . . . . . 61 14.2. Informative References . . . . . . . . . . . . . . . . . . 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 Farinacci, et al. Expires March 6, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 6, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 6, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 6, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 6, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 statically 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 prepends 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 statically configured. Farinacci, et al. Expires March 6, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 prepends 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 Farinacci, et al. Expires March 6, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |R|N|L|E| rflags| Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 6, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |R|N|L|E| rflags| Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | | Farinacci, et al. Expires March 6, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer 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 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 MAY be transmitted as zero by an ITR and when received by an ETR, MUST accept the packet for decapsulation. 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 decapsulation, 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. 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. R: this is the Research bit. This bit is reserved and its usage is not documented in this specification. If an implementation does not participate in the research experiment, the bit can be ignored by an ETR and accepted for packet decapsulation. Farinacci, et al. Expires March 6, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See section Section 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. 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. rflags: this 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 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. When the E-bit is clear but the N-bit is set, an ITR is either echoing a previously requested echo-nonce or providing a random nonce. See section Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least 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 outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Type of Service field (with one caveat, see below). Farinacci, et al. Expires March 6, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 When doing Re-encapsulated Tunneling: o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer 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. Farinacci, et al. Expires March 6, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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. Farinacci, et al. Expires March 6, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet with DF bit set to 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. Farinacci, et al. Expires March 6, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires March 6, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 | | + 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. Farinacci, et al. Expires March 6, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D1 |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: Farinacci, et al. Expires March 6, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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 that is labeled 'Rec' above and occurs the number of times equal to Record count. For this version of the protocol specification, a receiver MUST accept and process a record count of one or greater but a sender MUST always set the record count to one. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. 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 Farinacci, et al. Expires March 6, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request, it may originate a "verifying Map-Request", addressed to the original ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map-Request" to the original Map-Request source. If Farinacci, et al. Expires March 6, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 not, then it MUST send it to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" 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=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | 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. See section Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is enabled for the Echo-Nonce locator reachability algorithm. See Section 6.3.1 for more details. Farinacci, et al. Expires March 6, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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: this bit is reserved for use by the LISP mobile-node design documented in [LISP-MN]. Farinacci, et al. Expires March 6, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 [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 [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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 6, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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=3D3 |P| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | 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. Farinacci, et al. Expires March 6, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 6, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. Farinacci, et al. Expires March 6, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the 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 Farinacci, et al. Expires March 6, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 are injected 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-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 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. Farinacci, et al. Expires March 6, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 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 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. 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- Farinacci, et al. Expires March 6, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 obtain those benefits, especially if the 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. Farinacci, et al. Expires March 6, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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- Farinacci, et al. Expires March 6, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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-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-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-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. Farinacci, et al. Expires March 6, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the 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 ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- prefix uses is the one copied from the SMR message. 3. The remote xTR retransmits the Map-Request slowly until it gets a Map-Reply while continuing to use the cached mapping. Farinacci, et al. Expires March 6, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending 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 more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. Farinacci, et al. Expires March 6, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 6, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, Farinacci, et al. Expires March 6, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 6, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 6, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 6, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 6, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Interoperable implementations have been available since the beginning of 2009. We are trying to converge on a packet format so implementations can converge on the -04 and later drafts. 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. Farinacci, et al. Expires March 6, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 6, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts 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. Farinacci, et al. Expires March 6, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. [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, Farinacci, et al. Expires March 6, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 September 2007. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 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. Farinacci, et al. Expires March 6, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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-02.txt (work in progress), 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. Farinacci, et al. Expires March 6, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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. Farinacci, et al. Expires March 6, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, and Pedro Marques. 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. Farinacci, et al. Expires March 6, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 6, 2010 [Page 66] =0C --Apple-Mail-7-897923867 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-7-897923867-- From hartmans@mit.edu Thu Sep 3 05: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 DAF153A6B78 for ; Thu, 3 Sep 2009 05:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 XFFhhJIn7EAF for ; Thu, 3 Sep 2009 05:53: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 2F75C3A6AB8 for ; Thu, 3 Sep 2009 05:53:38 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 912DA51C5; Thu, 3 Sep 2009 08:52:03 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090902223124.755CB6BE63F@mercury.lcs.mit.edu> From: Sam Hartman Date: Thu, 03 Sep 2009 08:52:03 -0400 In-Reply-To: <20090902223124.755CB6BE63F@mercury.lcs.mit.edu> (Noel Chiappa's message of "Wed\, 2 Sep 2009 18\:31\:24 -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] #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, 03 Sep 2009 12:53:38 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Sam Hartman If a ETR receives a >> packet with this bit set and has not been explicitly configured >> to participate in an experiment, then [pick from group a]. ... >> Group A: * drop the packet * decapsulate and process the inner >> packet but ignore the LISP header Noel> I thought we had converged on another choice: Noel> * process the packet normally, ignoring the R-bit That's fine too. I'm still not supporting this, but if a consensus develops that we want such a feature,ignoring the R bit is fine. From mrw@sandstorm.net Thu Sep 3 07:23: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 9791F28C20F for ; Thu, 3 Sep 2009 07:23:54 -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 Qwcw5QJ8Hrt0 for ; Thu, 3 Sep 2009 07:23:53 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 265FD28C201 for ; Thu, 3 Sep 2009 07:23:52 -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 n83EB8o5008191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Sep 2009 10:11:08 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090902225425.834666BE641@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, 3 Sep 2009 10:11:08 -0400 References: <20090902225425.834666BE641@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [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, 03 Sep 2009 14:23:54 -0000 Hi Noel, I understand everything in your message, but I still don't think it is necessary or advisable to allocate a "research bit" in the LISP header. Dino has proposed defining _three_ new bits to support experimentation with alternate LISP header field values: the L-bit (which indicates if the locator status field contains locator status), the N-bit (which indicates if the nonce field contains a nonce), and the r-bit which (as of his latest round of edits) indicates nothing all to implementations of the -04 specification. Personally, I find the way the LISP header is defined in Dino's proposed -04 document to be very awkward and inefficient, as it uses 3 bits to support one additional (not defined in -04) format. The complex dependencies between the three bits results in most of the combinations of those bits being invalid/meaningless, and implementations will have to know what to do with those combinations if they are received. If we anticipate that there could be more than one meaning attributed to the bits in the LISP header, I think that it would be preferrable to move to a 3-bit "format" field that indicates the format of the other 61 bits. My proposed header (which I believe accomodates the needs you've described below) would look like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Form | LISP Header Fields... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LISP Header Fields (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Form: The format of the LISP header fields in this header. This document defines three formats: 0 (000) -- No fields. Remainder of LISP header should be sent as zero and ignored on receipt. 1 (001) -- Nonce present format (see below). 2 (010) -- Locator status bits present format (see below). The value 7 (111) is reserved allow extension of the format field. ETRs that receive a LISP packet with an unrecognized format should treat that packet as though it had a format value of 0 (000). The ETR should ignore the LISP header fields, and process the packet normally. [Note: Do we need a format where both the Nonce bits and the locator status bits are present at the same time? If so, why?] The remainder of the bits in the LISP header are formatted as indicated in the format field. Nonce Present Format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Form | rsvd bits |E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce (32-bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Form: LISP header format, as described above. E: (As in Dino's -04 proposal) Nonce: (As in Dino's -04 proposal) [Note: If this nonce is determined to be security sensitive and needs to be longer than 32-bits, we could expand it to 60 bits by moving the E bit to the beginning and using the rest of the LISP header as a nonce.] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Form | rsvd bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Form: LISP header format, as described above. Locator Status Bits: (As in Dino's -04 proposal) [Note: Similar to above, if we determine that more than 32 Locator Status Bits would be preferred, we could use the rsvd bits, as well.] If we adopt my proposal, Luigi (or someone else) could write a specification that defines a new format for these bits without the need to set aside a per-proposal "R-bit" for that purpose. Since implementations of this proposal would ignore unknown formats, it isn't necessary for us to allocate the new format value in this document, as only the nodes that understand the new format need to know the format value. My proposal allows us to define up to 5 additional LISP header formats using the same number of bits that Dino's current proposal uses to support one additional format. Margaret On Sep 2, 2009, at 6:54 PM, Noel Chiappa wrote: >> From: Sam Hartman > >> I'm not following the reasoning or discussion that lead from where I >> think we were in Stockholm to a conclusion that map versioning needs >> research but the other mechanisms do not. > > The problem is that we're operating in something of a vacuum, > operational-data-wise. (Apologies in advance to the degree that any > of the > following is teaching of egg-sucking... And I also apologize in > advance if I > have mis-understood anything I've heard from various collaborators, > so if I > get something wrong, 'just shoot me'... :-) > > > We have what everyone feels has the _potential_ to be a problem - i.e. > outdated mappings. There are also a bunch of ideas on various > different > mechanisms to tackle that problem, each of which has plusses and > minusses > (complexity, operational overhead, etc). > > In the particular case of mapping-versioning, piggybacking it on > user-data-trafffic has some big advantages (e.g. no extra packet > traffic), > but from an _implementation_ point of view, in one of our main > testbeds > (Dino's), my understanding is that it has a big downside, which is > that > getting the data plane to do anything control-oriented is really hard. > (I got the impression that doing echo-noncing for reachabilty > detection was > fairly painful, for instance.) > > Which of course shouldn't weigh too heavily on a design decision > (ask me > sometime about the variable length IP addresses in IPv3, and the > number of > pointer registers available in TENEX at interrupt time - you can > guess where > that story goes :-( - unless it's a _typical_ kind of problem for > high-end > router boxes (i.e. piggybacking control operations on user-data > traffic), > which I get the sense it might be. > > Still, when you add to that the concept that a versioning-type > solution (I > personally prefer checksums to versions, but that's an engineering > detail) > can be incrementally added later, I think that's _part_ of why that > one is > still 'on the back burner'. > > > The thing is that without more real-world data on i) how big a problem > outdated mappings are, ii) how expensive various solutions are, iii) > how well > those solutions work, etc we're kind of shooting in the dark without a > night-scope. This is also a case where I'm not sure simulation would > even > help much, since it depends a lot on other things which we also > don't have a > lot of data on, e.g. how often mappings will be changed. > > Yeah, people have an 'engineering sense' for a lot of this, but > intuition is > not a 100.000% substitute for actual experience. And when you add in > the fact > that it's something we can add later without too much pain, I think > that's > the thinking behind a position of 'let's add these mechanisms, and > study that > other one some more'. > > Noel > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Thu Sep 3 08:23: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 941263A6D8C for ; Thu, 3 Sep 2009 08:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.306 X-Spam-Level: X-Spam-Status: No, score=-6.306 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, J_CHICKENPOX_31=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 p8xjh4IQ+EPt for ; Thu, 3 Sep 2009 08:23:15 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 855053A6D62 for ; Thu, 3 Sep 2009 08:23:15 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2C7FC6BE572; Thu, 3 Sep 2009 11:21:00 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090903152100.2C7FC6BE572@mercury.lcs.mit.edu> Date: Thu, 3 Sep 2009 11:21:00 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [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, 03 Sep 2009 15:23:16 -0000 > From: Margaret Wasserman > I still don't think it is necessary or advisable to allocate a > "research bit" in the LISP header. Slight mental whiplash here, because the message you'e replying to is about the decision not to include the _mechanism_ in this go-round, but that's not important... On the R-bit, I think that whether we document it or not, it won't make a big difference, _provided_ we specify clearly and exactly what to do when a packet with that bit set arrives - which is to process it, ignoring the bit. The _behaviour_ I do feel is important to specify, because it allows us to incrementally deploy a new control mechanism piggy-backed on user-data traffic _in an interoperable manner_. > defining _three_ new bits to support experimentation with alternate > LISP header field values: the L-bit ... the N-bit I see these bits not principally for "support[ing] experimentation", as for supporting future _interoperable_ deployment of new control functions piggybacked on user-data traffic - a capability which I view as critical. Without bits which affirmatively say 'this field contains this defined function', we can't borrow that field to perform some _other_ function which we will potentially discover we need; at least, in a way which won't potentially confuse already-deployed boxes. > I find the way the LISP header is defined ... to be very awkward and > inefficient, as it uses 3 bits to support one additional .. format. We have two fields (24-bit and 32-bit), which we wish to affirmatively control (as above) independently. One of those fields has two potential functions (sent nonce, echoed nonce). That pretty much requires three bits: one for each field to say if it's in use, and one for the one field which has two uses, to say which use it is in the current packet. > The complex dependencies between the three bits results in most of the > combinations of those bits being invalid/meaningless Not really. Here's a quick table: L N E 0 0 0 No Locator-Status bits, no nonce (of either kind) 0 0 1 Not allowed 0 1 0 No Locator-Status bits, sent nonce 0 1 1 No Locator-Status bits, echoed nonce 1 0 0 Valid Locator-Status bits, no nonce (of either kind) 1 0 1 Not allowed 1 1 0 Valid Locator-Status bits, sent nonce 1 1 1 Valid Locator-Status bits, echoed nonce Only two out of eight are invalid. And the ones with 'no LSB' or 'no nonce' are not useless, because those might occur in the future if we deploy a new piggybacked control function which needs to use one of those fields to carry its data. > implementations will have to know what to do with those combinations if > they are received. Yes, but it's simple enough to do, either in hardware or software. There are two completely separate functions, each controlled by one bit, and the second function has two modes, 'sent' and 'echoed', again controlled by one bit. > If we anticipate that there could be more than one meaning attributed > to the bits in the LISP header, I think that it would be preferrable to > move to a 3-bit "format" field that indicates the format of the other > 61 bits. This doesn't have the 'interoperable evolution' attribute that I identified as very important - i.e. the ability for unmodified boxes to keep performing _existing_ functions on packets which may also contain some new stuff they don't understand. With this 3-bit field, if a box sees one which has a new value which it doesn't understand, there is nothing it can do with it except toss it. Yes, we could have some sort of mechanism for an ITR to find out what modes a given ETR supports, so it would only send values the ETR would understand, but I don't see that the extra complexity of that buys us that much, over the proposed flags bits. > My proposal allows us to define up to 5 additional LISP header formats > using the same number of bits that Dino's current proposal uses to > support one additional format. For one, technically your thing uses 4 bits, because the E bit counts. I mean, the existing format could have carved the E bit out of the 24-bit field, in which case it would only use '2' bits.... I don't see that as worth doing, though, because we still have a number of spare flag bits for various future uses, and the 'not allowed' {N=0;E=1} value serves a dual function as a handy 'escape' to a new format, contained entirely in the first byte. For another, and more importantly, your format does not allow doing both Locator-Status _and_ Nonce in a single packet. That means there has to be extra logic _in the control plane_ (which is a PITA - separate part of the box in most routers, and perhaps entirely hardware in high-end boxes) to decide which user-data packets are going to carry the LS function and which the Nonce function, etc, etc. Noel From mrw@sandstorm.net Thu Sep 3 08:57: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 5D97728C2BB for ; Thu, 3 Sep 2009 08:57:40 -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 To4qrDSHxQhv for ; Thu, 3 Sep 2009 08:57:39 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 15EC428C2BA for ; Thu, 3 Sep 2009 08:57:38 -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 n83FsqVB014027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Sep 2009 11:54:57 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <6521739C-A029-4B6E-A125-EB23A10F2F2D@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090903152100.2C7FC6BE572@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, 3 Sep 2009 11:54:51 -0400 References: <20090903152100.2C7FC6BE572@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [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, 03 Sep 2009 15:57:40 -0000 On Sep 3, 2009, at 11:21 AM, Noel Chiappa wrote: > > On the R-bit, I think that whether we document it or not, it won't > make a big > difference, _provided_ we specify clearly and exactly what to do > when a > packet with that bit set arrives - which is to process it, ignoring > the bit. That is exactly what the current LISP spec says to do with all of the reserved flags -- ignore them on receipt. > > We have two fields (24-bit and 32-bit), which we wish to affirmatively > control (as above) independently. One of those fields has two > potential > functions (sent nonce, echoed nonce). That pretty much requires > three bits: > one for each field to say if it's in use, and one for the one field > which has > two uses, to say which use it is in the current packet. Actually, those aren't the three bits I was talking about. Dino's -04 proposal actually has _four_ bits defined. The E-bit is used to request nonce echoing. The L, N and R bits are the ones that define what the fields in the packet mean. I don't believe we have established that _we_ want to affirmatively and separately control whether those two fields are present. Dino's proposal tries to do that, but that is all new to me. I don't think we had discussed the need for bits to indicate whether each of these fields is present on the list, and I don't know why it is necessary to control them separately. I also don't know why you couldn't use part of the locator-status field to indicate whether it is there, since it would never be remotely useful to send an indication that all of the locators are down, would it? > >> The complex dependencies between the three bits results in most of >> the >> combinations of those bits being invalid/meaningless > > Not really. Here's a quick table: > > L N E > > 0 0 0 No Locator-Status bits, no nonce (of either kind) > 0 0 1 Not allowed > 0 1 0 No Locator-Status bits, sent nonce > 0 1 1 No Locator-Status bits, echoed nonce > 1 0 0 Valid Locator-Status bits, no nonce (of either kind) > 1 0 1 Not allowed > 1 1 0 Valid Locator-Status bits, sent nonce > 1 1 1 Valid Locator-Status bits, echoed nonce As I indicated above, you aren't talking about the same three bits that I'm talking about. Also, you seem to be confused about the purpose of the E-bit, which is to request that the other side echo the nonce that is in this packet, not to indicate that the nonce in this packet is echoed. > Only two out of eight are invalid. And the ones with 'no LSB' or 'no > nonce' > are not useless, because those might occur in the future if we > deploy a new > piggybacked control function which needs to use one of those fields > to carry > its data. The three bits I'm talking about are the R, L and N bits, all of which control which fields are in the packet. The combinations of these bits are: R L N 0 0 0 - Not "research", no locator-status, no nonce 0 0 1 - Not "research", no locator-status, nonce is present 0 1 0 - Not "research", locator-status is present, no nonce 0 1 1 - Not "research", locator-status is present, nonce is present 1 0 0 - "Research", no locator-status, no nonce 1 0 1 - Invalid 1 1 0 - Invalid 1 1 1 - Invalid The first four are fine, and the behavior in all of these cases is defined in Dino's -04 proposal. For the last four, we've wasted an entire bit to give us one other choice... And, nodes that implement the -04 proposal will do _exactly_ the same thing in that situation (ignore the r-bit, process the packet), as they would do if we didn't define the r-bit in the LISP specification at all. So, why waste an entire bit for this? > >> If we anticipate that there could be more than one meaning attributed >> to the bits in the LISP header, I think that it would be >> preferrable to >> move to a 3-bit "format" field that indicates the format of the other >> 61 bits. > > This doesn't have the 'interoperable evolution' attribute that I > identified > as very important - i.e. the ability for unmodified boxes to keep > performing > _existing_ functions on packets which may also contain some new > stuff they > don't understand. With this 3-bit field, if a box sees one which has > a new > value which it doesn't understand, there is nothing it can do with > it except > toss it. Could you do me a favor and actually _read_ the text that I provided before rejecting it? My proposal explicitly states that ETRs that receive formats they don't understand should treat them like 0 (000), ignore the LISP header bits, and process the packet as normal. That is _exactly_ the type of "interoperability evolution" that you have identified as important. > >> My proposal allows us to define up to 5 additional LISP header >> formats >> using the same number of bits that Dino's current proposal uses to >> support one additional format. > > For one, technically your thing uses 4 bits, because the E bit counts. The E bit is in both places... My proposal replaces three bits in Dino's proposal (the R, N and L bits) with three bits. They both have an E-bit, too. > For another, and more importantly, your format does not allow doing > both > Locator-Status _and_ Nonce in a single packet. It could, if we define a fourth format for that cases. > That means there has to be > extra logic _in the control plane_ (which is a PITA - separate part > of the > box in most routers, and perhaps entirely hardware in high-end > boxes) to > decide which user-data packets are going to carry the LS function > and which > the Nonce function, etc, etc. The existence of the separate L and N bits in Dino's proposal already implies that you want this logic -- you don't need it, because it would be perfectly fine never to send either. You _do_ need logic to _notice_ when you have been asked to echo a nonce and send that nonce in the return packet. In general, I don't understand what nonce echoing gets us that couldn't be more simply and cleanly accomplished via the control plane, but presumably someone sees a use for it. In fact, I'd be quite sympathetic to an argument that the current LISP header functionality doesn't warrant an extra 64 bits in every data packet, and we should drop the LISP header altogether... If we are going to keep the LISP header, though, I hope we can avoid creating a rat's-nest-like set of interdependent flag fields. Margaret From jnc@mercury.lcs.mit.edu Thu Sep 3 10:31: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 0BC8228C39A for ; Thu, 3 Sep 2009 10:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 Saqtp3B2pI6V for ; Thu, 3 Sep 2009 10: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 87E1228C380 for ; Thu, 3 Sep 2009 10:31:22 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 91D6B6BE648; Thu, 3 Sep 2009 13:30:58 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090903173058.91D6B6BE648@mercury.lcs.mit.edu> Date: Thu, 3 Sep 2009 13:30:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [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, 03 Sep 2009 17:31:24 -0000 > From: Margaret Wasserman > those aren't the three bits I was talking about. Got it - I tend to not think about the R-bit, as it doesn't do anything. > I don't believe we have established that _we_ want to affirmatively and > separately control whether those two fields are present. ... > I don't know why it is necessary to control them separately. I think it's very important to do so to maximize future flexibility of new piggybacked control functions, should be find we need them. But I guess I already said something very close to that; really, I can't put it any better than that, sorry. It's an engineering judgement that I have, based on a lot of observations of how protocols evolve over time. Your judgement may differ from mine, but I don't know what to do about that. > I also don't know why you couldn't use part of the locator-status field > to indicate whether it is there I think it's best if we keep all the control bits in one place; allocating that bit out of the 32-bit field doesn't really do anything, except move it somewhere else in the packet - to what end? More importantly, if that bit _is_ allocated out of that 32-bit field, it makes it impossible (or at least very confusing - e.g. 'if the X flag bit is set, the 32-bit field isn't a 1-bit control field, and 31 bit of LS, but just a flat 32 bits') for _other_ uses to use the full 32 bits, which might be important (e.g. to hold an IPv4 address). > you seem to be confused about the purpose of the E-bit, which is to > request that the other side echo the nonce that is in this packet, not > to indicate that the nonce in this packet is echoed. Oops, sorry, got the bit sense inverted in my head - the overall purpose I did have correct, actually. > The three bits I'm talking about are the R, L and N bits ... > The combinations of these bits are: > > R L N > 1 0 0 - "Research", no locator-status, no nonce > 1 0 1 - Invalid > 1 1 0 - Invalid > 1 1 1 - Invalid That was an earlier (a couple of days ago) version. As of yesterday afternoon, the proposal ('process the packet normally, ignoring the R-bit') would actually have allowed either L or N to be set along with R - although depending on the (as-yet undefined) definition of the function associated with R, setting one or the other (or perhaps both) might have been invalid. > nodes that implement the -04 proposal will do _exactly_ the same thing > in that situation (ignore the r-bit, process the packet), as they would > do if we didn't define the r-bit in the LISP specification at all. Which is why I said "whether we document [the R-bit] or not, it won't make a big difference". > My proposal explicitly states that ETRs that receive formats they don't > understand should treat them like 0 (000), ignore the LISP header bits, > and process the packet as normal. Sorry, got confused between the different values. That logic does have basically the same effect, but it does have some potentially significant differences. E.g. since it doesn't allow addition of a new function _alongside_ other already-defined functions (e.g. nonce), that might have an impact. Without a crystal ball as to how often various things will get used, how important the nonce is, etc, one can't draw any definite conclusion from that, though. >> your format does not allow doing both Locator-Status _and_ Nonce in a >> single packet. > It could, if we define a fourth format for that cases. Yes, but if we add more functions, in going down the 'values' road, instead of the 'bits' road, we would need an exponentially-increasing number of values to signal different combinations. >> That means there has to be extra logic _in the control plane_ ... to >> decide which user-data packets are going to carry the LS function and >> which the Nonce function > The existence of the separate L and N bits in Dino's proposal already > implies that you want this logic Ah, no. It _allows_ an ITR to decide to do that, but it doesn't _mandate_ that an ITR to do that (as the 3-bit type code would). If an ITR implementor were to decide that it would introduce too much complexity to do one or the other, they can just always (modulo other future control functions) do both. > In general, I don't understand what nonce echoing gets us that couldn't > be more simply and cleanly accomplished via the control plane, but > presumably someone sees a use for it. Start with the recognition that the fan-out for many xTRs is going to be _much_ larger than the fanout for any router - because neighour xTRs can be spread out over the entire Internet, not just the local region. Routers typically have at most a few dozen direct neighbours, and it's quite feasible for a router to ping them all to make sure they are up and reachable. An xTR at a large site might have _thousands_ of neighbour xTRs, and pinging them all, especially at a high-enough rate to _quickly_ discover failures (which need to be bypassed ASAP for good service), would create enourmous control-traffic overhead. That's why people accepted the considerable hassle (as you correctly noted) involved in piggy-backing the nonce control function onto user-data traffic. > I hope we can avoid creating a rat's-nest-like set of interdependent > flag fields. The only way to avoid interdependent control bits is to either i) use values (which can lead to needing exponential numbers of values as the number of functions increases, and in addition is not good for hardware implementations), or ii) not share header fields - which means either: - more overhead on _every_ packet, in many cases to provide private fields for functions that only get used once in a great while; or - variable-format headers, so that the extra fields only get added when they are needed. This conundrum has been with networking for a long time, and some of the earlier attempts to solve it (e.g. IPv4 options) have definitely been problematic. Maybe this one will be painful too, but I don't think there's a simple, perfect, solution - if there was, it probably would have been worked out a long time ago. In the meantime, this path seems to me to have lots of nice characteristics, and a downside (interdependencies between control bits _in terms of legal settings_ - there is no complexity in terms of the actual operation) which I see as smaller than the other two options. Noel From mrw@sandstorm.net Thu Sep 3 11:02: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 BFB1E3A6765 for ; Thu, 3 Sep 2009 11:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=-0.307, 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 fMKyHQWbSLtN for ; Thu, 3 Sep 2009 11:02:43 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id C4EAA3A6802 for ; Thu, 3 Sep 2009 11:02:38 -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 n83I1U4H020804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Sep 2009 14:01:30 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <17F0EC8D-72F6-4C6B-9D10-9837E27A43FC@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090903173058.91D6B6BE648@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, 3 Sep 2009 14:01:30 -0400 References: <20090903173058.91D6B6BE648@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [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, 03 Sep 2009 18:02:44 -0000 On Sep 3, 2009, at 1:30 PM, Noel Chiappa wrote: >> From: Margaret Wasserman > >> those aren't the three bits I was talking about. > > Got it - I tend to not think about the R-bit, as it doesn't do > anything. So, can we drop it from the LISP specification? Having a bit defined that doesn't do anything just wastes a bit... >> I don't believe we have established that _we_ want to affirmatively >> and >> separately control whether those two fields are present. ... >> I don't know why it is necessary to control them separately. > > I think it's very important to do so to maximize future flexibility > of new > piggybacked control functions, should be find we need them. But I > guess I > already said something very close to that; really, I can't put it > any better > than that, sorry. I am not talking about why we want to piggyback in general... You have stated that we want to pre-define the LISP header to have a flags section, and two separate fields (one 24-bit field and one 32-bit field) that are controlled separately. I don't know why we wouldn't want to view the LISP header as one big field that we can redefine for different uses. Even if we decide that we do like the idea of having two separate fields, so that (for example) we can include the nonce in packets with a variety of other meanings for the 32-bit field, why do we want to use a whole bit to say only that the locator is on or off? If we come up with 6 different ways to use that 32-bit field, are you assuming we will have 6 mutually exclusive bits to control the contents of that one field -- one that says that it is or isn't a locator, one that says it isn't or isn't "foo", etc? Or would it be better to set aside a small number of bits and use all of their values to indicate what is in the field -- so all-zeros means it is empty, 1 means it is locator-status, two means it is "foo", etc. > It's an engineering judgement that I have, based on a lot of > observations of > how protocols evolve over time. Your judgement may differ from mine, > but I > don't know what to do about that. I've also watched protocol designers strangle themselves by allocating bits for all sorts of eventually-obsolete purposes, and then having to re-use bits in painful combinations to do new things... > > I think it's best if we keep all the control bits in one place; > allocating > that bit out of the 32-bit field doesn't really do anything, except > move it > somewhere else in the packet - to what end? I wasn't really suggesting a bit in the locator-status field. I was suggesting something like: If it is zero, it isn't in use. If it is non-zero it is significant. Because if all of the RLOCs for an EID are down, there isn't anyone left to send that message. > > That was an earlier (a couple of days ago) version. As of yesterday > afternoon, the proposal ('process the packet normally, ignoring the > R-bit') > would actually have allowed either L or N to be set along with R - > although > depending on the (as-yet undefined) definition of the function > associated > with R, setting one or the other (or perhaps both) might have been > invalid. I guess I may not be looking at the latest version. Dino keeps sending new HTML diffs that all "diff" from -03, not from each other, so I haven't figured out a good way to tell what he is proposing to change in each one. What is he date in the version you are referring to? > Which is why I said "whether we document [the R-bit] or not, it > won't make a > big difference". It'll just waste a bit, so let's not do it... >> My proposal explicitly states that ETRs that receive formats they >> don't >> understand should treat them like 0 (000), ignore the LISP header >> bits, >> and process the packet as normal. > > Sorry, got confused between the different values. > > That logic does have basically the same effect, but it does have some > potentially significant differences. E.g. since it doesn't allow > addition of > a new function _alongside_ other already-defined functions (e.g. > nonce), that > might have an impact. It could, in the sense that the nonce and a different field could both be included in one of the formats. >> It could, if we define a fourth format for that cases. > > Yes, but if we add more functions, in going down the 'values' road, > instead of > the 'bits' road, we would need an exponentially-increasing number of > values to > signal different combinations. Ummm... more bits is the _same_ as exponentially increasing numbers of values. The values path will always have the same number of bits (except when it has less bits, because some combinations are invalid). Let's take an example... If we have a nonce field and five different choices for the 32-bit field, and we follow the current model, we'll use 6 bits: N (for the nonce) & L1 L2 L3 L4 L5 N will tell us if the nonce field is active. L1 tells us if the 32-bit field contains locator-status bits or not, L2 tells us if it contains locator-use-2 bits or not, etc. L1, L2, L3, L4 and L5 are all mutually exclusive, since you can't put two things in the same 32-bit field. However, if we use values, we need enough room to represent 11 different choices: - no fields active - L1 without nonce - L1 with nonce - L2 without nonce - L2 with nonce - L3 without nonce - L3 with nonce - L4 without nonce - L4 with nonce - L5 without nonce - L5 with nonce And, 11 choices can fit into 4 bits. The same thing happens if the nonce field gets reused: If you have three choices for the "N" field and 5 choices for the "L" field, in your model you would require 8 bits. In my model, you would require 16 values (no fields and all 15 combinations), which will fit in 4 bits. Even if you have 8 uses for each field, your model will require 16 bits, an my model will require 7 bits (for 65 combined choices). With only two fields, I don't think you ever cross over into a case where your model requires fewer bits than my model. Do you? > >>> That means there has to be extra logic _in the control plane_ ... to >>> decide which user-data packets are going to carry the LS function >>> and >>> which the Nonce function > >> The existence of the separate L and N bits in Dino's proposal already >> implies that you want this logic > > Ah, no. It _allows_ an ITR to decide to do that, but it doesn't > _mandate_ > that an ITR to do that (as the 3-bit type code would). If an ITR > implementor > were to decide that it would introduce too much complexity to do one > or the > other, they can just always (modulo other future control functions) > do both. My model doesn't mandate that an ITR do that either... How does representing the same information in a different set of bits require you to do any logic you aren't already doing? In your model, you need to determine how to set each of the flags. In my model you need to choose the right format for what you are sending. These aren't logically different until you get to the "write the actual packet" moment. > >> In general, I don't understand what nonce echoing gets us that >> couldn't >> be more simply and cleanly accomplished via the control plane, but >> presumably someone sees a use for it. > > Start with the recognition that the fan-out for many xTRs is going > to be > _much_ larger than the fanout for any router - because neighour xTRs > can be > spread out over the entire Internet, not just the local region. > Routers > typically have at most a few dozen direct neighbours, and it's quite > feasible > for a router to ping them all to make sure they are up and reachable. I understand that if you want to ping your neighbors all of the time it is best to do it in-line. But, why do you want to ping your neighbors all of the time?fic. > > > >> I hope we can avoid creating a rat's-nest-like set of interdependent >> flag fields. > > The only way to avoid interdependent control bits is to either i) > use values > (which can lead to needing exponential numbers of values as the > number of > functions increases, You have this backwards. > and in addition is not good for hardware > implementations), You have not offered any argument that I understand for why this is not good for hardware implementations. > or ii) not share header fields - which means either: > > - more overhead on _every_ packet, in many cases to provide private > fields > for functions that only get used once in a great while; or > - variable-format headers, so that the extra fields only get added > when > they are needed. My proposal is a different way to share header fields, so these arguments don't apply. Margaret From hartmans@mit.edu Thu Sep 3 11:03: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 027A93A6821 for ; Thu, 3 Sep 2009 11:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 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 UxtNw3EnTd2s for ; Thu, 3 Sep 2009 11:03: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 217F23A67FF for ; Thu, 3 Sep 2009 11:03:57 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D3BF851C5; Thu, 3 Sep 2009 13:55:27 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Thu, 03 Sep 2009 13:55:27 -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] IETF 75 audio pointer X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 03 Sep 2009 18:03:58 -0000 I may not be the only one who wants to listen to the IETF 75 audio. I found grabbing the stream to be far more difficult than I expected so I'll save you trouble. Please see: ftp://videolab.uoregon.edu/pub/videolab/media/ietf75/ietf75-mon-kongressc-pm.mp3 You have to skip about an hour of silence at the beginning. From trac@tools.ietf.org Thu Sep 3 11:49: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 7DF3F3A672F for ; Thu, 3 Sep 2009 11:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, 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 we3rGq0Tg40i for ; Thu, 3 Sep 2009 11:49:41 -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 D224D3A67AE for ; Thu, 3 Sep 2009 11:49:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MjHNM-0006ih-GM; Thu, 03 Sep 2009 11:49:40 -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, 03 Sep 2009 18:49:40 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/17 Message-ID: <060.7f4b69749c25ca2cbdec2632ec17d536@tools.ietf.org> X-Trac-Ticket-ID: 17 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] #17: Data plane request for control-plane reply 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, 03 Sep 2009 18:49:43 -0000 #17: Data plane request for control-plane reply ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@mit.edu | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- At the IETF 75 meeting, Fred Templin proposed having a bit in a data plane packet to request a control plane reply. Darrel asked to take this proposal to e-mail. -- Ticket URL: lisp LISP WG document issues From lear@cisco.com Thu Sep 3 12:35: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 4F6C73A67B5 for ; Thu, 3 Sep 2009 12:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.262 X-Spam-Level: X-Spam-Status: No, score=-10.262 tagged_above=-999 required=5 tests=[AWL=0.337, 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 81FZPbHhcYxa for ; Thu, 3 Sep 2009 12:35:24 -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 98BEE3A679C for ; Thu, 3 Sep 2009 12:35:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8AAES3n0qQ/uCKe2dsb2JhbACBU5lqAQEWJAambIhBAZAlBYQb X-IronPort-AV: E=Sophos;i="4.44,326,1249257600"; d="scan'208";a="48589911" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Sep 2009 19:34:37 +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 n83JYbN5006810; Thu, 3 Sep 2009 21:34:37 +0200 Received: from adsl-247-4-fixip.tiscali.ch (dhcp-10-61-109-103.cisco.com [10.61.109.103]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n83JYbAd024608; Thu, 3 Sep 2009 19:34:37 GMT Message-ID: <4AA01A4D.2090301@cisco.com> Date: Thu, 03 Sep 2009 21:34:37 +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: Margaret Wasserman References: <20090902225425.834666BE641@mercury.lcs.mit.edu> 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=392; t=1252006477; x=1252870477; 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#16=3A=20map=20versioning=20re solution |Sender:=20; bh=hikB9ct8y/w8ZEgv04oaYApJ3LSuKY289s0+W3FOMEU=; b=oLpJ/C5f6pilMXDsJtz0HJqCknQjcfK/qZB44wIsJZd3CYoyBZus5UPpbL PCkRSrq15N6TGSfvjGVy6kD2iH4Qfo7zNXlQnzebDwSDaQnNCdy/Wm8ZSDOo QcIZHMhB6i; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [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, 03 Sep 2009 19:35:25 -0000 On 9/3/09 4:11 PM, Margaret Wasserman wrote: > > Hi Noel, > > I understand everything in your message, but I still don't think it is > necessary or advisable to allocate a "research bit" in the LISP header. I'll go further. I think adding research bits generally is a bad idea, and in this case we are ducking an issue about version numbering. Let's not duck the issue. Eliot From jnc@mercury.lcs.mit.edu Thu Sep 3 12:35: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 046E73A684E for ; Thu, 3 Sep 2009 12:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 lUcdlJEQFDrd for ; Thu, 3 Sep 2009 12:35: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 23B593A683D for ; Thu, 3 Sep 2009 12:35:30 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B243E6BE649; Thu, 3 Sep 2009 15:08:41 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090903190841.B243E6BE649@mercury.lcs.mit.edu> Date: Thu, 3 Sep 2009 15:08:41 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [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, 03 Sep 2009 19:35:32 -0000 > From: Margaret Wasserman >> I think it's very important to do so to maximize future flexibility of >> new piggybacked control functions, should be find we need them. > I am not talking about why we want to piggyback in general... Right, but I wasn't talking about that either. > pre-define the LISP header to have a flags section, and two separate > fields (one 24-bit field and one 32-bit field) that are controlled > separately. > I don't know why we wouldn't want to view the LISP header as one big > field Well, if we really need a 56-bit field, we can do that; in fact, that's what sort of what the original definition of the R-bit tried to do. I personally feel that the need for such a field is unlikely, but that's not very probative, of course. > If we come up with 6 different ways to use that 32-bit field, are you > assuming we will have 6 mutually exclusive bits to control the contents > of that one field Possibly, but it's hard to say, in such a vacuum. There might be a couple of different functions grouped together, with one 'master' bit to select them, e.g. the way nonces are done. > would it be better to set aside a small number of bits and use all of > their values to indicate what is in the field I suggested something very vaguely similar to this, in the sense that it tried to predefine some limited semantics for some 'unused' bits. (The actual idea was: have a group of bits which, if set, and you don't understand that bit, you don't process the packet; and another group which, if set, and you don't understand the bit, you just ignore the bit.) However, it seemed that leaving them completely undefined was the most flexible thing to do. > I wasn't really suggesting a bit in the locator-status field. I was > suggesting something like: If it is zero, it isn't in use. If it is > non-zero it is significant. Because if all of the RLOCs for an EID are > down, there isn't anyone left to send that message. Ah, OK, got it. Still, that doesn't help me do something else with the field (which would almost certainly involve its being non-zero). > What is he date in the version you are referring to? Umm, it was a message to the list, let me see... here it is: http://www.ietf.org/mail-archive/web/lisp/current/msg01197.html http://www.ietf.org/mail-archive/web/lisp/current/msg01199.html with an editing error in the first one fixed in the latter one. >> we would need an exponentially-increasing number of values to signal >> different combinations. > Ummm... more bits is the _same_ as exponentially increasing numbers of > values. The values path will always have the same number of bits > (except when it has less bits, because some combinations are invalid). Good point. So it would be more the issue of the decoding logic (to control what happens) being more complicated - which might be an issue for high-end (hardware) routers. (In addition to the previous point about deploying new functions in parallel with existing ones). > My model doesn't mandate that an ITR do that either... How does > representing the same information in a different set of bits require > you to do any logic you aren't already doing? That was all in response to your original proposal, in which packets could contain either a nonce, or Locator-Status bits, but not both (you didn't originally define a format for a packet that could contain both). > why do you want to ping your neighbors all of the time? To make sure that they are up and reachable (i.e. that there's not some problem in the network between source A and destination B which is preventing packets from getting from A to B, even though A and B are both up, e.g. a routing problem in some intermediate ISP). I gather that this is really a fairly hot issue for many potential users - they really want reliability, no mysterious traffic black holes (can't say I blame them :-). Also, I wish we had a better term than 'neighbours' for 'partner xTR', because those 'neighbours' may in fact be on the other side of the Internet; I think the term 'neighbour' can give an incorrect subliminal sense of how many, how far, etc. > You have not offered any argument that I understand for why this is not > good for hardware implementations. It's just much easier to look at a single bit and say 'oh, this bit is on, therefore I need to do [this function]', rather than have to do some complex table thing and say 'oh, the value of this field is one of {2,5,6}, therefore I need to do [this function]'. Noel From hartmans@mit.edu Thu Sep 3 12:51: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 9D9853A6839 for ; Thu, 3 Sep 2009 12:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 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 AhYg+VNRLMf3 for ; Thu, 3 Sep 2009 12:51: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 E19153A67A1 for ; Thu, 3 Sep 2009 12:51:18 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0C3AA51C5; Thu, 3 Sep 2009 15:49:47 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Thu, 03 Sep 2009 15:49:47 -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]: Desire to expand data plane for map versioning or handle in the control plane X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 03 Sep 2009 19:51:19 -0000 Folks, I just listened to the Stockholm audio--at least the locator reachability and map versioning discussions. In summarizing the discussion, Darrel acting as chair pointed out that the difference betwene what Luigi and Dino were talking about had to do with whether it happened in the control plane or data plane. Dino said that the idea of sending a map request to someone to let them know that your mapping information has changed was a good idea. The question though is whether it should be triggered by a data plane mechanism--I.E. map versioning--or should remain in the control plane. Darrel said he would ask that question on the list. That hasn't happened so far, so I'm asking it now. From jnc@mercury.lcs.mit.edu Thu Sep 3 13: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 D52433A68D2 for ; Thu, 3 Sep 2009 13:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 wSDZFdTlebbD for ; Thu, 3 Sep 2009 13:32:13 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0F2EB3A659C for ; Thu, 3 Sep 2009 13:32:12 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3B6566BE649; Thu, 3 Sep 2009 16:31:19 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090903203119.3B6566BE649@mercury.lcs.mit.edu> Date: Thu, 3 Sep 2009 16:31:19 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [#16]: Desire to expand data plane for map versioning or handle in the control plane X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 03 Sep 2009 20:32:14 -0000 > From: Sam Hartman > The question though is whether it should be triggered by a data plane > mechanism .. or should remain in the control plane. > ... ask that question on the list. That hasn't happened so far, so I'm > asking it now. ??? I thought that's what this sequence of messages yesterday: http://www.ietf.org/mail-archive/web/lisp/current/msg01200.html http://www.ietf.org/mail-archive/web/lisp/current/msg01204.html was about... (BTW, when I talked about "various different mechanisms to tackle that problem", I was meaning _discovering_ that there's an outdated mapping. With that datum in hand, updating is trivial; it's discovering that the mapping is outdated that could be expensive.) Noel From mrw@sandstorm.net Thu Sep 3 13:54: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 290483A6967 for ; Thu, 3 Sep 2009 13:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 RGZb9ku+nyIx for ; Thu, 3 Sep 2009 13:54:14 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 154233A6934 for ; Thu, 3 Sep 2009 13:54:13 -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 n83KraDH028878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Sep 2009 16:53:44 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: 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: Thu, 3 Sep 2009 16:53:17 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] [#16]: Desire to expand data plane for map versioning or handle in the control plane X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 03 Sep 2009 20:54:16 -0000 On Sep 3, 2009, at 3:49 PM, Sam Hartman wrote: > Folks, I just listened to the Stockholm audio--at least the locator > reachability and map versioning discussions. > > In summarizing the discussion, Darrel acting as chair pointed out that > the difference betwene what Luigi and Dino were talking about had to > do with whether it happened in the control plane or data plane. Dino > said that the idea of sending a map request to someone to let them > know that your mapping information has changed was a good idea. The > question though is whether it should be triggered by a data plane > mechanism--I.E. map versioning--or should remain in the control plane. Neither? I'd prefer that we use short-enough TTLs to allow new mapping entries to be detected in a reasonably short period of time without an explicit signalling mechanism. If there is concern that this would result in too much mapping traffic, we could work on a mechanism to extend the TTL (and suppress subsequent mapping lookups) when there is ongoing successful communication. Margaret From darlewis@cisco.com Thu Sep 3 14:06: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 135593A6934 for ; Thu, 3 Sep 2009 14:06:37 -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 bCDMjF49beW8 for ; Thu, 3 Sep 2009 14:06: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 51EBA3A68CE for ; Thu, 3 Sep 2009 14:06:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANPMn0qrR7PD/2dsb2JhbADCbohBAZAqBYQbimc X-IronPort-AV: E=Sophos;i="4.44,327,1249257600"; d="scan'208";a="381536356" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Sep 2009 21:04:44 +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 n83L4iI8009196; Thu, 3 Sep 2009 14:04:44 -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 n83L4i6G026108; Thu, 3 Sep 2009 21:04:44 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, 3 Sep 2009 14:04:43 -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, 3 Sep 2009 14:04:44 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] [#16]: Desire to expand data plane for map versioning orhandle in the control plane Thread-Index: Acosz/Yb4yxpkhXVTaWO47LzYPvpowACiKhQ References: From: "Darrel Lewis (darlewis)" To: "Sam Hartman" , X-OriginalArrivalTime: 03 Sep 2009 21:04:44.0061 (UTC) FILETIME=[2948CCD0:01CA2CDA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=184; t=1252011884; x=1252875884; 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]=20[#16]=3A=20Desire=20to=20expan d=20data=20plane=20for=20map=20versioning=20orhandle=20in=20 the=20control=20plane |Sender:=20; bh=uLnJ1S3NE2eZolC6ARsOfsw5i/nJjwVNNFJQOfjcMpg=; b=jew3vpbKR0ByeEC0s+Tikgja88fF/jHG8xg3n83q+GCoaXq/2pld9xlrXH XNNT4C1JH1VNz8I70/q6suGEZ51GeTZzyezlF4qz0jOOPyJawc83Eslrhpua gy2Ed80OQ6; Authentication-Results: sj-dkim-3; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [lisp] [#16]: Desire to expand data plane for map versioning orhandle in the control plane X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 03 Sep 2009 21:06:37 -0000 >=20 > Darrel said he would ask that question on the list. That hasn't > happened so far, so I'm asking it now. Thanks Sam, apologies to the WG for not doing this. -Darrel From dino@cisco.com Thu Sep 3 18:12: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 73DF63A69F2 for ; Thu, 3 Sep 2009 18:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 GLSYPOzokWgI for ; Thu, 3 Sep 2009 18:11:57 -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 6C9683A69DF for ; Thu, 3 Sep 2009 18:11:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB4FoEqrR7PE/2dsb2JhbADCI4hBAZAoBYQbgV0 X-IronPort-AV: E=Sophos;i="4.44,328,1249257600"; d="scan'208";a="92934176" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 04 Sep 2009 01:09:45 +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 n8419jQT002895; Thu, 3 Sep 2009 18:09:45 -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 n8419fbm008527; Fri, 4 Sep 2009 01:09:45 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); Thu, 3 Sep 2009 18:09:44 -0700 Received: from [192.168.1.4] ([10.21.86.12]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 18:09:43 -0700 Message-Id: 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: Thu, 3 Sep 2009 18:09:43 -0700 References: <20090902225425.834666BE641@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 04 Sep 2009 01:09:44.0223 (UTC) FILETIME=[634382F0:01CA2CFC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8819; t=1252026585; x=1252890585; 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#16=3A=20map=20versioning=20re solution |Sender:=20; bh=eKzEqlqepCd3qkjOL3lO52cqwjXwElCYTZ/xBXV0ueU=; b=JGyuJObxjnWmJE+BfASNezjsAlD7o3VpleovvPBxTVHnexpe8OZ0BymnSr 2GQGjedx5bwz+n/5X3zYftKGCGxrOfYX/SqqTaNUqs1M1Yt209dnTlE9WmZz Xz3+p7JiTl; 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] #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: Fri, 04 Sep 2009 01:12:01 -0000 > I understand everything in your message, but I still don't think it is > necessary or advisable to allocate a "research bit" in the LISP > header. I actually agree. > Dino has proposed defining _three_ new bits to support experimentation > with alternate LISP header field values: the L-bit (which indicates if > the locator status field contains locator status), the N-bit (which > indicates if the nonce field contains a nonce), and the r-bit which > (as of his latest round of edits) indicates nothing all to > implementations of the -04 specification. Right, we wanted to give some flexibility to the research folks. But I agree we shouldn't document something without clear meaning. So I have an idea inspired by your email Margaret: (1) Leave the N and L bit settings as defined in -04. They are used as "field-enable" bits. (2) Don't have an R-bit since we cannot define how to use it or how to ignore it. (3) The E-bit is still used for echo-noncing. Now when the research guys want to use the Nonce and Loc-Status-Bits fields for a new use, all they have to do is set N and L to 0. Implementations which are spec compliant use the N and L fields when the "field-enable" bits are set. Otherwise, they just decap the packet and don't use those fields. How does that sound? Dino > Personally, I find the way the LISP header is defined in Dino's > proposed -04 document to be very awkward and inefficient, as it uses 3 > bits to support one additional (not defined in -04) format. The > complex > dependencies between the three bits results in most of the > combinations of those bits being invalid/meaningless, and > implementations will have to know what to do with those combinations > if they are received. > > If we anticipate that there could be more than one meaning attributed > to the bits in the LISP header, I think that it would be > preferrable to move to a 3-bit "format" field that indicates the > format of the other 61 bits. > > My proposed header (which I believe accomodates the needs you've > described below) would look like this: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Form | LISP Header Fields... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LISP Header Fields (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Form: The format of the LISP header fields in this header. This > document defines three formats: > 0 (000) -- No fields. Remainder of LISP header should be > sent as zero and ignored on receipt. > 1 (001) -- Nonce present format (see below). > 2 (010) -- Locator status bits present format (see below). > > The value 7 (111) is reserved allow extension of the format field. > > ETRs that receive a LISP packet with an unrecognized format should > treat that packet as though it had a format value of 0 (000). The ETR > should ignore the LISP header fields, and process the packet normally. > > [Note: Do we need a format where both the Nonce bits and > the locator status bits are present at the same time? If so, > why?] > > The remainder of the bits in the LISP header are formatted as > indicated in the format field. > > Nonce Present Format: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Form | rsvd bits |E| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Nonce (32-bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Form: LISP header format, as described above. > > E: (As in Dino's -04 proposal) > > Nonce: (As in Dino's -04 proposal) > > [Note: If this nonce is determined to be security sensitive and > needs to be longer than 32-bits, we could expand it to 60 bits by > moving the E bit to the beginning and using the rest of the > LISP header as a nonce.] > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Form | rsvd bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Locator Status Bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Form: LISP header format, as described above. > > Locator Status Bits: (As in Dino's -04 proposal) > > [Note: Similar to above, if we determine that more than 32 > Locator Status Bits would be preferred, we could use the rsvd > bits, as well.] > > If we adopt my proposal, Luigi (or someone else) could > write a specification that defines a new format for these bits > without the need to set aside a per-proposal "R-bit" for that > purpose. Since implementations of this proposal would > ignore unknown formats, it isn't necessary for us to allocate > the new format value in this document, as only the nodes that > understand the new format need to know the format value. > > My proposal allows us to define up to 5 additional LISP header formats > using the same number of bits that Dino's current proposal uses > to support one additional format. > > Margaret > > > > On Sep 2, 2009, at 6:54 PM, Noel Chiappa wrote: > >>> From: Sam Hartman >> >>> I'm not following the reasoning or discussion that lead from where I >>> think we were in Stockholm to a conclusion that map versioning needs >>> research but the other mechanisms do not. >> >> The problem is that we're operating in something of a vacuum, >> operational-data-wise. (Apologies in advance to the degree that any >> of the >> following is teaching of egg-sucking... And I also apologize in >> advance if I >> have mis-understood anything I've heard from various collaborators, >> so if I >> get something wrong, 'just shoot me'... :-) >> >> >> We have what everyone feels has the _potential_ to be a problem - >> i.e. >> outdated mappings. There are also a bunch of ideas on various >> different >> mechanisms to tackle that problem, each of which has plusses and >> minusses >> (complexity, operational overhead, etc). >> >> In the particular case of mapping-versioning, piggybacking it on >> user-data-trafffic has some big advantages (e.g. no extra packet >> traffic), >> but from an _implementation_ point of view, in one of our main >> testbeds >> (Dino's), my understanding is that it has a big downside, which is >> that >> getting the data plane to do anything control-oriented is really >> hard. >> (I got the impression that doing echo-noncing for reachabilty >> detection was >> fairly painful, for instance.) >> >> Which of course shouldn't weigh too heavily on a design decision >> (ask me >> sometime about the variable length IP addresses in IPv3, and the >> number of >> pointer registers available in TENEX at interrupt time - you can >> guess where >> that story goes :-( - unless it's a _typical_ kind of problem for >> high-end >> router boxes (i.e. piggybacking control operations on user-data >> traffic), >> which I get the sense it might be. >> >> Still, when you add to that the concept that a versioning-type >> solution (I >> personally prefer checksums to versions, but that's an engineering >> detail) >> can be incrementally added later, I think that's _part_ of why that >> one is >> still 'on the back burner'. >> >> >> The thing is that without more real-world data on i) how big a >> problem >> outdated mappings are, ii) how expensive various solutions are, >> iii) how well >> those solutions work, etc we're kind of shooting in the dark >> without a >> night-scope. This is also a case where I'm not sure simulation >> would even >> help much, since it depends a lot on other things which we also >> don't have a >> lot of data on, e.g. how often mappings will be changed. >> >> Yeah, people have an 'engineering sense' for a lot of this, but >> intuition is >> not a 100.000% substitute for actual experience. And when you add >> in the fact >> that it's something we can add later without too much pain, I think >> that's >> the thinking behind a position of 'let's add these mechanisms, and >> study that >> other one some more'. >> >> Noel >> >> _______________________________________________ >> 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 dino@cisco.com Thu Sep 3 18: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 EB17F3A6783 for ; Thu, 3 Sep 2009 18:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, DC_IMAGE_SPAM_HTML=0.001, DC_IMAGE_SPAM_TEXT=0.001, DC_PNG_UNO_LARGO=0.558, 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 bkG83t2pA+6A for ; Thu, 3 Sep 2009 18:19:56 -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 38C7C3A6781 for ; Thu, 3 Sep 2009 18:19:56 -0700 (PDT) X-Files: Picture 3.png : 164468 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHAHoEqrR7PD/2dsb2JhbADCKIhBAZAkBYQb X-IronPort-AV: E=Sophos;i="4.44,328,1249257600"; d="png'150?scan'150,208,150";a="92936768" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 04 Sep 2009 01:19:10 +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 n841JBxE028171 for ; Thu, 3 Sep 2009 18:19:11 -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 n841JB5q009397 for ; Fri, 4 Sep 2009 01:19:11 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, 3 Sep 2009 18:19:10 -0700 Received: from [192.168.1.4] ([10.21.86.12]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 18:19:09 -0700 Message-Id: <37DBC15D-8B94-47F0-9AC1-D7CD2E9AB05B@cisco.com> From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-41-989526752 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 3 Sep 2009 18:19:09 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 04 Sep 2009 01:19:10.0280 (UTC) FILETIME=[B4A8F480:01CA2CFD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=226039; t=1252027151; x=1252891151; 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:=20lisp-04=20spec=20and=20lisp-ms-02=20draft |Sender:=20; bh=ioZsubIzs4oGuewvBkgdMEgrgkI+mzTmQO0FX6fXBS0=; b=qWTefHpZLjvJIngElKlVyzDtkEsSRPJY+iAegfgr9+hLXhs+VrzeU5venV fFf3Zto+f5iT1QTeO1EaEEzS9Fyt+mUVeL1OjwcLiqEADLMrIMR9cci4xgUk tMpNtDsibq; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [lisp] lisp-04 spec and lisp-ms-02 draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 04 Sep 2009 01:19:58 -0000 --Apple-Mail-41-989526752 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit How about we extend the deadline to next Friday, Sep 11th for the -04 spec? So we can have time to clear the bit usage issue? If we converge earlier, we can decide to post. As for the lisp-ms-02 document, we made a very small change. See image enclosed below of the text. We have received no comments so we assume there is rough consensus. So we'd like to post tomorrow at end of day PDT. Thanks, Dino/Dave/Darrel/Vince ---- --Apple-Mail-41-989526752 Content-Disposition: inline; filename="Picture 3.png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; x-mac-type=504E4766; name="Picture 3.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAoAAAAEfCAIAAABed+B/AAAABGdBTUEAANkDQtZPoQAADzNpQ0NQ Q29sb3IgTENEAAB4nJWXCThUX//Az52VwVhCQhprhAhZS/Zs2feKmGHsxthFJCLKmqVIlFLJ0o4K ESqprCVF1pAkS3bz3qF+v9//fZ/3eZ//mWfu/dzv/S7nnu+559wvAOwEZwrFGwEA8PENpFoc1CLY 2TsQsD0ACzjgHxpIOhMDKJpmZsbgv7Zf3QCinzuk6b7uDQS9Hks3+dK2vIf9jcLBsv9ut9HwVDgg AJAUzJzkTdags8smW9E5JJASCLM7nYnuziSYI2CWolpZaMN8g+6HvMmVdHbZ5Bd0DiaS6bYfAMBw +JI8fAHATsKsTnINIMK36XFJpACiD8ypACC0fHz8YP9snbBcnEihwrZsqzCL0Mdls8uu/gCo7gGA MetvmSfc13IqALxLf8t2MgHAHQJA2T/0Zi02xgrifhvgJi+3IYKYtQBA99Fos2Jw39IBWEuj0Vau 0GhrVwFAfgKgzpsYRA3+PV4Q1ArA/7refObfDQkHpCdYEFDBJBSD2IuEkGtoEYwn9g2jExOauRv/ nK2e4xPnzFb5bSS+4u0TBEkhqkix2IAEq6Sq9EEZxT3b5bEKU4rtyndVz+6zVxc8MKqZr22hs6Z3 SV/J4JWRvXGnibVpvbmcxQXLFWt7m2o7vL2TQ8XhuaMKjlSn68f6XNiJeqQA10tu9eRRD5ynhJee t6NPsO85vwJKuX8t9V3AQODPYBCCDxUIkw1XPL7t+FREfWTWCf8o/Wih6LWTH2Men8qPjY7zOG0Z fyBB5oxgIncSy1n0Wdq5teT1FFoalI7MwJzHnF/JHMxqyi7JSb8QctEl1zxP/ZJ0vsBltgJUwWLh 5JUvV7uKmq9VX68ovnTj3M2IW94ltrc1SsXLWMvWK8Ad7F2me/j7LA+YHzI9wj6iVc5VjVf3PX73 5NnTiprLtYl1Ic/c6q0bdJ7vbRRt4mlmeYF4sfhy/FVdS8Jr41Z869s3qW9N3+HfvWyLbT/QvtRR 3unWtb2rozvpvdb7xQ+lPS4feT6+7T39af+nuc8Vfa79zP0Xvoh8KR1QGWgatBocGgoaxg7njEiN 1I1ajo5+DRtjHrs8Ljf+fMJyYuhb4CR6MuO74PfyKbWpxh8WP75Me07P/gyfQcycneWeLZgTnyub l5t/8Evm15UFlgW3hZpFpkXdxROLlYs/l0hLfcudq5HrSTQafQaDCAgBpSI0kJzIdbQw5gi2ilEN 186chCeyGXKocmpxO/BE8hbyNwtMCQoIG4mSdsZKnJcMkBbZ/ULWX45Xvn6vhxJe+ZaqltrH/T7q qxoJWizaSbpovYiDXw1sDB8Ycx7yNWkw4zb3tLhruWC93ybYttxuyGHLYZ0jPkdzHRucRp0xLiJE bZKTa6hbMvma+xOPt54DXrM+DL4CfnIUQ/8j1OCA1MDCoIRg15B9oVtD58M6wu8cT4ugRNqcUI0S iEZFT57sjqk7VRKbFRdz2jfeIUH/jFKiaBJHEu3st3NdybUpV1Pj07zTLTKUzu/IxGXOZvVlv8p5 eKHoYlpuVJ73Jft83ctyBTsKcYVz8GxoLbp/Lfd6bLH7DYebbreOlyTcvlhaVFZa/rSi8c7ru2/u td3vfvDhYc+jnsreqg/VPY/7ngw8Ha35UTv/DNSzNPA939Uo07S9aan57Yuil+GvzFskXoPX3a23 35x66/BOpg3Z9r69pCOq07JLtGuuu/b9uQ8OPWI90x8re2M+6X/Gfn7YR+pn76/74jewY6B1MHxI Yuj98KmR3SPdo5FfRb6+HPMdZx+vmDCf+PkteXLXZNN35+8rU2k/xH/UT9tNT/6MmuGYuTGrPts+ 5zL3c/7kL7Zf+QsiC3mLPIsFS3uWOpfTVsirxLXY9VwagWZHS6E1b+SfCxiCCxAE+UPziGTkPhRA 9aI7ML0MgFEKF8LUzCKKT2RdZvfnGOG052rZqsxTxIvjI/PXCDDtMCPkCPYL7xTxFL0pNiTOJ2G6 64RkiVS79C8Zblm5PUZyNvJkBcreEMUIpQjlcJUwVaqa+z7X/SR1twNuGk6aDloW2sY6mrryeoIH 2fSB/pRBj2GDUZlxzqFoEzdTUzNlcxELvMWS5bDVO+samyLbcDtDey77QYc7h6OPmB7lPzrhWO10 5piNs6jznEs9MY10zFXKdcmtiZzm7uQh5bHo2eB1ztvGh8+ny/e0n6xfDyXGX8y/lRoUwBtQG+ga xBhUHmwdvBxSGGoQOhOWG64fPn/8aoRlJCay+oRPlEhUb3TmScsY1pjXpxJjdeJAXM3p4/FK8bMJ 5Wd8Enclfk0qOutyTuBcb3JuikMqX2pvWm66Y4ZgxvD5G5leWQrZiOy2nMsX/C5q5G7JHcl7dCkp 3+WySgF7wURh45XCqzFFpGu613cWMxZ/v9Fxs/pWITzLAksdywzKlSqE77DeBXdn7g3d73nQ+rDh 0aPK+1Ul1dceFzzJfZpTk12bUXfuWWJ9fMPp59GNYU1BzZQXbi/dXoW3ZLwubn34pvrts3fP2ura X3Z0dX7umn3P+8Gw59THF5/kP5f1Gw6gB0eHl7+6TLB+l5n+Op++co2e/829j94wigBk6gFg8xYA i5sApJnAWx0bPEGOAWDGAoCVCkB8EgeIG/MACpD/a//gAXLgEHADJ0AWKANN4DOYg5ghIUgVMoPc oSgoGyqDmqB+aBHBhhBHaCGOIIIRqYgSRBNiEEFD8iGVkdbIQGQG8h6yAzmL4kIpoRxQkairqJeo GTQ/+iA6AH0Z/Rq9hBHH2GLiMZWYcSw/1gx7GvsUO8cgxeDGcIWhj5Gf8TBjHmM/ThjngavALTFp M6UzDTDLMscxf2SRZTnDMozXxBfg11mPsTaxSbOdZwfsFPYBDiuO1i06W2o593FWcalx1XIf5G7f enTrN57IbezbbvJq8/bxRfIL8jdu9xbgEHiyg0zgIjQKBgqJCg0KN4ncFS0US9wZJk6WsN2lIykr RZBmkv61e0Dmley9PXlyp+R9FKz3qikKKeGU5pT7VFpUa9Sa9/XunzoAaWzTlNBS0T6k46RL1Ys7 mKNfZtBo+Nlo5dA2k72mjmZx5hUWH63YrfVt4myf243a0w4TjmgedXfMdKo7Nu0iRiSRilxHyJLu wR6NXtzefj6NfryUQP+WALHA6KD3IbKhZ8KGjlMjhU8MRl+L8Y1VO80VP3+mK6npXGVKedr1jMLM 4uzSC3dyKy81XG4o7C9KLz58i+d2R3n0XYX7/Y8uVFs95aztr3/SmPriRAvlzfG2oM60948/fu5D DhgMF4+d/p41H7SksPx+5ftqz9r19cKN9YMb7AFGG/nPBhXgBfgCFiF2SALShOzhNSURugo9hbqh aQQOIYJQR9gjAuHs30a8RIwiUUghpAbSCRmFzEfWIQdRKNROlCHKD5WFqkP9QO9Am6Nj0Y/Q3zAE jA3mLOY5ZhWriPXHlmEnGXYxeDKUMEwx7mEMZnyKQ+NMcbm4MSZFpgSmXubdzKeZ+1lUWLJY5vHW +EpWXtaTrN/YbNjq2RXYizn4OTK3sG1J4mTmTOLCc2VyC3CXbFXZ+oLnMM/0tjO8wrw1fEf41vkL t+tuHxdI3qG0o4+QJKgg2C+UJOwockBUXAwvNrezT7xZ4v6uPMkEqWBp4m5zGQ1ZmT1CcpzyjAqQ wsLeH4oTSmPK4ypTqnP70Pt51CUPaGjYaXppndS+qHNH97XeiD5ksMPwgJGzccKh2ybdZihzeYtj ltlW7TZMtofsQu1jHTIOlxypOfrJcfUYt7OqyzFiMump6wSZ393CI9Gz3hvyUfcN8btHmaaKB5Dh fbEnhCPUKCwuvD/CJXIhKuXkzpjaWLu4pfjcM2qJA2eTk/elfE8ryLDN3JY1klN28USedb5cAb5w vUj8utON9FuNpVC51p1T9949lKlMf4x4GlaHrT/fqNjc9yq91emdQPtq1+iH572lfVUDTcP9Yynf eqbypr/OdM4FzC8u3N/IvygwBaGgADTDX5EckCJ0BIqGrkEt0E8ED+IAgoxIQVQhhpFsSHWkN/IS 8g0KAb/hvqgbqCG0EJqIvoYew0hjAjCPsWisBbYQO8Ogy5DLMMt4iLEEx4TzxXUy7WO6zczHnMKC YYlmWcdHsyJYE9m2sl1hl2av4jjI8WmLPycT5zUuXa4x7rStaltHebK3GfFCvNV8wfxK/IvbHwtE 7tAhMBG6BS8LeQmbiOwXVRDbtVNIfLsE/67tkgJSO6V371aVMZC130ORS5C/rtCwd1gJp6ygQlTN VVvY76H+RYOkOaJN1YX0svSlDJqMnIyXTVLMxM2fWBpZfbHxs123jzvMcaTAUdmpxZnoQiMVummQ hzwSveS9B32TKCr+IwE5QbrB86E3wo9GoCKLogyjp2LSYxXiPsWfOiOS2HTWK5klpTRNP33g/Iks gezHF6wv/sxLzpe8XF/ofGWlKPO6YnH7TXIJ+vaFMvnyljsedxfvZz6UevS86mj13JOkGvHal8/I DdjnRU2mzUsv81uMWxFvLr3ja8vv2NVZ203+wNBT1ev1Gd9X9sV2YHLIZ3h41PJr1TjnhNm3U5Ol 35um2n50Tjf9fDCTOus9JzX3bT7/l/6vmYWERf7F8iWZpVvLIsv5K4gVt5VXq7tX41fb1vjWXNfK 15bXD61X0cRo6fT8b9ZLGw2n7eftRyUYa+v8j+Lu/9t8vIP+xOCA/8y+Liamv3mMEmhmtbEKAbAc EGypC5/hPQtic/PQM/jNBJKzjhHM/DDLhrtrm9B9wGzsRtWz2LSF7DydDc1gxsPs6+prbbnpH4qg eG/UuHROpgRqWWzseAAqcA3Q/aNTGe5uZfvb9hU1yMJ646sari29/IwsfsdaJbnq/O4bgsHX28R4 My6CxyPQYKOWhXk30APOcDVGBq5AGhgDbaDz+0iA5QSY/OC7riAA1hve0PujZbNx7fFvVtLwqkz3 F7xh4wVGYfZx8oihwr7+r3ci7DkIeMN6QYAqWyI7Lrv6lw49qvdG5D8So/+Q/PHzt64HIMHnf/rf kNOj+9x1C87xC1O1cUeJoeRQe1FaqP0odZQKIKC4UbxAGqWAUkZpog6g1OB7Km8mH03+FWdzfFz+ ek6jP32Gj77/MWbEf/QGbNbvG985cA7yYunUkLkY/e9zLdA1dKNG1vajhFE9yO6BBE0KxdtVimDg S9wtRZCTlVUB/wJX0XpAPL/WlAAAAAlwSFlzAAALEwAACxMBAJqcGAAAACR0RVh0U29mdHdhcmUA UXVpY2tUaW1lIDcuNi4yIChNYWMgT1MgWCkAYDI1PgAAAAd0SU1FB9kJBAERHtODZiUAACAASURB VHic7J0FeFRH9/DvXXeLbnzjLkgMCR5cSrFiFdwLpUALLbS0UIoWt+LuBAIECURIiLt7svHdzbpd +e4GKZJU3vL+0/fr/T1pnzC5M3PmzJk5M3Nn5oIoigI4ODg4ODg4/7cQuloAHBwcHBycfyO4A8bB wcHBwekCcAeMg4ODg4PTBeAOGAcHBwcHpwvAHTAODg4ODk4XgDtgHBwcHBycLgB3wDg4ODg4OF0A 7oBxcHBwcHC6ANwB4+Dg4ODgdAH/nztgfVNRVrm8q6XA+QMgvcEAd132KGrUG4xdJwCKopgCkC7L HwcHp2vowAFD8uainIxnz8ko0/9ufGV97vUzB4+cvVZYr/wvifg30F+ZHdr/VtV/NxMU1alUBgOE AjDeh/4BBkXx0+if1n+1at22uNKm5z7HoKzb0N9j8M4nxq6RCVU2FKwe1G38oadQ1wgAl6demBo+ 8G61umvyx8HB6SI6cMCN2ZcWfjp28JDIoRgDf6zs3APrq69xbEPmXEyNu/bdxLHD7leo/q44iDz2 0BdjevkEhYSamZmzWKzuILj4Yq4459IEVxLD1kYU1k3kbOfm4jRn65Wq/JsDLXl9+3ZnsQVCu4FL v/81s0b5+sXWutJrC5LIt6cHaNvqt80Mdg7sfymhFkUNKed+Dna1m/zDNan6ZZ//H16IjWor78/y Z1ra2pnx2fb+g47F1b32x86v2f5Tuf1O/M5B5He2zX1LgauuF+lldQe/GM20tXENC8IUyPSacDa5 wqgvWWlt5t0rkMnnOwwa/vXea9VSfYdZGuT1F36Y7WAX5OkpYjKdew2Zf+pegUL7zpzxjcjvyq9L ubBj6eJvcuREgkzc2KKCEdMDIJFg34Mfbssn/sWy6mtvYQbQq1cgZgD2okjMAHLFqtey/LMKJFAJ ou78YGvuW43hrdjyskfb9206k978pwV8KwF98s6NO5auK1O+rTc6ke7NYQvIf1UBODg4/9uQ3g3C ugHhxA33JozpbsshU0hg55ERg9rXb+/TG58YK1L2fjXvYV7DYGe3vyUOge4zZGr/W+lZNsFr1q3n M4HkmRNuNBsMTiid3nP3xs+SryajQQHhlg+ilW0Qa/Da7ycO+JxxP3a/vjTpwKp9G8tph499JHgu MaQ8t32V9ZLT4QJMTo5P7wEtJ89EXXzc16fnlWt3C8V+i8MCmTSSRiIuqW0waCEa18zJWcQmw61i sVwPsNgUlaQNpnKsbIQ8BrmT8rf9umRCvM/erMdjmmJPbdoX87zDRSG9tLm2pq5VC2GDBkcvewsK ACkkDTUtGoG5GRVSNTa06hhWzpZksVhNpyqZ1p48UFVXI0FoFLbA0lpA17Y111bXydQGMsPK1cOR RyfqlbK6qgbQzELAILSI69u0BEd3F3M2nfBW9RDogWM+6/+kJNOl35p1Ic8VGNtqJDEFkTNXXwwt OH3iKS3I/4MPQgI9LIlUYMx3H+5fQb0YNabs0dUdm36sytNu3TFZSHt7WEZk8IMjhw/P0NQD3bZu tr56/sz8D37gPdkS6UUpKBWzBNaWPHJLdbXUSLNxchIKaO/IT0Jho0ouTi9tdOjW79MF8xzYdHNz LmZcqF5aUNrSf+mVDyxtCS+0p2msbVHpdBxrOx5RXdWgMEIEB3cRh/y2JVLNgzEDGL2Od/3Bh6rs R0c37Nveyt+2c5wARNRtzdWVNXItRGEIXTzsMQEAFNGrFQ2NTVqAwmPRtDIpzdJBKGDDWklZnWHo ktMCS5uXxUa08taq6ro2NUQXcIlahluAHRnSKSStKrmEoVa2tVGIZDqTTiEQALm4vFoKmFmZkRFF TX0zjWPtaG/DBLX1VXWNcpkBJVs7uDpa8wgIbNC0FqiaM5WU8FaZOUSiMFn09salbhVLyM6fHDtq hZnJC2ClpKlW3KjSQRSKlcjTlksjaNskzQ1SIoepkUuUOoqNk4MVn/l27ePg4PxP0YEDxrxIfW3+ oweEKi7XwtW/V4AzvZOhOd1pXHwyjY0i9ZrWehBlQhDyd98qUyyd/AO72WssPH18XMvK9BN3z4xr osAAk2bef/CwPopsI2LVK9LPkJDPRRnmvfqFAjaa4G5BZDfLlvKCK6ViHTanbe/H1BW31z+12nMl BPudQKY6OPuG01VKQ3pqEq0V1sEB3dwcOBQi/Ozqnk/33ufSQSqNO2Plno/6MqJ3fX08XuzQ21+f laPiOPWMHDN3+mhrVkc+WN+aloEM2x3MBgic4CELCFQdjwog+pq0h+fO7L+fJzVCcJNT8IYZK8f2 ZmY9PLFy+z2PoJ6ujMaUlNwywQc/f2KxftVpAK2afjB5JDXx89m7Wuw8Ji5ZPiOYeOfsyVN3MvV6 g0ZiM3bljAWThigLnv60cEONd48IP2FmQlx+Ebz8wP6P+njQ3x4gUYSu3TAFqu19MQUWFZsUmIE5 DArDyS/cwYGf/FjPce0zfJD/8yoNjgghkYCB/QYOC+3m6bZ7Z8yD9IphI735bxUU8zeO3iE9Qpuy W/2HjQ0f1MOxrOIXuUGjLIuf+9l3dMvQUUNsc27fyDB4TF286rO+lLflnzycqZNmPrx+OT6lVc8R HN/HMPf7ePpIe3OWsSFx7pwN1jb80DmHVw9zwvJCFJUXt++7cPdxxDf7ZvHjRiy7JnAK23l2Z7jl O1VAt8QMgGgLYQZAEnHaGipjmht1RkQhybx+/tyvtzIQyKhusR23avrCKcPoqobHF88cvROrYlm5 mVNzn2QMWbt7xbgQVWXs/LmbMbfZb87uJQPtsVRRg+TOqa2/XE1BYVjFIZbGi5IbDlg05d29H/00 rUCgsSWXsXiisMEhHhwGmnl+28qz1U4hoSJy893Hca69x33++bJAIHfflz89bpABqIodMGn3ztUi QFGSHHs3JTujmeZ27XIem+YRMTzYxYJCBMtjj87ZdFvkELx477ZwW7ppWFebfm7fybMJOShqVDZ5 TN0w6ZMxEZJn0T9/s0/rH4DI6/PSpBGLv/p+XqSA3snQEAcH53+BDhwwhe8YTswsjHtUgsjTcggb L58c58HqODaZySMDBlnljWNnskn994Q6vo89XTBAR0oL0p6AJev3C4oyNp1VEtE2oFckjQ0jEGxE AITq0H0Ew1zAIBtaYKD80aFDIChvKCxqDAodx3peIKjt1sndbuNX9rZ/LjnWlzJs3QbzBMiv+2L8 u4W40a0gFEEBg5FsOWXiCAaFnPM4Iep8/PDBM0MGdD/zoEJM9f965zxKbdyGLz+U8Qu2jHNsrCyX aBFCewkRI8BzEDlY2M6cM+77s/v35rKJZDMHd68IGwYkrzqydVs6KWDJ2gn2XGPs1oi5E9Hw5l0h wz5eWSM7cDDaYdnq9R+vUMuJnj6Wu76M6TuH+IuvrSXs3TNMUG49dGof26zjX28+3TR98fLIQKvG zHPjF02le5Qv6dZ37tqZ2zZvT+LOWvTVVq5OzXUXkjueAZkUWJiTzNenrdxpXpu/6YjqxdQKRrAf 7H/Iq6VRA2xsjwAQaPzgkOC+YnGdTAMAbztgoH09FyI11UjiY+40SCoyUB7bjE3luI28foE7M2BC ov3cBZtPLwMMVB4v7dxP78q/rBvbLSCsl3dqfC01oO8wd2srAYuKSU+x7Xf5guu947Oeyl+8DiBy XScsmlxvbMx+9uAa9ZnQ13PDD18FmXfsaQwwbCh+cOiQEZVWFxc1+g/0ZBHUcUe2bL6unbdqTW93 fn3aiQmLpvI98/u03tp/6E7I6m9HiODLR75Th48fHOJNJoI8t8hzJ51unVtbqnghACKvunLzccCo eRN7e8vybu+EEQYAEolUJlvAYZlzWRwum8Wkk0GT8sndP96wxXLnuGWPFnyx7NSZ2UYjYGNGNzYR nPr1G2Wk0BnVe9f8/HTpEmdnbAjEsaAzrehktikBMoNCANtrzzNywRFB4LWN29ug9lfikOzOoS1R 2c5f/Xy8ty+3Kun6suVzCPbP5gf19OzjeU9s8dW6lez8X2Yfz2icFMGnv7MsgIOD879DBw6Y59J3 2bq+HA6LBDduDfM6k1Q7zsPL9AcEUiuVGpiAdSBU4gtXqxbn7j24P1tsvvjL5UE2jFeJGNRymdrI MTOjE/96F4H1YkJHTz+PKf0JcGNxgdI5wttv5moAkhY+9xxct37j25e6Ndh821xaVZRfX5hcg9p8 Oj6C0y6XvCz2bKLNvJ9D2OQXBUQAkCl09rWjlyTWOroEWBfW6fRQW+mjSzE1HDtlg4okg0AUVRpQ Cs+MwxT2mTVyWF9/e6K/75qkbz+5kbN2ID3u0snkJpjS7sv0cmLY9M+sw2x4/eetDxNnpCeWVuVl p6RItA6f9WkrVcM0O1JTeUELmULzHD+KxkNRAo3D45vZ9uz/4ayPp4nYL5YUrCdsGrHb90p2nSW/ okZl/sGMEdYs7e1yDZHKQxXizPQWMmg7atRIo0pNptiaCyz8gyP8F84f4tGBg3xLgXZ2Ik8/2+kD iJgCSzQuvfhULBhs/3md1wZMCGRAdVoaQOh0EEVQyxtLS1NSW9skqg8+/qi7kyWZRhM62PAFfgu/ 39TXql01UENSR/ITKWZCV9+ezo5qlBQUHOrJf2l4ZLZQaG/FF/2WDZFq49Fn1YKWvuOXrCwTb0+o G+Bj26lIAAHhSzADqMpJaCQ5zBsRxgFkFaVaTABYUp2ZLqYQnDABDG3SRkml3tNpwqh+bnSAVnO6 sNKMTTN5L5DCEVrbW3AdSl/lz7Tq16t/mrjgXkwzG9XZ2BPUetDJ3n9YZGQ9kSPsPfrDQItXArDN LG2sbez8P/py1Vjec80ZpRcuJ1Y3NchUCNFSZdUeRmJwPEL7DU5KJJeTho6f8FvxsSEIx1JoJxRY Ai8qRy9LKVeHTB0SEiRiU0G/wVPHuayLK5csD2TxbPyDrIJC/dzInEju9grYgH/JGwfnf5t3HbBR KVdqEQqDRdfLZDUoSnnhLFB5Xfalo7sfS7w/nTU9IlCIBWtqUpZ98dXZattj27/wJdQ+zSOG+prC AVh6ffeu6JwK74+/+XLIX3srjBh1Go2BZWvp4t137Tq07PyYX8j7IrwFCOb+tVq9QYcYtRqDEfOs BBBVKWQAMHztpkXKnNs//nTwztUkr9l9+BTtg1NX2N2HhblZkdr7RBRBtNo2NWjwHzAtMNTIQisv Hs0VSxRW4ku7z9FTa36y1Ved2789RqzT641khISiuXE5mT6uDEJz3qEnQLfhtnQGx7fPIL4aILUr DNIRnUQWZKjx8PrNfX7es3DNeE191sGt+8rKJGAkj0RlUPjWgWG9+VS41ZEBM3QkEDFq1HI1YCCw UaNGo6HQaBQCNoXief389fSQDStaXAjUoI8HuPIwhyLgUxgOXHvfbmGOXK20gaQDuEI6YtSrWlWg ikQlImqNlkqlkogde0oY04/GwLW1xhT43XdI2YWxh5gHe7lzDQadSqXF/q8zaJQqLYdOJRIJGrUO RQGlVqMSF9y6eK2qyXKAHaejVFHYoNdoee4evadjGmYyOSw6kQAieq2mTS4HLamgQaMymgpOpHYg vw0DRbF6U7epNVItCas1NZVNp1EJBFSjUhohrUqrhjXY4E5NIlJoFFAuzj946ob3yJnT6DXnfvrK ae33I4IdKB1IhWBJUWmj126a3fLs4vZfTt+/leYy1c2cT2Y4CBz9uvsLWRpJPVEHmtnxhURnVt2T s0eu9nEzPLiZJ3cIbx8ZIhqVSqdVqzEBtEqlWk0mU4gaSauRFx7azdPRDJClXtuyJmvZOh8eGUEB uVRBbJW2ydHqnIwWpme/AHuDXo+JDSA0g0ajJZGoVAqorj935Zpo5NJ1Uwaryx/N3HJFp1bBADbm IrIBCqBWyZUKqVaW/azYKqyvtyVZpTJodCoNBKvkKo0GpBAZTkTqvaTsob2DutuxGgsf3a0jBFlz jFjFqYwomYrCqFajhSGNFjJt8sJnwDg4/7sQ169f/2aIvjDm5C+/7Lt4887Na5drLSO/mDPOkWvq /ZT1JeeP7Po1Gw4f0D9IJCAAUNa5H+dvuQRQWPrqlHuPU2Hrbr18rE1uAW27v3vj0Wt3LCJmjA6y +QvioOqsaxcOHDobm1+ckpjw6MHdm7eiWWELJnTj1eXHb1v1w83k5ILi9EYC08vVmabIXLx6a05m TpuKN2RKpDVUGX3quprjYseo3ru7sN/ksaG+tiTTOiGiasw/sPK7O4X1Zm59hvS1v3ry6JXo+6VG 1xG9bXKOX81szIp//FCi1dYVliJ0J2czxYPbV2olzQkP79+4dMHgNvmrpR+KzLnWTq7u7q7Pcfd0 tuQxCMaGgyvXXc/OT42LuRn1pEZuOXrGcH9nIYeiLY9PiHv6NCEx7mFMNcfVM9CD9vjQ8l3nnmQV 5aanPc2WkjzdXUw7gwBQ4OhdcOTzuCrRqk3Lfc2oAEjicWmtFY8T4p8mJyY9enRfS7f36xHUlndz 7Y8HE7MKMnLSH96tMnMUOdi+vWv3uQJTz5w4fOxSbG5hSvyT5wrk91k0zAV4eG7rxl/OJj5LLi5N e/a0wsLD3V6gOrTsu7sF6eVliTExsY2A/YgJUyP8bCnvpGtUtSZe27312K3yyvyCFqONk4vImg0C UMbZhWt2RCXnZBeVZCdnlxJsfD2sOe/K7x8abo02P7qwa+vx27ml5XlZqTG52oAANwFNeuiTRftu 3X7wJKUgJz89PqVZTbOm1x3bs3X7sVvBH3+9rC9j+cofS+sk1v4RXlb0t6TSNyQtXrM9KyNPImcP nzbEGq65fiJKzXbt3ctNWZsQ+xgT4GnswxhMgKDwPl6ONhxAV1JQJJbK1G1FKrPgocH+AnLz3k8X 7b8VHRufkp+dlxqXqkA4zpaqvXuOxaXllBXlZmTlGnkhH04fbcvExhvG+uTk26cv3X10JyGrjucS GOig2/PZ0qMxjwtysgsLE4pqWxx9ugnoQFt5UuLT1LiHD66XS4ia2uziavvACBdzJglSJafEXboV HRN1vVJK8gkNNlM8/Wzxhtv3YuIzCzJz859kVdNsvCK8rKvTLt6Mjrl7O/rKxQvCQUvmjw2RFyT8 uuXA02bAxUtYfO3ctZiYXDOP0T1FtE7GYTg4OP98wHeOasBycXlBSXmr0oCQaCLvbj5OFs/nwJBW WVlaXKejeXq6WnNoIIBIK/NyqqXPoxGpTDsXLydLlmlIjhqbSrKLxHJ7v1BnC+ZfkQeSVFWWV4k1 rwXZePZ0t6arZU1F2cXPzxqzrZ08ne1psDQpvQiCYCrNLjDYBVA2VhZXkyycueq862lw/yFhbjbt wmDSaGSFKTlSgGpl5+ziyK4oKWlsaQPYjj08ebWpGeUqLZ0tEAr5WomcYe7IkkQv+SVz3IdjXayo RiPs6NnN0ZrTyWRTkXw3XkGlGlVqiMC0dXTz8rZnkgmQVl5dXFJW3wwTqQyqhYuPyJIDNJRkVEle xGNYOXk727Ooz/WK1GTdL5XbhffxoT/PBjG01BQWV9S36VE6nWHn5Olga66VVOcU1b7MWODu42Jt wexIKqi5rKyqrvF1Bdp5BTsLCPWVBWX1ipdhHI8ADysuUPw0owkynYohkmnmNk5O9lbv7Opql8io a64pLKptv9KEbunu5iQUMDADaC17mlf34vQsmcWzd/F04NM6kN/OioJoGqqKfxOAaRPkK+JSjYVx KU2/5UOxtHV0sCBUVVa3ynVCjwAnhjops4xIpjp4dXMUUN9Wv6YpKaMEglAqzSYoxBlVNJUX1VAs RSJ7bltdUUGZWGkEngvgaG9FIwJ6jaK1uVUPAIXnVh80DNm6YJq7GVIQl/rauSKq0FEkElLy80vb FCpIb4BQopWLr4+rDZVgqhdZbVVxSY0CILDNhM4uTpZsOD8urfWVTs2sXD08OBRA3lCeX1wp1aKY TdiByiYlJPLpbsulQDplVUVphbgVJJKE9q7OjrZUY1N8aslv+dMFzq6u9jxiS3VeUUWTQodQ6Czf biE2fKqiRVyaX66kmbu42CJNNXWtMqOVe7iHkILvhMbB+Z/lXQdsAkVMoCDh7XXO58/+qSZvShgE u6B3gHVqNUxg0GikP/X6GYVhBCQQn/djqLbpzIbV64/c8xw5ImLkrCVjelLJvzPDQGEIBolELAkU IBBJr/eFpmSBV+n+gQgIJgLxTWlNVQCgBMJ/8Ar9H0GXy29SKgC8JgBcm3Ft39EjdwtQVUnNhB/3 rpgYYdbJ/n7MdjHLRRGTCRPerMHn7eUPDbu9+ACxgxfqpr1/4J9oGCb50Xb5/0ctAAcH54/o2AH/ a0F00vTkpKLKZpiA8FzCR4R5kPElvv9PQOVNlekpz6qVFJGHX5C3iINvIcbBwelScAeMg4ODg4PT BeDTOxwcHBwcnC4Ad8A4ODg4ODhdAO6AcXBwcHBwugDcAePg4ODg4HQBuAPGwcHBwcHpAnAHjIOD g4OD0wXgDhgHBwcHB6cLwB0wDg4ODg5OF4A7YBwcHBwcnC4Ad8A4ODg4ODhdAO6AcXBwcHBwugDc AePg4ODg4HQBuAN+D6BoF3/SossF6Gr+7eXH+UeCmyXOH4A74DeB9dImcY24RWeA3whHYU1bc1V5 eVVNg1ytf71VIZC+8tmTtJq232lqMKSXiKvrGlq10PtvkJgA5SkJvy/A/y+gBq2qua6moqyiXqI0 fS/XFIYomkqepRVrka6W7l/Aiy+F/1Mci7GltrKqpknf5VWPQKq2psqK6haZEn6pGoOi+v79NCX8 uxH/q0LBMGJqI/+QysLpANJ7T1HfVpf0LF1pwFy7ecigYMtOvnneMaihoTgrv6Jeg5AUbW0QBAkA wLrfGF+uPOXR4yoDlclhAhoNABDtvIP9bMC4O3FEM05Dg5xCs3DzdXd3deTS/kp274DoJAmnD94o 5i5a/UmAs+DV8ASFdLX5iVduxdfozYeMnTi6r+srxUG6lmvfTEoYc+3SwvDOtKlXSp6cP5SiMP9o 0UJ/C8rfkfBdMAEurJ+ZNvL0KwEQdWNMrKxbuMhSQPurqemktU+fFSrVOpVOYYQgLMTSI6x/qDuo EGcmPqhWMDkchkql4Ln06OXr0JL98LGMKGhuBvlmAqGLh4ezOYv8fkv3OkZlY1z05bj0Cp0Rtgqb MGd0GJtGQmBDwf1jiw6RLsRsdPnLxf0rKBsAcStg4QaY/Vez+Zugsuq8pIx8tnNosI8DlYRWpsY+ q1b6hQ3ysWX/rYRhfWNpVmp6bqMaIJEJVv79+vs70cldO4KXx1/ccynfcuO+Vf/dqv8jEKO6Ojv2 wNkU1z7DZ04exGtvh9Kcq5GRcZnq64GMv5s+CmmrSnOe5dUwGAS1gu4fGuLhZEZq/5x1a1HCrbQq CpfDgPVtOpp/j2BfFyuyQZafGJtS1gKDZDqL4RoyrIc1UpSTUyyWI4hGrSbZOIl8A3yEPBqIfxO7 S3n/DtgoFz+9e+58TJZMYbb2woW54Xav/RHFxmQgCBIInbVbQ0NpyoWtR0sotgwakUyEkRu3OSez NvsWH1jzRYNHT71KBxjIVrQG7oDVGz50vHfspzvVtu5+XLKOSCOZD545f+oHXtS/ITxIYZlRdIWF koY2bcDr4QSymYNnrzBJwfmykhIV2ve3PxEprLBP5jq7OrxZJBQ2QiCJRGg3cDKNZW5hqU1PlepN g1KTAl6zexQyQChIIr/xfXgUhhCAQCQSkD9apsAE6DvzU28Xh1dDD6StYNN3hZsPTbIQ0N5Is33+ AoJEkNBpu9NJa24f/jm6FraxYNKwx4ytpYaiO/d+5LU1Prt3KbZY1qoBQSo3fAI/wE1YlXj+k/3J k929aGxSSwuh//RpMyaMtGD8R2Mgk3AoQPhNM7DRCKNECuW30qvq0u88uaOxHTrU25xkbUZqfxQE SVYe/T6aQBX8CdePFR+GUCKJ8GYFmKYKBBLpD/qihnzgwTMgfE4HDhjBpjkg0KlV/wZsygolYfX6 Rg1gEhghlEAh/UF7xHQEwyiB+Kb8b6KoTP35u++UwvnnTyxy5TT/8uXnF2sdd1zo1e6ATUU1aZnY efxOclbUF1w6uP1+idHCkpz28InllJ093OzoZNNoEpsPY+IDmAY7UiFshAlk4u9mh6KQEcasvaP4 zwvcSXy6e3eXkt0Jur/nRUym15EBvGuB7U+3tyGs/l57GiRSrRyduYTUmgKx8eV8ky7ssWyZnfXb 420UgpD2+v8LQqNGbU3Rs+M7TuuIKJkXMtfG1dXxhQOWlCReOP9EjeqUTYCFiycqcPBwNhPHndy8 JQp1dGXp625HZ07YExA4mJabcGPr8VQyl8mjUxUQMTDkk/XfDrNkvH8XgPPnef/aZwh9pk0aeS3T EGBff2Djw8nRMzmwXpyXeC2q1MyBXFecVccLmDJhbM+XBvQGIN2997j+N+6bOQ4YOy6SAutLqCVr mwyQB4nOi1i3bs7Do/GoRY9Ix5j9zbCR5bFo+Ye/zCLc3PEx2lhwYuO+m9fjRo72snynTLBenXb/ +qNiQnc/TmlWhpYjGjQ00seOknR2xzVlz6/mDtUVPthzLil4wOjB/bu59PSwionLTbxXfr1Ca+Ed OW5EgB0X83Lm9l692eD9ezpQBbwSHGpJ/3LTGXuRa8/uzFfNVN1S8eD8lYTiagOJZAuCvVduDrdh ufp60qMv7z20+4pc7BU+fOLwfuZsbKigzo45fywqA0LpTl6DPpzS30lARfVtWbFnop4UtqgIdnYE qu+CJSPcO+vaoeaULzefd3Tz7s5ltkuFKlsaKgsKlOrqkpI8OsIBKWZevo4UxNhYmhh982pWDcrj E5nukZOGRjiZdzAyZ9n6TBjukV9iu3j8KDvQQKFVjun7rdq42d7Ke8KyHWF51/c9EneLmDQ62IvP YASOmeS2PHn6jW2Oyup7xw7eP3vEwqPn9FCbtyoWRQy1mbFRt9LN/b3h070dhAAAIABJREFUxvK6 NmrQgMjeQc50guziyh/SHIOmjAxrTY2OSmrwDRs0ftwAHix5Gn3iTnKVXEekhI3/emJfc5KxpSb/ 8qWo+Aoo2IVvRAROQisyiQgg0hvbvk8kM8N6zmA99/uIMuXcxRyxWO8WOSnC/O73VxT2UqchK4Z5 sqqyH0VF3ytpRAmuwdMnjA6y5WIW2FSYcO7gxQoIoZPJvt169R0z1pHzjgGhMKBoAvIygfI8wCwX IPABni1gaw5g8z9EDlw9C8QVAAAf8B8ITAwFOB2PAGGDoqjizu2qxGoYsaQHj/Uf5WPGzk87GKMC GSCi1hTKyO6RHh/2drDtuE2i+oay9GtXowtr5QQL7/ETxoZ7WpM6cKOg0D840Mr20J3jaXVTrcF7 p+LKrIYt7uNlpmquenAnKjatBAHA3mNnjugVQNMUHfz+KCV4gD2tNSe91jZ44MCIHtbcjuRH9JW5 KalVwJgvt08MoMbsXXeeQHvuaLRNhZdPH0ipgAEL59BhY8b1cCFKCw+cuKKmu34wKrDo/MGH9VSr oKG9zFtiE8ucu3mE9ggouBvfrGquoPutmDXYnKhMvnX+4sM8GOD5Bg8dMyZEyNQlHjsd3YxGjh8h qH54OCqHbxM0c9F0EfvdgR3TNzxcpD+c+vBabF66zrrHqIERTmzlrVMPxLJiXt/PJvfi3dp+vJ5N N/MYPrG/S4cDQ8wAzhy4WAUjTDLZu1uvAePG2bKIsLL+SdSxqOR6A0yyGDR1yYhgsrT80cO7ZTom LG2sq20IGjxxwpAQFpUEQ4rsB9HRsQVUDy+AznypLkX8yX3RzU2uEdP47dWJGJTZj2OTciR8rrys rKLVMWLehEhPCxZoWjKseXgr6mmVyi8oAKwpMlp4DR46wPLNlSQCld2t7wcLC+uSKhVhs5aEedm9 Wnpw6PXRDqd+SXduXEtx+WFjf2sLSxosu/HrOV33edtXT7KA6uzAuY0AQOEK+48Y+jiFynUP/3iS MCnmwsrvz037fCDugLuW97+CRKBQ1fUlovDI5WsW6xMOJNbpsEkKACszYvafuBwFMzmt8bfvPHzW qoE6ik1k8S1tRBwDpGwV5+y9WB2+7scl3awQgE5h9vRyd7TgC83MRa7u3kJLPonGshPZAFoa34xv YW1j5cZGUA3S0esOLH+DrPLeoW/2nbhYr9LXpJz/cfWe9HI5kajfufFkgwEgkwjKxqpL15/KYcxb kFFJztG4rBYiVVX+cNmCOQk16ufpINhQGX3jdRM2M7YQMOvS99zMl74M06SdOvEwQ+zg4+9iTY7Z uTOjRWcKJiONckltg4JPM9w6czWpUGxA9KnHlyzbm8x19vH1FFakXthz+Nd6DdpWEX/oYqae5eLn bd+SfnDXzTxD59p+LkBl+qGXAiCS2tLEpGcSee6zZ08ePLwT/SRHhQAGVUv83at386lefh4URdq5 24/KW1QdvhnCRjr2ri5UCJK31Fw7cAdwCl337TwbKjaJZ9iK3F0cXKwcXURuniIbPoVE4Nk52AF2 diJXn579P1mxqKezMPtZifqddLFeBtJKUu8c/ebAqZgaubIle/+2tVeSi7UwSLekF5xY/+Wab69k tJIJcFurTKttfXBk39mYEpa9R6CPjezeyjVfPlBiHkCrUKhgjQFsaqoT19fLNQZTTYBEOlegr846 ebMYeqkREh3KvHZp++mkZlnt+p2bzxfqqARYnB13dOepasjC29eFVntzy+qTBTVyFJBeXbkuh2Dn 7+cONpc9ufuoXt2RWSJGoLEUSEoG8gqApMfA/XtAbjWgx57UALvnANvSARsnwJIAxPwKnLkCKIwd JaBIKb289NG6iwWPqqsyz6RvW3ZnR6ZMVlsevTlp447U3fHlmbfTN58quNKk6+R9Jmxoa26WaQg2 Ijuw7Oq2uwkSbYctCKBwuEKqy8AwMCEjP+F2bMAHA4k2fC4D1MilLc0yjo29NUPx686bebVtAJHQ mnXlu00/7kiq1kPSh1d27zt9uUbekbmBIBEgGmTS6vKSmmZD0JjPFo7uzqGTAHXF3sUr4+vp7n7e 1kDp7d07b9+vMBDIAiYUf2TX5wuXJMkoLKqutb5VpylNvn0s9mkDQqagypwTv0a1aY1kUB93cMH3 Z/PMXX08nZgpMUd+vXSj1QBSeDRxzOFvP1+49W41m89QNDTIDZ28x0QQnazi+K44NUqoSr6zdtuv MWUSvST1xK8HKqRqFKWqqu/+sueGprMpNCDBDKCI6oAZgKEmHzOAJqxf0rdc3fLT+Sd1dh7+gT7W FVfXbdjwWEMAVdW5V349m1Zj4FMVJ/eezWlQIqgu/sC8bzbdU5PIktynD248VgEkU5eKzYg5Zoy2 4o0H0o0v9AfC6urH13bdTMyicFklZw/eTi42ml4Xt11c+MWOO0WIUR5/+8zWczFlCtMKx9tiEshs M6GDo4WVjcDZTWTOYbx6gm5m7+7ubGMl5HCcPNycLXgsIoFIhcDW+qry4rIGNWvS8m+mhtgQyDRz oYOFi4OlyMnTr8eUcQPZzCYt1HUvqHHa+S8Mf7QNJ+9lwlZWdLYwBMj7/GxK5Jd9BHbu3v091eYz 584MLxOu3i8ubpT3tWayOoqPAiRU0dgkrlJHneZt/375HDcQ1bNW7PDnIwrItICGCgLHL/OkCrlU qIkIyPaPibwBGjQ8S9tZa8YIOioQgUwXefqHeXHoo2bNHuSNyDJ/mrM5LnfErMHjghpXGxCipWvw 1HHNZy7UtftvzCgDPhkzZeZIb7Kqkb/ac+2vs++vH9ThAieR77Vo4aK4w8lXX9sHotOVZGdpeO6Y l3Lvu3hVkJVpxRI1Ai42noPmLhjtLN88/6BcooSM9ad/vPSY/tlntmagTkUiNV68db975MRBiKas NN+Oh/W0bqLu8xb5+P3O2ipR4Ltooc3dwzl3XwhAsHL1GzZ0yLGkykFDRwS6chECBxtmozDcWl9b WgmG9/axcB32Ubduzu2j7w5BAaJKIRM3lafeTh66c/XEebMpL7WK6Qc1/feyN2wfjrSvvxI4Vvb2 9uZpzfVYD/b2i2BslODk6esXIDOOWL54lBBUPTw0a+f52F6+Hw9e+nlFzM6nQSMXfzRQyCIiAIms LLj68F4NNzyQzWOyLJ01KQfjj3+xeaBI1G3C2MYWTp5T+LiJvuYMDrd9EsDpN3WRxX3KskMv3R7I 8Bs2+QuhDbRo6/ypJ6wXb9i5fLKnAIi/cD8qp2ZUUCSPRxMSWi7FHC9cNNzHgSeXJSUnhwT7eDiG DHDji4SsDg2IAtj6AZHDAEYm0GMM4MMDWOYA5n5UhcDGi8CBQmCYE4CogSsHgMQEoM8QwNf8rQR0 6ob0gvM1oMvn/b+OFJqlpG39IufIjaoPlvefG1AyqcF+5cYwn7MJq9IURRI9ZEvrYJcApnYQgapK 83IqxZrG0or6rNZpwyyZ5A4qEUU0qMOYGb4XDm5YKg7beNDu+7OQqepAGFHWZiXnNjXLikobqlo/ 6eniNmKc974tAavnzfXngkWxR3dH37nvEzaYW5ecV6M1rbSarAFFmCFjR7mEDJn5sfJ23N7FJ8Qa I23I3A3dnK31xQ+2RcWO+Xos5hLIclCWeyM1t/+AAWMmTJvwbP9ZxtDl8yYM5pMMWiOFTfAszixM 1qopbHMzoNFiwIilU/rygbrjG6+luy+bJjQDNKhOXX4qKi40YnDfUeOH3dpxjBW2aN6n7tYMrUrP 5nb6XoPAZU/7ctG47gJlefJ32y4nPvNa/MmMlNvxCrkO60ogSZnl6J3jQ+w7mWqgmAGkpoZ383B1 7h1JM3exZJI0jfkn7twFgyb2ZrNIVJ5563fROU5L1+4O8PAdKCaGzp3bV1hfO/qXNrUeVdXu2HYr fHvi7P4OcEMe1KJWAO1dCMgIGjHdxcHwzW7dC6skMx3dRXZ9u3OD584b5NENGnGouMwwJBAQx22L TfriduJwB1pF8nEtq9jJz1/Q8UYWrNVhTQ15vgHO2FZTpmR52Que/w0xBb6cfRC5H677QX/9/q8/ fVJQQxRY2874ame4MxfFLEibHHX1sTgDKikosx8wxZX7nvej4PxV3r8Dlpaml5ayKOqKqMvN3KGh JVuPly7u64QNinkWziJPAYdrK3IDWrkQ3PnWPC3g6d1z4KgIZ2e9Mu3Moca+K0c7uwcCsEwBErAO wbScIuKaHtQBEOA2Yee2UVm39x9KkFvYW1M69CogNtYn8+hmjt4+QnMBYO7nzgVlOh2RxuNhKiAB BBKFxaCyXiwIYE7FOsDO3orHJfK4vX3cdia3YL07uf2vbzdjApnBYDKo3NeCaD7DPpsrKGloU7aI 1ZlXz93ympAyPwhEAB6NYWNtxuEgXCqViDUxVNfaDPT8zIdPJWpBbu/BM4NH8rvb0Dlg0IKFs+vE LdKm2oaCmw8vW00attqus/6nXQA69dX+GpDOEQithTRFi6WVvUhk+VwfCIPXZ9QMo3UFJKuvFic+ Ti5zd/OyN3fquPohvdDdO6LfsP4nujuCFQdWP528faZVuwAEAOhAwe1/MqgUykYNm2/N7CBRkEAk UvgMO56Lh40FFbAI9PGQxrdq9QhNQKcZKUNGjfRx4jx/VFGqajPwnLEpNpsOEkDviYd+muRoRgEp BBafz2UzGXyumaXlKw8HUulYBdAB3W95kelcUaCfi7HpfEaxe4i5s5MFWdWkUumpPCeRLZdKQOyD P/3Gjx7oag6CrMiV22mliLK5QVJRmtRcqnXruSjU9l3xgaIKYMkmQKkBLsSZXO9zYDXQCgDrJgMb 2z2VQgrINcCTOODAbqB//9cTQGCjQS/nMv3crPydrTlavg2dqJRp9AJzkZBAdhEN87Nju9j5pUk7 MLHnCTTkx/965gyhz0ebFgpbko9984SMdrja81wuQG3tO2piWNxj+ynBwkyovLyxufLBsSMJYocF X81g6iuWfnELJcCYqmg0mObuEewsZAKAm7sX80axpEHS2JSVGJujAk1LR1ivDRqFXkOHtCjaKNbB K74dqVGoxRmXVv2SPnlgMF/eLCe4+rqa04hGknPvaV+GiwICGGQiDaRAoF/kqCEiS1PT4JlKwBg0 IPTprayYtISUREK/6REiKy4IV8tkxKDe7jwKUUewHvXh/FECBw9zOpmKkvSEfhNG9XC3waJyOJ0V 1ASJ5h4U4mLGAnhO9jZsokahZVgPmrV83MQfbgziZ/70xH/3lmE8amfth99uADBmAM2F+SnycrJv 6GiaUgpZhbnYsGkUiEAInbknhObMpxKMZLKFOdfKks/mqHkkEoEIwIraRClxSZivBQ8EKE52zjaF EAI+N0IqjcVmAirFKxsiYcNQC1sbO0cumyvy9NVVm9bwEY20kURyETkIeIDOylLAriCRO3qx0A7B 1NReNMHaR0tm1S9IXDTk+Z/eKB4kTy+GBk/6dNTkKUoNknZ16+Hvkz+840ABEILBztXFIXK04/AJ LCdXLzsW7oC7mPfsgBG9NOHoTZqd+7JvF/nYsIC2jFKb/ntuLdvYG6xrldY7qA2AQWnQlUnkMoNp s8K7lgbplG1arBGpEIAWHMxO+GHBLbuklaadCwapTK5UK2CtXKbWmdGpRALS1NgMVLCtvHpOseU0 lS7asfa0aPcMe24HGyJBCtBQlZOw9ZDjqtG6tAtnCuXTLAUUEokNxF+7m2sTAsRFX8/Ve6k1GqBN rVGfO3PXTugwilb9cOD3FUsvhdNRWKtRtjVLVEopqpY3N0lYHA6LTlBKW3VGXZNCYqS2tMgEFAqD TVVc2n+omB++fPlsBy4oqtsw+2mVfq6frrWtpVSnkKsgpqpQJyFKFDDo2t0LvKghefcZak3R5yXc TSopkQSGMqujDz1u/fiz2SP9rOofSY5+lCzXAXbMd8uEAbe1tuhhfatc2i6AGYVCZzPpBDIVhE6k VvXwFRpynlyJrfdeNMUpNuZ8smDurgXhUJlzavL5ljY50uH+LkTX1iZBFCQURhyDfUgtzy6dOR6x aaY52ahSyiVySVVrk6OkuVXJ5DGpcItECkjbGqXNaO3x/T9fLDH+sD2Q2WH3gVJQVX1c5v7L4fxA StUXvzz1GbbeggG2tda35KLsthaZBCLTGSwGjWlhR+NACpQV2HeIPctQkhJ9/kp+2NjBXFAlkTdX tDUT27BqB7k8Lp1ChtTyFpWuvrlFb2Q3tch4pgqgQ5KSI3OW7Oy2NOFmz10eEb5N8sR9k7h2tnqg hi/qPsSH31qeevZYamOY1pVdu37ud8GH7i0Z6i7Jvdq050xTtQwOte2gtw4MBI5tAc7cBrpPB4JZ QNQVwGwgMNoOsPQGus8AvpsI6CqBX7YAckfg6zWAu+VbsSk0rpmVT2Zy9PaHglors+PFFyt01qF2 FkkPdl5GDE75527QPJ8WZ+brhIk1JS6+3u/qUNemIMh0IYEBXtbKtHtFympji1KPWrHf3cqjUyrb 9M31cvKkH85PpTJKrp42qBpq6iObxW0gbaifh6g46ppW1tzSqmg/TmQpy//up/MeMwJoF45fzTMI JgW5dHP29xv12gAZJVApxmfxjw+fypj244/D/OzRckDF1KME1NwtCAW2Ihy3Af2cdc3FD27EV1e0 eDgL9dLWFkgrk7W1UbQEtgWHiTkOikePwa5RsStGj/OY9O3int4MEgiQLAI9gZMIOyBiGB9UpD+4 mV1bJff344PK1gKjWipta21FyHQBt2Prx1A1tzTJ8mdvOX/m0x51jy48yWsaNsiVSaZ4j5/zydGI 6dMaxuxIGWhH7yw6oM/DDKDPsQfzBro0pRxrPXqrWSxnhDuQGQoFwAsbOopLUGY8jLqfUBQaGaxp VDSVazRqrZEgzTK0BrW0ga7ek3X6ed//GrU6Upl9OebKObPI1XqDEYYNUo1R3tBs2lXa2maGAnQB R6tV1UqkJKPOCOhken1xi0yDoFbuw+faLJzRe+ai+d6Zt46mUwf0Gdth84GNujaZSiFTK9tkzRIi VVxbTtSaXhZg4S2tWMNUaHRtTa1tFkwmHVQ+PPCdcvCizcsnuFC0RdcVbUwIQBG1SqlQkoRenoE9 eghYNArpbx0YwXk/oO8TqOjmz0NdTMn2WnWiQlKxhmcau/ItBMt+Won94j34w7M3Tn08wg/7ffGh KLkefjsBWBr1zSL3NyWc82s+imhy7x0KehkSNHN9rlipKrnEZZu2Edk4LivR60sSDk30cpi75lyT /l3BYHFW9Lqx7qMiBvljEezDvzz2SKY1YgLH7ZqGBdBZdJcgTG73KVPXTpk6EAtxcQHo7c122bFk CEW1rRU75we/LtXiQ9FyRcEc7utHO8wnL9hTp246OH2M/W+BY66XKCQViat6Yb87TFu07/auBb2t sd8Hn3tWBWGd35gXz9m7B24587BFC9c/OTLAT/gq/pozqVBn+tYVTXtDVdaYAA2m4qse71nkZPF8 hX/Mr/eLlM0VO2f9Jv+oxVuKGuQdJtmUfG5MsMPriXJ6baiFTAqc6fVbYNDiQ6XNLWc+ejX15/qF fRWTU9+ZpCpxLqZAT087f38R9vT4xVsqJWpl0ZnX8rEbP+NsS7tFyMrjF3TzfPl+ov/O6ykqvezK oS9fexhzmrl6BH2wptfrokZ8NO9pfvqM8f1M/xjxc1lLwRzsFxLDb/Ylmbzh/LrP3F486PXp2pPl UhWiy5/4W2zhiBn78ls6sJ4XaBvRjYtNxyqxn15T0bhSbIyCSnPQwcCLwAHj0KKWTjXQVnng8kTR egDAfjYO2ZmRrzYqju0y/dNqi83Cs3O9TH/yXBF3t7Wj+lY1FG1ZOq5dTrcpUz4SiWyAwT/Xqt6R 1vjK/EbcLWtByy6ZfmXZ91546s4va3q0xw8fOfKD/g5cer/HtaqcA2NYLNqIET2xcL/eI+5m1nVs bJAy4ew2t990FbwzKldtNNVW6YO9PV+aX9jQNU+Kqp4em+5j89ujU47lvkol5+raoZ5uW84myF9m o61LXD74xZOePQceupXSWP5w5IDA38yPt6a2swZgrFgGAAwGrV8/kwh8l+AfLia3vXy46MxsNmN2 ibGzCnmefc5rBuCAGUCJ1KTS1oI7H7s7PJ+d8CzG7Y9OK0m7ODfcJOOXP1+69tVIT9OkfjCmQEnO jee1gk3TbbBSi0buv1v07OhSZ4vfvL6tu9+FjOL93880mejcb25d3xPSrqDNjyuxvDSy8vPbvl66 dOW2nxYu2zD3cmZTB+pXic/unA+8ybgf7mJ/Stwx/LUwlxU/32xVVX3ep/ur13uWdp9hcsork7+f +bIH9ZsfnSV+p/PF6QJA9N9wShtFapKjLx045Lv+fIQNmUIhv77IA+lVBpDOoLw9HjRoNCiFTv2j wynvghiNCJGIzeU1WoTB7fCl4htoVXIjgcxkvDy+g0BGhIDF12q0RDqH1tFrvj8DbDBA2NyF2p4/ iiIwBAME1KCFTAuP1L96DOXvgSrrsg/v31NuNvPnBSFUCvlPnIKBlUq16RAj7T0eLEb1ep0eAug0 2qtzMZBeD1DIsFZjREkMJu2PNiUi7XuviABmLa9KgCCAWgGAZIDB/KNNjYjBoNMaIAaNQf6jE0cd gM2CtHqUTKVR/zObeF58Ah2L/2LHOJR5YMzY2GkFJ8eSyVQK6XekR40GnR6LDIIatRGzavprdolN +FRqPZXOpP3hsWDEoNZCZAqN8tqTKIJoNUqERGXQ/lD/nQiH+WID1mhIJgFQxKA3QHD1Ou8ByE8x Oyb7/H7cVwYAASQ643UBYLlcRaQxWdQ/qCkEMWpUOlNk8n8yp8SmB3osPoyU3T+x/2HJ4HkbJvtb /AfpvC6RSq4g0uiwSqUyEi2sefhU9x/Lv8IBQ1r5rcNfLzuWJvLqPnrw4A8njLT/Y7eI8/6AdTn3 Tq5Y8KNSJOo5YubsCWP9HXldLRMOADUlfRQyJYfBCB714eixcz4Ms/vjOP94EGXVuWPn455dikuX 6MbuKNo87u9cDPB/gFpaeuTrD3bkCMmt8nGfLVuycKIdE/eY/xb+FQ4YgfTikszSRh2IIhwrkbu7 E7vjzVo4/x0QSNpYnlskRkCUxLbwcvcw7+SwLM7/JbCqLuFZMUokogSCnWuQm83fuyrrH4JRXpRX 1CDXgiAM0hx7h7j+w70ZbNRWF2ZVySCBtaOryJ6Fd03/Jv4VDvgV7avupjN5+AVsOP8cUNP5cvT3 brfCeUn7fWng71zl9j/JO9fA/Y/xvy5/1/Gv+hgD0lqYev3a7dwGxb9o0PGPAAHk9UBaGtDQ1tWS /ANB5Y3Ft85cqOzoBg+cN0Hq0x6dj4qtlmn/j5uwTiktyXiWW1qrMr73Lz+gWlnDw0vn7hY0/d98 VELXWp2R8iy1oM6IvJcMUVVTFSZ/bElLl38U43+O930MSdv86Pq1DDFz9NRRbkKuujzuwJ5ruoiP V48N+M9PnKFwfUHsuTP3DWxGc7NR6OQVPqB3d0/7v34RPNJSEns7KjfSKdDXhvM7YzVFRdz1Wt7Q 7l6W/81PC/z/CaIEHt0AHqYDTDOARwEqGwE7ByByCkDJBY4fBcJWAVO7v8fcWqrvbS7NEREZJJp1 H88RPvyOr+TXKZqf3jyZIuWPGDvBz4Epzo4/feOBZciEaYP8yO/eOvSngaTZ278/TnWyrKqSsvmu wf1Dw7r7mP3lu/2Qttqc6F/2sfuNdeb8nr3pWkvjisRmjj2623d4g82/AUicee1qOtXRL9CR3/nh oveANunnXwgfLQh58QULVCdvibtyupTu9fH8WV5m/1lnBlU/ia1Rk7wGRphTX7c6VNtWFXttr5Hg F+lj9VcTRWFDcer1LEr/yd3+7NYtnaQqatvOx5QR5w/OtGL8/TkYqmouwuSnM4P6efzN7WP/Ot7z DBgEjA1ZD8788u3dtGKNUZd+5tvNO6/I9dDzbBAE1huNUOcXCHQGqlcUpsTfiK5CiIb86Aublh1K K2l9dREfatTp9X/mi2QE257D5y+YFy4ye8P8YaNeD5nOkbxMQl2deierXPbuVX8IDOl1RqiDbwqi KAq3X9P1OyAwDBmNKCYvpoPXlNCh/AhkMBpNF8W9Fo4iEJb5u7mjBqPeAP0JBXQsv0kBUHutvIdZ BaIG7t8FcoqB2ixgx31ApQVitgMZUoArBGxsAbEOgCAAfutTjyig0wOG/2T03FxxYWfS5o1PN258 uudYQUGnU0jYWFeS+tMPR65cz9EZmu+cP7Vzy93qZh3avpUZqzuTAuG/LACIwMrqJ7v3ZEFkUnNh wsGV267cKnp1Iwik1+t0f+aqP4KFc/Dsb7/yFbzRrSOQ/i0D0EuqUjLTilq1b8U3ya/TGzpRIGyy tt/L3rQLF7N/zDrfehKzFd1bF2OaLBB+x8yxUKiD7BGjTvenposoihh0BkNnt02+Dsll8PQVc6Z6 Wr5+j5tJKoMBBv6EBaMIYtBjRfgjsRDpzTMnUuo0L/8NMgTWLnbWdKVYh6UAI2/0YZ3Lj6ngt5xQ bWHGk5j4dInurQdBlpXrlGXrZoQ5vtkdIzrj2xb9rvwoZKjKuHO/XAG8A6b/tyuwHaaNV59u7Pxi qf6v27zpsxtG00mv12KCPEc/TP4Pu9u9404QzAT+ahb/Kt7zDBikmTk7mTOQiqi44nE9GQdOpMsA 0YjePgS9MvXGqd37LlahqH2PyCVLZnd3tKh/cmT+psJJiwerkqNiiuUjpi34IDLUjPpOJYJEK9ee wyeNVuZ7f/VVuDLj+vJ194vrmnt4WZII8icnf/72aByCMr26T1q6eqK3FQMwylPvXv7lVBSnx4hh dsao07cjfz49zhV9cufMzuMPffuNn2b/6kSxNuX8jlUH7sFkKtHCPcx36OdfDNBWlaSlJRQVNT11 ZtQxSAJR9yBnHtaPtdZmnjl08OqTYgB0mbRw4ZRRgXxS855xs2/TgxcvAAAgAElEQVQ5hnw5b3x9 9IHD0eW9Rkydv2CyPeuNbR+YyRbGnNm1776WL642OvnaE9pKy4X9l6yYOVzINbwrP6JteXLhx4NX 0xvkoLMzgRm+ddfs7rBa+uz66QOHrtQBgBWB0G/+uqlj+nGpBGXpw6/nbMxGYJaVaOLCVRMjvLF5 gaal9PrJExceNkR+OlZQHXs51Xv7qU8Yje/ITyfB8vJjm2adToJpdIKtj+/AcV9O6e3wNz8tA2hs gAkTAD85cFMMrJwBnM0B1AaAYQ7wLIHbF4Da3UAuG1i2EBjuD1AIQFMO8MNSIAsGBPbAx58DI3oA f2XRwdFv5qyUY4cwp6c2pNbcEncPdOroJAuVw/Pt2df2+1VZufcrSvRPc3JabEL7BjqRiWBL9u31 y37ORRCevdfUhSvGhArTz229mSb36hnc8vR8dJ7rx2s/mzTQp8OZNZHvs/DzCSe+Eny1ZiJcm3F0 27GMnLxxH/iSVNU3j208crtYZSCwx6w4vGCUDd20FbwiM/bIsXNihstAP5vsm9Ee83+cM9Ar78ZP K/Yl9Og9ZkYYbNm+/RXRNN0/9c3BG4USNcHVFTSL2Ll5uo+8qTIl6Ul2TpGU4iJs47Ks3ALdbSkk gqr62b4tq27lIqCl69DPli0Y5M8FJTe+/fHXGmTG0lnCgnNfHU20dopYu3OtL/+txm5MPPzt2kKd Q0ZGM4vt4+VRnVLkOW7m7M/GOLCN2TGn1++6LFHqGazB6/Yu7SXi6BXND04cPHX5QQMICkFw6Lrd E/v4MMhg9bPrm1btKERQDpEYMnDM5EWLXHmE6qc31u48UdMoBQjEL3adHxWATewQeUNp1IGDN8sN Qb18dOWP680/2vr5CCYouX3k5x3nUxDQLHTwjHnzhzl38rVHRC2+dPbYpXtZ/pEzHFx8XwZr7h3e tOl0HMpgEtjuoyLHf/pxn46P3SDa4me3Dh8+m1ImJQiDV635fKCfsDVh36dbxBuOrnWQJ/2yZZc2 YNyiyZPtiK052Y/uKhQ+jx5219kaCTTXwJ62bJaNk0Xl4/NzFs5mNNX2m/HFF1Mj2TQyZGh6W36u 8sa3m56SHAJs5YfOPKSxBv9wdEUgH60pTIrJL0iTClweParnUoReQe7WHAII1GZcnLXmV9/QQcMn Bb9qes15j35atyNdqiC7hg1glrtM2zuxB/td+Slw87P4Zyk5zwoFibFWNWS6ubu7uyWXCskqLh/8 5si9GgNMsJq4evesodY0ANHLcxOijp65aRT6O0lLYKZ3h2/SIUnBtrVb6u2G/fDF+IoL61deyB84 Y+3SSd0pBkX2gyOHT9/IEwO2tgRaz9W7Fgxik9HarCtzvj7uHTxg3NTQ58npmzJ/XHma4OvBKj57 o5Li/NGqHR8PxKxPL69/fP386Zv5ngP7OSFlJ2+y99z6wu3ffRnX+34HDBIJgFXEyLFQSeWzO7er 3Yb1BEprVRAMQUYSvdsHn65aPt9MnHonJlmigc2dPGybz6z7fFmdWeDgHtb3d365ZesDaUcDJgKF zqDQEDlsuhePaIQIRhDERpHa+xuHfnxUNuvrjZu+m2+mu7Pxxx8qlKqkHdu/2hFr22NQEL1qxdof c2wH+tiwQRLd3a/XBxEWzc0pFTL982QNdfFTVmydvHrLlrULwwXynIIirV5TVZydnFvRVJif9iwx MfZRamWb6VtsDblHfvwiVuaxauPGVXMDow5/cfZxuhZkh82fYpWwY+70T+4rXCZPHOFszUffsWmQ QBDYWdHotfX0kBCGrjRP4xIY8ORMSUVda0wH8iOSonv77yF9p6z96YeVnoTUy0/L9QDcmJd053hM 8MJ1m75d5gBoqusa9O2DcHVzkyBi/IovV48Osnxw7FB+k8EgLfzuu28vl+iGftBH+Xj/ik2HzcPd KS0dyQ8DVQ9/2pzUa/227Z9/MghqTE4pa/nb41VsZGwP8JwAAQsgsABzc8DODTB9dsm0OALIq4H/ x953wEWRLP/35khYWJacs2QUQcSAAXPOOecznjnrGe7OnHMWc8KEgoqAIEjOmSWnJW3enZ2d+c+g noqLej7vvd//PevucwfDTHd1dXV1VYdveQ8EbpXgYQiolwBJHugxAmiPADt3gnGe4PRmsO/136qM zTEjw4yO9ns3u/hXNMcnVzdofA3rAhqd62bTTk9P/OB+lKGTNdfJhNqSqVrW3GzUc8yKFSt7WNPC gy/l1ZPM23lLU17/9us1xH7Q+AGcU/PGT7yYqlksJJoWh43WwWoiAQEIRFISMP9DUX1hzbq7WZyZ q7fv2r7UNWnpxOFXm4GqJDJ0x+JDJcx2na3Jl8+eeApb21vggFnGzgETgvykT26Xvs8DIcgIOfCU MXj2lj+3LbOBXobE85WIqqm6ID4prTiPn5v0Oiby5ZucciUWroqz1w6Zkccbu2Xn9l+HWKUd3HLi dJKCxGw3KMipLmzdxGFb3+hMmzXR21bjwibZskNnm1OnZJ2GdHOmRcQnuwVa1VZFJZYIkoNXrTwc 1XXSst17t43wrVg0dVRSg7z0zYuXEQXdF2/atmaOgbSBX9ekws9vVl+asVpr3Mrdf2zu5WJSnpMn xCJRoBYJFd6BQ9Zs3TSrh/6WhZdr1UBUkXVxz7aHeapuXV1r71y7+FjZ3sOGTlbc39h38xPi/I3b tq4eLcm7sP/kmao2tncJVO32/j37e6nzKjLrpO86BCoJW3Po1rT1f/y2dIIDuS6nqLStZBYAX+ii 2vkM+HXtsmGGqZtCXwlkKl0LJ93oiwVCRMvAuh3XuDA0Oq1WqmyqSYxKrBZJsxOiY6OiomPia/Gu QQEVaRQpHd26zBrdJezMjcRyzB7JNPAPsS29TEJvHr2Vr7189SIP0rENZ+MUmGHJSM/MKSkpKUx4 FfkyIqqoRvg2jNYzc58xIYgofh5X8S7pS1Puo8Wr1tVZdVq8/NdBVvUHb8UklTZp5B/Ia+NfRaYV 1tWkvXkVHRmflFkrUgJ5xfFFvz4otV66+ffd25aYRy+fPfm2EBbF3b246PcQuUOPjuaquzEVQjKi CVcWkNiGfv7mz2LKRSq1kVf/3u317oQWY+0XV6bdeFrI9pq/c+e6ALP60LgcMazGhhbG/5SR/hj/ SdXvFgwoOsbOpkUXj2xVd/9l2dS+Tcd3hBc0w5LK4LP794emu/XoxCh9+uf+EwwfO6P/+S2+H34d FlVJ6s2dO5ipHq9fmbz4TjRFdkOhwvqJAMtqnl+7sKmuCpIpJnUcCSMo06JDF1NF85ArGye7kVCx q9npaw8fpGUbNyREF9aJSC232uXyJvNuc6b4slGkMuTK+rC7JBRWTVj5Zz8/RzrMDz6YVWLsJyvL TpLIG+TC8KTMrlGv87PjAybPmDdmKIektms+sp4b6ID7/mRjG8++3XoXRxT+tQZOZbAYVU2X7l1v sLMwdu7aydXfgK1v0necObWMn2U/e3QfR306gULD2tRYkffgRgXoLSnJykbk9VXVpYcfZQ7v7OXV b1inA/MIo/cemdiRRsKcAgLpczQDAknHyM6vkwPLafaoujsmtaDH2B5RYUdKBBlPDmSVmHzCf2BW 3TA6s5kfFvpI2uzlyXbdeLhzVwYgkJlIsyg14uh9yUBr00GTXbr7arVsgSNkan3qhUnH8tVcyM12 mEylFhQ+ySFazpm3oLerEQJ1KT1i176ni6LymUb+iUROeeLRGyEMG30d/97LfLr9y/4o2Rj8ORvH 1y4percgOPEoINABVA2AEfDqDCaOAAEcMLcACCBQHQ2yC8EwAJKSgUQAquNAaSxQdfr2ILix8MFp NaorFEpZwpKGpuf8rL7W3TWmP4dRulG7nrqg/uDWgtlrAk0ZFELLSioC0PK4U7uPFqm1oY7tpypg ormzF4fNWnlizdjePiyS2t9eNfy3U2ldV1U+vZ3VAFNaeFOKgfuwcf09zBCUWlW41MVyHUBgn15D dv02iCFIDMlKU1rol6UnlzNYalFJbvbVqoYeuXlRQhfbbRuW2TDQjuz4tXUd7A3xrVw9+059+5GE cU/h9/cRCEQW1q4HD+EaF2ct7993dfWnk+hW7r3nzoLhFxnWnaaMc9cnkChUCrkxLeJMXvE4GM5J SpM01zVWviosT5LA7e06dutkTi7utvbsklEMGhGBERL185FOMPUI7GApoUyY5lWkDs9vHDm6852w NLm07vnt7JQc/cCawrg6CkSEsjIzT0eUrjSFy4viE09w+/S1sB4zp4O3PQPHqKExTYtP/HGbOctF 196/p52bOb6NrUAJ6oKHO7avq4OUCjZXX6BUs1IypTnw5L1be9uw5Z10EqdW+TtZUGH+xQM55R16 NxVn10iFdSJBXGRmnyFNJu30Pu9BAkXLtp0vXRCYlEj9axGcymTDJVXBIXd6WJu4BgS5+XbitKE8 mHRRqDn8zulnb3LUkEzu5d8wvZ+plV8XJwmMENgcS99u3mn1Uaga0bbxmrFKJ+tuuO0vq+b7G+E1 U7FhASNS0MW7a5fpkztyK99c/10JwUBZpIl/ea+OLgS094JZ4wLtDTzoxQNW1iJrAruMmdxQU/u6 Rm/K8oX2umQy9R3wCcvAaUAfoqS+mP9ua0iZdPZMiuXwe2vm2nNZcGBXd3PnJmsdzfzzXGYvXW2j V8U2WLBimBVmaigUiqT49a2sDLa3Iz85oZDBVjUX5NXc5vMtXkWkeHSctnFZbx2C2o3WMPA0HWhy Vgg0Pd9OHuSdVQgMDFz8+te8ubga30NECFRpTXpCTgUd6cExmbKr3wAujYwrq4FT/979ZcKa+ve9 QqQbenlxFcjuxeOGEZRNoqwTzzNqehEKc+ubuo//dXE/J4K6j/xJMr2vt9b//KnpH49HQcY0hc4L nD7rBbFpsLfDYyG+E5IVf2Pu4bDNBx8HO2tFrF6Z/xZSnIDATcDU1IBOxQYNQ4eprYXC8ua69PTU nGoxnY7zJhZXAo9pBICQWOZjV949OJuzYulSOUoE+Il3RAWBwJE+tqZsGUx0aucxRZ9rpafYiaII kUImY6pIUcsJ4P3ZeAIWBxFJ2H8/8Mq2OxgSUi+q4pdWp8TfuhIeqedwxt+YRiRSiWQSnUanv4Wj xNP/oBxDjn03FxsLmhpY79kfqGflpM8iE4kQQUzq3sWHpSmDzV+ENRWrmIRFx2QCggAig+tNIeug iErVmn87Bz1dpOPWPw8W5ebVCJtzXm9fv7Xaq36fqWXnuX8cTS+qqaurSb55a0dsY/ihpZ60JFO/ UX88Si2+ZFP/6sGNY48x5UfVVFRIxmoiYSLAz0QBEoK0xT/qN/5GcKf60rwKQWr41RexKeQ9+0Zz cQnJS3KyBCqej7vFF9qliYhg7Wqwf/+73ziLW//98PsfPJe++2H7wg9/TV4O7ElgyZJvq0sdHbsF AQ620pBTzQQXQmZx090icVc3LY3rOhCNwwoMcmOaiv07WbwIDRVIZGj983YD5u+8E8PvZFH+8OrD hxkY/wQi5kdZ6unr0ahkMpHMNeABqFIurS9MS06tB7SWC8yyerp1b3wdhQKU5kFHs272v75vxekE HIxJDUMqxMy1naOdnTk2uzsuCx+qZWDKQLMQNYx3ChWbwlGYhF/aaAlACHiiCrRFSd+tnHLsA3Yf OMrPy6sRN2bFbPzzgNC9aIcV5pBSaNi7VBr1nVpiTVLKAMm9k4+tCVCpyTZeXceZ2eAHubBAHBah XTt10GK2qGUbN2EJRBxxDf8jioWtJBQhA4TYkjEe9ezq5GhtgakRhTrp6b2Z5u0sDIl6y/ews/k1 AkFNwuWrm7KpGbsnWXH0hm4OseDXVZRV8iNfHguOmK9rPQa9O2vpiym/Xdh+swNcdsuz70MSmYCy AWSAxexEbFQqMV/VlkCiEVoS+JC6DvK2MWcq1RbOrj4rDE0drNq8jozLCvvn4yGs3W7vpfN1zdVl pWURYRfDMvN3WG52434+GNWlCY92nLliMmd/0d12FWE7R15kknAwegSbW8RiCBAYLUXjXUIgkmko AYewpJPp9A/r4VitdDKBQsE5wH0P3D5p5p8oUAN7NyMtFhHvLzqAAQkf+iQCgsJkIoVOYzA+chMw y4AVSfzQSWpIZcPQ1abR8Kds3e5Tf8WelcTc0MQ/iUZnIIBEpmGsvtMKWKWEECsvNwcbay4WuTqt fjpex5BHEUFKApPK1sIVkKLHpbaVoBEXCpGIIlCLhhBRlRS0oAszeXazV2zrlFlY21DLTzmzcV2y Y+lpHy4T5x8LO4gfKxmBqCY6cw1oZJJaTdcz8cE8QBSlIBIqUJFwDSCicgLK/DFnsP//ph88AaOQ pLFEUqCq6Dro11sntRR1GWVqQC+tgEmQNoumQ1MXpzy/zM8marn0EUuMWSSaBTgzcYH31dV2KP/y ueuNFoOd2gf279azVamyxuKy3PKmXK6Q1Xnt/JHL1jy+Yuk6c4x9F1/tpeXNvCk9jWjK7Niw+KwM wvCxk7q4LNmwvS6rwEr59M+z4j4H8BKUclFddU1FRZmgtqKmvCiPKTUxNSYUhPQccvle4qU5/akF EdxLl5PenkIhkinliRmZPs5IlSD8ynVyn9WjzA1NLchlaqZTex+iuOLV/TsZQrItj1lTX1SagVDz M/lkfboWx4ino0mrUYVCmFtWzefVwCgsbJKKxGICmlwqGuTvo7WqFf9cS6jo2poLVZOnz57iblTr 0HgrpgKSQ3lxtzetujhs/4nJI3gdDPL4URIYgmFYyaSReHosUUXG/ejH92QiF0GNj2tgR2TVlKUr 5w9zr9z6+w0AehJIbI4G/u3MePwbCydFj40/MkdPytdH1InyZhgbslQgL34xeNicjLy6i7niSY5/ EzRj3y6wZhXIvAXGVYPwKcDaCmhRgSAf7D4FmgLA3n4g9z5YkAJ2zwUOpcC+Dzj0FAxwBk1l4GEk 0HYEU/t9WzXq5IhVEytlFHLpvMFZ3vC9OTd/eZL90oj9YGf3gUafZr+BFfLaytKy5iaW46DlPZjl 8ZdkouTCsnqlnpxFJxnoMhpLUu7GPwuT0Dwb6iA9lAlK5m04qtowxY3K3x20iTPjhLuLd5ejl1r3 q1qWkV8CZRryRfTBY2eUZf92aPuV9cs8dQyUdSLExtOXR5NnRofev5Vqtn+hb/uAh6c2LJpE6tZO cONGpM7oMZgRR5UNxfwmYVV5tURKyM8rIRjocblNr88uuaxcvWT2DHu9SpvqsNxqCJvrmXhKqQZ+ ZZZOVjaVnxz6sMJqxELfDizmrmqJbr/e9lBD8fP7ryqqISND3eb6krJMZWVubok5CaHqWllwNbok ivrisnQAiqrsYalCmVYr8atRCokK1Kkd53K5nGbl5mehXZkd8yz0QR3b2KTw3r6Tr0dt2Ta1nZ6X dlJqnFAFq4EieW6v0QEXns+dO0jQUVtyOYwgUsBszL8w0mWym4uTHx/ei6otS4rrOzu4snUv71w6 Jb2n94OrVxPQAZirA2hG/j7sEwKFmVsPDhClvnwUW1yhxTPjMD8PYxGZqKm+HhNARVMtqaKsUAvS t7AyhbODx897fenJgf4DEE8dyvNc0FaaNczpsaRpW+tSBHkJ9w+9bKq0L6wVtzPiWXYhr7/2uJeu y6vn0RHJQrtmoQrlUZi8TmytV+nZFRZwYdyz2CTRgMVT5SV1JVlClyaRDKpJUFTbF9apbA018W+i XVkHZZSWVEpcTJhlhaWQmlAphu212JZsA1JOXWFhASQvCL2T2GHxql7WlMoifmNzeUVNlZBdlF+M 6upxXUb3ly0MPuFuPrW7Y23Wi8Ozf3c8/2wiRSP/mLNCUMlVOdFvstyhiqToDKF+r84WHK64qpng 6NMZTybxIvTxo5zpaweZtKOffHX65nOmC43/+7oH9co+ZSKVmZaGyIGAkGiknFcZ/ACD2lO79kG6 m+pkCLs45tC5OzqdZi+ZNlKcQgt5GaVUoohaXl1SKqjjY/xL9TD+YT0uj8MGpZWC9OoSAYxoQ3W5 1TX5SBVjgEsHw4erf19emNOVdfvytYz8pZ9X/L9HP3gCbuJnxEKNkUnpxnG9zfp7Re9Y8JjiyT0a MuDEyFGuYSsnjQA2rj6O7WuT7l167LZ+QielEAT90i1l1YK9DH2XoClbFoy2Ybe2FSgCFyQ9OXL3 GQC5J0/prlg+7dd5FX+cPefqtW3WzSjiphETBx7HYksTa6dxc351NjLQnb7trHPEs+hkssWiXXD8 bQgffFWpL7fP35zUUmBMWMwxYLft/N7u2mbu7qLNM4cgapTBtRgxb52HMe5FmnYcMffCqoNzJzQT iI6B09c5GxrwjNdsXXhw77rBJxHMK/TpNXrGIEdifeyESb9J7G3BxpkhwNCv+9yde4bqfmbqMP5L c+PuRlTaS6/l9LSoLyvOelPuZu14Mbrp5pUX9B1jP+VfS1Vvayd7cmDx2P14sEzaeDbYgUUo0zLQ R8X7Fo/fiz9sN23NKEdjbTLV/9a24atnD9+rxTHp2MnXIPXmhXOWy1esPnjM90lYfG5j//NHmgaO xZxvAxv/z/lnUslaJp2tC06NDzqBBcnmLh2XrhvEaxmPFG1jp3ZuRLqzp/Hfh6yCG8CODSAyEZgA MOUx2HIdDLIGhZkg7Bkwk4FoIxAbA6CX4IkLcB8OYq6Cyb+APVijdED7oWC5W1vh2mekapRnufLa wURWjUQqogOpkacnFhFRy5StTTAiKEq6ezA4B5jduRJtO8vuzK0YmCYNvh03qc+4k8t6bpk5HOXw LL292lHTrgdfs1wwEAGMcR7IofULFVJZwKZzIb8M1tHEgbz02fRtEYZcxoYlrKNXZk5cOHn39jsP Im337Pn94rqdUwaeVBKIDGbA4p3zjKhkuu+wnTesIsIiG6ju80cXPtDCoydZWcTIcdvfFbdy6ikz v0XLVwRxHB3EJ7fPevJbiwKsOXzNtmVVnWPtNdIy+vDepeMIwNxrwJK+xnQTj6QHh9fPmdf3d6xb 9T07D583zInanLVpy65oGhOc3PziJGBpTb8dsdBQg1RVSecWPPbEhufjoNWu7vTS+ELESFTbkJLW cdmBP66u3jl7qFAOaAzWiLkbutjzGgVGVEHBzvljduBcua/ZNwybJwGi5Wlnc2f77Nu/YZ6rcdfB M4d1tjIljZjut+ro6om/E0iDZ04fUnflxMaLbpeWz9lw0u3Zw5Ry1fzZg/+8oYPi3WS49FYYedOU sf33YkPA1s1v0pxFFvqa9hAQZe6zO3t+O5rd8ltW+CMAXI4/OemlZW3CC149eRCmwNrmblOXrLLn atRYkpFLR0vbyOPLph0n2vbvF+idGLv5+LNexyb7jT1pO2PL2OeEtytluSmvyr2sbXR0+h/deGbe +v7HlFo6+hMXbaFXvwl5fTeiyMoyPoUoesClVZ5cf76j3w4N/OuIbtx4zdVNXH/YuffZThf3vWDo mfx+z//EpPZOwwZpFe5aPwvrQEKvMYucDGgAKtkzclzEWx6f/hp9xGTCoqWzJ886tVd3/satd/dI KDTWwI3H5nazZAtRjfyzqPTOPca/mrVp/AvAMXcdO2uRmZV38Ml9+5ZuHdlnn5pA1NXvuei3WSZ6 ZqMnLq6r/3PX0umAaOZMMvBkxpwOy/WfpuFaIMPSd/XoC78vHrMTJfoHDtDPev4oadhEUyNz0Hxz 9/wnfyKYMzjlt33ePDrUnLln5NT3/C95ss9k1rp1o/zAyRi5acnhC2/6D2y4EPy0wdz5fPrYo6MW b7L1johMLDVavVq2dgP1vwtM5fvo34eEhV+BUUIkCg7F//aJoqnot0Av5fb42bYUnrWN7ufnn7+N lDIJTCQzPiC5I80VWfkCpUzc+GTNpPIlr4JH2bfxqRqCAJUClHIIYJx9grqOqBRqlEL5OEcDgi/u QEQqvjb5A3WnNf+YpFACCSAKuYJEZ1HJ767KIGo1fpIJgghkKpXygQEI/5zG/ChpAaqS5GfkiFFU WpM4Y+KBw2mpfS0Ymvl/KwBUqYDUFDrzk/1rRKVCyZS2F6p+GKEwkCkxSw++lAzgn6sdVcqlahKd +a734aaKhHVT9rvNm9bFw9XW1ozxnUwhUqmMgMn0w+YrKmssL66oqhcrEk5sTfBecnhWPx5L044l AsNoSzYPuZLEYFNbn6nHAk8SnjT2fc8gCCyTQ3iOhh8qQJVcqkQJjPc5QlAEeZv1HVKqSFQahfxO M3ANopARpQIGZBqd+tcYlMnkgMxkfgSsCCtE/KLSRpGoPuv+H8FGJy/PcjTFbxNhqq2UyxAShU77 DhOgVqkAmYRCChWBTKFq2Or++F0Yvyz06fABb6/8qYm0z5MuqCGZGtCon+Vp+ZT+Hv+IGlKrMVbJ X4XjU8klSphE1WL8FaO2wf/bXCuYHDC1+OhaOyKRyFqOr37EPn6SS4VSsbZ+fWDL5XIS40PlmAao W07PwEoFoNCp32Ea1PKywqI6oVguzN+44uTMC3cmePzte8//ZfTvy0lAJJEZn2IUNOZGJRv6wY8u XtXnDFi4uAPvO/GBaUz2p1+qi+NuHAorqyhr1LeYvrGnVdufkqjUtyV8fqmfSPnsQguRTGGQf/y5 vdb8Y5Jq+R+D/QFvARutpJb8OSRG6y6jMlun1UbltQ/OHU+XSGsblH6rT3SxYLTJ/3sBfFYqLoB/ 0xFFAhmw/nO5MQgETP4ffkUVefHxUo4oMvxxRW7tvJVTzL7zWBqRxWoFl4HUFb6+evVOTBGiQ203 L9BLV4PQ3376NlMShaEBBwY/ZtNqPiASyex/QIAUxifeAeHdLh+J8en68FsNwhyYT3klMpmtk/gq m8qfXL8Ym56HUMiD5/U349L/OpxBZ343tAjprZrSvgX/hESmapI5kUzVnPGIRGV+w3rM3+OfSKIS v22R5/P+b4P/FhawNrSuic3+jCsszNCwvK+ZGIxPrSJ+WLnX3fQAACAASURBVKGljM969hsJVTa/ fnAtNDlHoASGg5f0ctL/vnL+m+g/iQUtqyvKr5QQCGqA0s2cnPS/N9b4jFCRoKK8ukFFZptbWun/ B437f4rUyqrS0jqhnMbh2liZ/sx78HcIbqgsq24QwTCCEFlO7o4/ACnoHaFyUWNVZaVITeUZmxlx 2P8CBtf/l6RWSmsrK+qFCra+samRPu0rgeVP+q8jRNVQXVklEBLZuuYWJtrU//lLSP9ryRj+f6eW ZUA8FvmxoOcoqkYQQCL9NIj/VYRgTgQWTP8bpnlMgdQtCvRzU+/76KcA/1eJtHnz5v80D/8qqVUK FQpIBGJLpqP/MDMqUdXrmMjsWrURl/PFDOffQeqK16Fnbz2DeDYWeswf1VBUrSp+c+PAxUxnP3f2 /7EpWJj36m74m3qYbWms8Xj5dxGKQykSwHdkxEIx7wf9ng+/k1SNeXfvhRfXSLmWX9qKxnqwpjAt KjI6vaAapWnp67Ja3lW+3rNqQwF3oJfJd/dqCwPPimskPEszTQhj7+qX1BTeObQnjmjrZcn5j0T1 WMfAKvxk0F+OKSQR5GSkZOSXEVlc3U832psrigormphaWlQy6e3H4vqSpMT0JoisradNeVcC0lzN T0lJLqqW6hgZ/rC1uTbYxwR47cjhBIKltyVHs3KhWOyY/yomTU7WwtrzIxUQgUFFGWhoBE1NOGId lf6fOYrxv0r/55ZnUUn51d37b0RWGjkaqvm5hRC08ux914bnu7ackVpaCmtq6NpGPQaPG9qrgx6+ cyqMPL1r46UoPCzk2Pca/cuq8Z7/4rqGmP96z+HTlSIigeC8cOcCN/0vr+AKLw+YYH72bjfDd9Ui KnnelcuhWt0c7KzY9O8UryAl+HiRxbx+ftxPbAcqacwqzM+0EQ/7jjLldTnhcXHAZvBg10+2XjDn uzY/OzSMOW3l9zH7KambIo4cC0kNF9tN+qUXZ/3mp04W5TYjjy3o9XfvE+MESWpDVv5aGbTnyRmL 79x3akWo9NXhQ2U6zkGjBnFxswo93T9vbyhw8zH26DZxfG8nElBlPzl3ICojP1X5y9rJTec2vNal mbXbuHaGPw0WPr8RVoMaDR7dVeffs3imEFbmRl9+Hnuxs59eW6qEwlXZT8YvOWDi3N6UqQtTDWws DRi4hYaxaTFT+I13utpkoDj95c1oypUAP922dVmlEJTmPpa1m/BddSDi6qQ9y1dms7xmLVvX20m/ OPLq3tORMFDxa8ogC7dx/UeMHtyZIa28e+HMnZhSABoEAiH+nVmvQ4eXu+rQqhJCDq7Y9xpBsfnX wn/Q3JnTO+qW/bpqe5RIuyu3JnmrasuZ272s36uPrPLgwT9upxudPb7Uywp3FxRN2VvG/BLFNDVU kLosWL54mDsNIAVhR9fuu0Z09GaFRda7/noyeHILZhNcGH3+xOngcmbQ4uUzOtryfpC/imIC5OeF I04j/3oEV8dOXFhz6Pwgg7f7wARUWp9+58otqz5rHawMvngsAQGR18DRq2DAcjC+CyDDYP868LoW zFkE8iJAeC5AGgDdGAwYCUZ2AQwqUDSARSNBWcs6qGM3sPxX4G36Y5r1k76B/ilnB1Gp5DLos+Vt VIXTlxDqCVSGmad3125mz8LuEdy8ggIHGNCpLK6ptRm3NiaZ7eBmqMw+sW7SuedJQgitfHls6vrD A+euXrdgqHZpTHpkifz93W6VQiGTwq0YUKvUWO1fXnOnanE9HYxfR4Zdvrzj/PP8r7RTXXs3+lWp 8MONcqqueUAfe4YxEwvK5XLos+ZDCkjVOhsFNgeq5B9fSoeq87Or6qHWnJJsuk1bv3F7DyeDT7oN BZD8c9B7zBOQQx+lXVBLGqtLC6okrTNMEEk0j4G/BJ+dafrppIJJCoI+S0cBUAhSwV9A9ydStcwp b94oSECLw7Pq4y65dIdgrP/e/GGFyqXQZ9kglJBcI2w/p12vRfNtyqqUf72pUik1CLClvWpE9dWM FCL+mxvh+RVyXfq707lErpmbXt3Vk4fPBJ+7VirBPieztLXyo17qWphbGJsYO5nevhSrra+Nm1oS TUtZfOP54+cF9V+u5S1BEDYCWgnwbd4LDck8NBLZwHXi/HH65Q0fPlCrIEyAH6dDQBFFfaVU1n/D qsVLF08L6mRPexcfMXpuDL2x0L/1vInAWLD4CQQCfopXqtCUzgRjYMy0EZ8woIEI2qYeM3be+KWn XesJSQ1BkMZPPiZUJq7LyxT0GDjEgYvriY6Foysv+6mM2mPo6CCzxi2r5ux7ySdS6CamTFm9QIbY 9R4weMiAQJ2Y3EZMmQWxvaaue2IctHTlL+4W1ITU/AYRBIuK0lKt1s1ftHzljp5Q7Dl82n7HUEHM 9ejca+kSgQJ+Z4XKIi+H1zht3bGsS0fayyfXS5tVmPHIO/FA7Txq/aJlG06vkMTuf1X+FiSSxLXu EtQnqCQ5Jbu47it25G8QERPg/O3nMQF+GNdQTVxcrfqDPlMMTV3M7NpLxGqgVH6eD+Pj0oAuG+Rk gVU3gAwCohSw/SJI1wJGukBYCYrKgFtHwEwGO2eAExEAUmMaBSRCsP4QOHMGbFoIHH6mM/q30j8w AcOC8LOr2rtYGZvw9PwXvC5XIippWsjB/t6jFsyY3NuFxwuaeiGhpM3sRVT9zgPHLFw1p4uW//CZ C35dvdjLiMax9B4xeWyQn/WkOcu3n7q40Ms99mVOvUjRkB9a0u/iktF9ew+eNGnmbFguhBAAN5dc WN/f08nIxNRAb8b+opaxgyhFaQ/3DvHj8njcvoO69Z+/L628SSMLNH3b3j38dF3HrVjU9+y8+zW4 1ZdmPdrXw7vnvlspZTF3pgV5dR636U1xvZCffO/KjVCV6sWtaw/vhTx9GV8jRQgkKsuAW5MT/dsI F3tLQ87Sc5Ut04e8qerc+jnuPJ4RjzdywW95NSIUKl5raT546a7fV4zg8hx7D/0zpVYGYGF+6qsn r8KSY548fnr/1q1bsbmNoCXP473Tq128/Ffsu15Y+yEfjrL89a8DODxjnpOzLSa13TeSVAApeXWz u48bz9iYZ6B34DkfC5LEgrywsAdR8c+iXzy8E3InPD5X+BZNFy5d10XPbnTAmYgc5P3ClkKQd35d X0drHo9nELD0RJEQIIqm2ODdA/3GL5gyurszz2DA3DuZVSqNNoDA9PDrwO0wblQPPwtLj3nTu0Oq IX089DCjVl0QsWBsN56xKc+g5/ojEc0tyaaa02715+gZ8oydvDv9EZLw1s6phCU39y5ytjUbv/7g /cgYoItzJhGUYAJ04RliApywfC8uQKAM3zqOZ9xz+YE7Zw+u4erzuo9d8CRbMxx0C8mzQ2PLYZa9 jwPr3W4b2bXPhMHdmP2mTbIFr8LTqrEGmPv4d9LrOn3GKDdr6z6LV/aEAvr0a4dPYwSGYydvPUF5 emyW+ItZjqQlsSsD/SwMsRFgMPbPkKa3dTdWXFw125tnaGBg4Mnh7LwdL24zAZQs6cGxke3sDbr+ cv95Yva7h1BZ5uNpwzpjAjTk9tlxIU6Kf658fnz79hN3BTWvL508dvH20+IGCBvSqqqoAF+PoOHT zkZXt7QTbSpNWz93cOcxkzoHdjXg6U//7WxF01vk3vozG0boG5oaGXoMGncgu/btQynGwEAbC4yB R1Ep2Rp5fE91yWfMLO2mr9gVnd8SmAIkO2RfwODBUxbNNzQx4/E4f4ZkfDknFIrSWDo9egZ1sWhJ w6Bn5dmva4BLwIBx4yf+uvboyXG0+xcSlEw9/x59uvXtGThw/PLpY6bMmTlES455YlFnlzVLhl4+ tXxw/+FLZ4zy9AAl2BA2Drz6YN2wzq6Wlg62zkhcbvVbBlSN2cEP4M6ea7vaOhPU73EfH52yWzw7 yM1jYICXAyjNqmzGbFDXg6eO/zbL1cbK2sEgC20A7zxAgo6pQ9fALgZsGgKrvz13GKoSZ945PdrJ dfCs8ffiS1CgeL5n/tARAQGLzkkAKIw8hAlw9rpDfwmwKivp/uMIqSzuweMHIbfuhL3MkOOn35kU ufTNzV29erhzuX1OPMrR4HW/pXbegMMFNacBXwriHwGJGnTqBZysgLsz6GwLhk8HR8LApkngz0Og piV3F5kCDHiAZwrMzEHrGxU/6Z+lf2AChmCKnt+2UyEZOfF7rC/5n3+Dea+WXh3dzBITK8VrLz3a aCZJfPKiStSWb4zft6GQSRRAAmoKteW6GX4Jh4KoySQClUbHiERWE4kogcBgm4HzQ/ZfexKfXe0/ esadi1O4cOWFNWvuFnsdDc2pKknYS97obbarFlFmhAdPmn9Wa+q5ly8fB6DE1NBsoezz8O5t/aqU 0GtO3bymLl3mov4jJENMoDCsffv2G+KXlFbPce+5av1SkopR16iU1ZfHvUyD1HB+SlxCXHxqZu57 k0pAUrOsJx19Fnal2/7pV5LrVZLax+c3HH9TfygmuzDrmXvVi3k7gouE3DF7Jj3YvzLfdGZE6F5H xvV915NhWFZRlJ2cLxAW8VOS3yTHxmZU4sOSSOP0Gr7w7M4RusyiCsn71ADC1H4W/qdMNz6Lid2/ aHJB8MuiEimeFQBozduwPy4rK/zw5CW9fi9VIZj1T07LLuE3lmekJMa9Ts0rlyhbmk82nXfm5cHB fV/HNbyzJzL+9kWLT+c5HA9LyUt53oc/19tqbRVZy76Dp5XOqywpfdvVBysYJVHhr+ulGjMUEBBA QssLo168ePAg7FbYa+CCACJal/Ns1/JZAqdFKXx+4qNpMednnX6ZhvWATAT13hOckJx6fNmQhDMH kiqUQFa6d94vs5+AlUevTnKu++OpCmgBWFJ74/haTIBn4nMxAZqlXsMEWCsCXtN2XP3dY8+SKfsu EC/dvLZ8Qh8jdptLpWph9avKPC1PSw9b3odb1A2JJ+5qLVoy29feLe5GAuaUYUNCC2QnPnsa9uDJ 41sh4YCMvkunCTiWzi4mytzMxNpmRVu1APxiN+wyY9Xj15lZr4KLtk0JycT8CkVhVGhCFrQ9Jp+f 8Xyot6NC1ZYLqow7OXvSrGD3pQdCtwdemrBMDbAmIRVJt3esXkHwX5tRwo+7N/LOH6MuJvBVCMnQ zs3OlMVkmbm4ubk52eq3GFCKgeflqzdX9Kl4VCx+2ylahtZ9Onoyc/PaD1/79Pb+zJv3X+ZUqVHJ lUkG6+M9nmfzC9POt9d5vOX3PwpE8qj9YzEGum87jzFwbdb6FgbaJK7ToMe3DgVYpqYJ3sqEaBkw ZIJ25dNI5fnwmBen5+1ftDNb+gVp4ey1INi+u9mMg8WSSIXNjU1SYX1FUuzjPOBpxiYQUAIVaah5 8+L+jmHjjlxO8L+xu70JmnMlvvvOSa5sKpFIsvIdtW/h+nE2OgSarqmRNoVMkKRdmXuNtKS/a0to rky7eJ8oaRww3Eu3kgjk7/u/XKWvzSASiCwtCkULleF+JRbTW/BY+DGLF8f+IJH7OL7fAGnZ///b NpNAYRl7mZrYU3XIE72MQUlFs8fIyfo51d6dPNkAWLYfhQnQ2yTjvQCRhoqClKwcpao0JTEhLiU2 Nr1YhnsQRIDk15JIi7efP/4Luu3KvTJh68SU7wl72wNM6AxCX4Bbr8DqaYCswLkmtQxxTLwMHTBs GqCmAL4Af1KUA7rYA1MeGDAWpJb/3db9pH+FfvweMKRQyJpz165dUVpVr4YUoCZbuKELncU1Dezv YrE4yNfBrt5mc2pjg1hhrfs3vC0CHWTER5zu3odM4pcSfI6c6mHGoZNHHEvU6brvwJYdCXkwx7b/ L1v3Ddd901ApJmjH3r+ayGSJpHQmK6yyYXpuUqpR+18OLxyqjzmI5460i6i20aNrPMuAiopPxzQ0 Wlbk57C9SaS5x55OOzKSzuZa6RqmpQKalo6to5WuqJkkBYbdhvzewbnwZviwbfsnfIzXqJITx8we ObirkyFz/jzy1jclM02glNCbsHxgUsTdLFTRKIKLz+fWzlJ6u9sD0rxtS/sbKwSBflV3U+Qw3bjH iNkO7PLGAu91kweYaL8XEZHC1jNrZ9+RV17wVz2lMTciwBz+qaVW2Ki1XWTsElAPjIhqqVwhij37 2/LZ5WI8yuzZpKJaOvZctYpu9vgBaL90ru/Hl9/JZnZO7iUO4O673+vy4zPKbWcsn9utnRUFWG24 FP3AdOCzgtWjdAyMg0ZRnRb06GhjPsl8TZ5AJFMZa7ioipcJiNX8omQyrK+szAHaAVgIXlde8TqK oK2X/zC4Xq2slgNa8Ev+BH9nEaQqerjZZ20+YqBytx6CtaM281l8meXpbUsHd7emgC7xTVmjXiDi hqLMF6Ew3C827FYyUEplKCZAwXKlq4W1q72dmc3qsDfrjL+2IwdJRYpmLZ6No86Hw2ZobtjVXNSu Iie/TFZbUPsorbxndxMstiGVFuYDSEhS5pA/nn4Yel5svdg6YbMCcx81Z83DASpVKkHi5cEr5kis lAR8doHxjIim2sK6pN0LtyYFWWn1nejhbkfXeOZVVvHgZcP4vZvmj+ylRyWE5SIWQU/VqLKyuDox jmBmlnnvUgUKVcIk+pmwgkkdrFx7DqKTqp8mW44ePfjDcKJoW9loK226gbr3XUJn87jmg4J8/McF ddCv68qNwa+IKotuXAZod3nC/eBIqaRCSkysak7OSIsJb8YYmDs6kE0m3H2jcBsZ0YavihORyXN2 8Cww9sp4/4Slb25GY6/YMqOHix2t3bhOv+7UmHXnS0TRI11Z1/XAIrVCSPLal7vI/91zApHGYui0 Yyt0qRxzcw5VDvSB3nsYdgJdx8hE530nqJr5LxcEre62K3S+P67witrCRzkNtQadtRGRXFFeUFbj 7aJHp+Dz0VvXk0ACpI/AbGBIkX1/26BdyRfi77l97QDC2+sJRMyF0HxCj8gx8nYPmBhXXhf3592d CbTte/ol0IecC3LE28o2wgSYZuhW9O5lslufse2cmZeyqzZumW70HioSBggguPcO8OnfvRPZYumO fsUKLLTlaqpNpgCwFug9GvwyFUiWgDtckCoFzc14cm6lEohFoBnPLYE3WyICkBG4GAcs7YAkH+w+ Am6FAtupQBM+5U/6J+iHT8BQQvDuPanqdZee9rZjRe4cNywWQhEUU1A6jBrQyChAqWxLNYnd9m4d rsyISgWjsBrAsApuuUmBqJWwrZdnwISdvWz0Ofr6bAaVAJShu7fwe68++2Q2WSV6fO7PC2HXS3vM AgQDWxsHz/beDBKidrnkPZZhwiTkU8iQUiESyXWYZAWB4erqwGEzNIwVFObHvpTUm9oZK5JjcswX jdXZfCRq/YBADqawKlgtVUKQsqZKwRHBzJZhK8fbIcZCHhVBLhErEbI2R1uNqHlEtGUsI1yXTgoF 7gOTdc307Dt6u7mSYdTV3rk3ycjJWltdJAM2Liw8VwJQq2H8NCfufwNIBeRSKRZbqyBY2NiEsgy4 bDKCvYH90/IvxgqJRCTSsHGiahCITDlMBEb1TcwNGCYNidc2b37SdfaRhHOe0pzLdp1vtXjEJDUC 5HIVQalQqZQyUbOSyNLXYRHxLcGWROwtCEtUHO2eTCLBErEUUqlJRERYX08FukzsJ7WaiTX1XQ/a wkSdNreh1CrA6zJx5vA+nUxVWSZHA+QwNqGRSTxzHfvO7u72uiji4uToy7Dx4shem/Saui88q/is YdGzm9fPR7WYMTogqsQikRJSISpxnUiClYgAClnPUs+oY3t3NxImwM3O/UhGljw6nkUeVRItTLVR tVqNQ/V/wdQrpWJJkwBgfCPv8hOoZGXXD9z0HbemNDlVRdOmqUofRab4jjCVoA7DZy3q4+tIgdJi jq6B8C3Tt3EPhWFK5gAKhdB2GCTJ+2X1esPA2TEZZ7SURaude6rVWK8S2YYeY5cub0Jpanlz4sVj 27NJyXumWuu1RoBBYKUY61+RVCaHtIFaUCfAN/nVCCZAY2s9Nz93D2ttTIB/OPixHDzoFCKmDgq5 So0qFDBMbIH1x6YApGXzUIVplBrrXrglSyie+gNWtMBZYQqA5wFRowQyiwE8e3u2a2eIIAR3V8+J 2jwHM8JjRE0XYW6cik6F6+vrcQY+SKD1gMEzjbZoJv4TDON9ACBYqVa1HEBAFTIpwLWrzYwQGgiT gcB03pHQGb3zT7afua0wv15kYKyFn9fVMnR17DJnyDQRgcXBUaeI2JQb8jRsdeBEQ22qStpc06xg 6xroU6HkZ1cGLTowYOu1O+McagQSEwM2DCPaWqW3Q8Mj7ggrquT5B7id/WzseDQTR/0ntQIZZCOo kUkaKRwc+gmVNRSEHNm66lLi1fjCrvoyoZKt0zbIlRqSFiY+y2tmu7T3szXUPFcTGZz2NrT85yeu kLRV5fLbR0uQ3hNtWFSNAsS0GILUaF5RvUxpQEelYpECZeiSEKDFJmvpYnGsGtfgttfA/zwD0s6C rYbA1gEQHoPF5UCgBl0OAmEDaFKA6HhAUoHSCkDVB2snA0QJ5Ahg0gEsBTUNgB4DfIzAkMHf3Fk/ 6V+iHz4BE+lMrhWptrEgLSytLjKkFKjin6cP86OXx6TlC+nZVQ3U7KKitDQVv1dgB3Mt8ucGE5ak pqSVF6cUiorjnoXDuXquvQZwVSURL18XlIuQwhKZmb7xuyM0cE38mQWhKv31Q7kESVJRBcPKxsTU 2snNLKmsrkEoN9JGKrKzs4rpHkG+jp19iS+CTx5j+drrFiReeBrvtefYr+4Ouq0Q3aQ1uaHn74oo pgETxvf3Mq56FhwCjh85c9t5QV8thlIkiLh3V96UeKUkF86uHNDLy4TBNO3pYBr9+L5xIbU8J49i 2rHvQJ/s4tL0zAp+cz9LYtGz5KoCOLJ54jifwEEpz2sqGmRmdKiIn1ssl7u5mWW+TAUFyMvUmkBT YX5aaqWQXiCQufGYdF1DKDkh9AmTBwQZSflWw5aOcFCnxCYV89/kZVYg9KdoiZlPF19Tn2Gd24/7 Y8uxsUHO0orEx0/T3bpvmt6TxaEyhZWlcc/KimLuc9nN0c/SHAZ6k2lMkliWGvrwnkC3LDMTOA2c NcQXKnr9Mk9QlpDS0FD76AHdzNTC2dbH0+/Jy2eXtZl1RjT5q9uHUd9ffM2oDXnlcWk5VE5uTT1I LyrOSBXwG7o58ZitOxCFSgtKm9ITo1K8vGxVUc+SYYSYXKl0MbH28OYV1VYKLdgESXVRZhadaunB pjibsYUV+THixKjY6GipwDoj3cnDw83r0bW7F1VSf3pj1oFtCUr/zEJ5lw7+vfNe11Q3yY2oyvyi rFKlY8cOZrkvk9KTM2TZlJBHXGMuz927wxfgXNhcnp45j68UKrDpiYL5HrL4qyePlJB3+A+cPcC1 KS+6dP26xHtXojkB5U35yoiXTjY6kmePytWVKZkVrp0s8AkEbs4pFgoVxl+4qYEgZDN9FiypTY97 XsZPDNemsmKfl1kEVsWHHt//yH/u/I62DjI/E1eZ5jufRG3z4W6eqy/dYKvFblzZk8MrFMqgxGxB D0sbJxdOdV212JSJCCsKM7JZbEdfO25p/JOwGKz7ah4+oPB4Fq7uHkZsVVFiQn5dY34qX9r08uHj GgbbvIO3cXFmekpynXVplaUgK01YwIhM7eEVOGiUz59VeTUSfR2CtCI/U6ztYGjddYK758ZLN7gk ub226P7+DQplz9ScakcfUw2NRsSJj8JLxLUJmYXVzc8eoFa2zq5G5LKs3MZMTpZ4oG9dzPM38rKk yCyHvu7feJlHVJWekJWTla2ML+4watmz+bcHzN9y7vDSYUb1GVnxaQgPDnXu282d04KEyOy7es+h 2X9u2g0N8DUV8BOeFhMHj5zRixSzcPXOWv0gH626y8d3JFIGH17anWXssmBb8NRl5bHhF9f9njF4 WneeDh1zC3xGLNu34tBFo5qyuGQ5z83dXAebf6OPrV+9P8R7xk5VdtiR6GjX+buHOLQVBWOzddHx xWND6SP3ne+gOfMyTlSr9m7E+yopu8PaIbW7/3gwfMg6FoWECfDNo/AycW1yRn4jLkBrTIDOdiYU bSNH05BrId5++mhOWhHdqcfQDmhJfLLAiFteby9JK5ZKMl8W1WLe2GfsQGBwALj3GkxcCpYNAUgj 2DgT3FWAUwdA/GVwIRFMnwC0G8GZe6DTPLB5OGhMB9cSgZMlaMgDj1NA78mgf+A39dNP+hH0w+8B E7UNDWrLi2OjXxeW0/rNG8xUVtSTrZ05ja+Ta2z1WEb6rMK8MnVDo7WLp6O5EeWzCRhVNDx69DA8 KkPPmieqKc3Nz7Xq1IfemHH+3msCm9NUVsMytLKxNWnxR1FRRZFSpShMTUxIzqAbu82YNbedmZGn iyPgZ72MepmQnlNWqzdw5hB3C56xkXVHU1bG82evs3LrtdtPXjjOz9n4MzRTtKEoObWsXE4EqIG9 q4123JHgBhdXfVRk5du7nSFQ1sRHJxeQjWysTLVIXNuOjuZ0CtPI2yzq0aOs3EKYodeld28LujA6 iQ/qGy29/AybU66/gd0ZYoeuQ309Xajy/PCnz1Mzc6uoxkF9At1NCS+uxnBdVQKCXQcrVUpUErDW NrB0dDLSYhuYcYszI2LjsooruR59B3R1AbW5D89dT6qVUwgUcXVJfm6jnY+XiZHtmL7tBWGhL9Iz ipuIXsOmTR7V3sjQVAeqTUiKTs4vsQkc1cVWwi9idAj01NPS0keQ0lcv4vOKEX3n7t38bAx1yqOD zz98XSchmplIi/JyZGSGnZt/kJ87pTw/IjIyMSNPZjVu157p1gyovDg7Kb3GyoBjokvMzKmiCust 3Ts6megTW625oeKs2FShsqqeZezKa7r5NMfZBdCsfLt5ODo7mdQnPX4WlZyVX8Kx9+0X2MnIxMzH GH769FVGaT3ToaMfj9IkJzh4devl7VCVl5qUkFRcd9l2KwAAIABJREFUww70suVZULUdug4K9KQr i548wQVYw7QICurmagKeHDz9uhZ2sFcX5+Y0yFR27h24jDYjLQIBqcyPieI3Orn5WGGhp7o+9OwT XUcnhQB06OJYnZ2YUCDRpVswpFVEfVJdVYWFq132lTDU1ULNsuvsaUbGr3Llnb0bpeMWMKCrB4ui eT4h0LVsDci5ycmxCVk1Rl7T/W1LCoqNXP0t6EgNv6SwJDc5KaVC5jF/7lh3S44GBxTQzL1djRqK klIS0goqzTy9TMyM1UyHAUF+rja6lW9CX0Sn5BSUGbTrOqB7R30WSL+zN7wI6z5ZcV5eE0y1sHc2 YimS7tx/GPGqAuJZkurzcvIFDVQHZ05BVnQZwdzGxprWVCCF5PU1ZO8e3bsPGaRdcOfhs+S0zFwF ldu1Z992lmYO/p5GDcWxifEZBZUWXp4YA0QdRz83Iw2ShQUPdp2I5FcpgB5FVJGXW6ltZEEXZ6TK UYVYq2OQV+XDYJmeKSRite/ixtLcM6ikoeTFg4KAKX30W8KB2rSHL1IFego5wnXv6mrv3tOt9s2b KjqXWpeeV9dAQuvyFSxPZzsDPHwEdEPX7q6GOc+fxWfkVqg4vYeMGeZrI+bnCGGqrbaqsriwshl1 9gvs5MgjtYC5qhoKI16lAhYQ6Vl3c7dkU8ksY0djNPPB03imRfspU6Y585gAkeS+5hMNzMmyuvz8 Yoih06VHbxOtd7EKKi2/cSfR0d/f084Itx+ouj7/1f79Kb6j184e4fyFpVsqg6kkMMzt3Ht37iRV OvQb1NVCn0WABfd2nYjmV8EEnRYB1mgbWdrZmtC1DDwM6RHPItNy+ArQbtDQ9hRhVX5WlpLHsbE1 qkvNRlmCCl3boV5WratBxOBJJH4OpIEO+nQA0nxwPxM4WODxLlsE5HJQzQclNWDwVDBvIGBSgaQG BN8AKcmgUAgCBoLRPf6TuLD/e/TPIGGpVUoVQsIzTv+zmAWwXARR2GRYoVAhOKLyhxGOKJUQSqTQ P8HNfbvGg5ApFNJ3wQCq8eP/KPkzcCGsXBUgkL9aKNKydkxsgUz/OpoDAkN4ok/yV5fuULVSARHx RLMftjaVSiVKpNJbTxIoAiMIIJC+Xj8CKSA1AhjMNnY6v4taBAAT8TN2H3wflVKuJlDorWD01SoF hJDoNArhk+/x1XIiiUomfRcchro6+e6SAze9Bv+yaGiXb4H5/YRQZfqj8wcu5PSdv2hYoM2XrZQa z8lK/Jh9FM+ngckeVUFqPCXqV5QFlz9KotA+BX5GYJVKjX2OjawfNrQwvmBIgbQo0EdlYgwoUTzr wj8MzoKqq3PDpg3fG7Rr1TBff2sDTamQvlYEAsNKGMUzgH8XlBSCqBVyOYnC+Bo6JtpYnpf05Orq 3fFz9/8xpY8HFfPUYWXa/V3jdhYduX6gh81n8einhGk/ih86JmCixQT71T7EsczAPw9mhsBArgAE CmDQ/vZu/U/61+ifQcIikvBZ6p9HDCJiBoqIObYUGq0V6hQBY4Dc2sbhePI4Y99ru4hEosZBQ2jj uYb3Wrj6tskD300jfsvQIxA/cyneNl8DpziM5TfV33IWnfKDfeH3AvhEViQy5bOealEhymctILT0 37cK8HMisvSM2WoZlW1gY2HO+LsZrRBZRWmdgYNHt27uWtSvdMzn7OPnc3DRv1OBr1VGIGlQ4PcC +KFgXC15Pj5xid4zoKlffjgR8HxUDaIGFY1taWlnqPMdyOX4yQW8Ad87rrHv8TxK39BYYVVJTlaJ roVLYE9fE3322wpRQLFx7NrD35L6tfqxEd3CJbElmdU3GYwfjDrbRjWASgXYYP85+/7b6ScW9E/6 3yKlRChTk9hs1t+OllBYIpGhBBqbTftpqX4gIYhSLJSoCRQmi0X/pwPuf41gpUImk2GsarFZ/xaU 7Z/0X04/J+Cf9D9EqFqNH8n+/mCpjWJRWK0GZPLPzbNPCIIg0teS6f530E8F0EwQBEjUv3H+/X+P /qlkDAisUKhRMomkUkE/Js0OqpZKa7OLUkolKi02R/Mdyh9HP55/gEJKcUl5anpNPZWhq/V+y1Pa UBCXF59SXgpTODzWu0spsLQ6rTA+riCzRkE21df7dyqwsrH48YO78WUqS1PefyQcUQjyHz8KSagi WBjr/2gG4MLQS+uO3YNNHB2NtH6UAqmVojchh7acSG/fs6P2/yULrIYgWA2+77jDDyAVf2mPwXWd RnkZ/Jflw5Qkhz26dz9KrGdjrsfAPDlMAV5c27/zTGbHXh21fk42H0gOxvqCMmfQ2eo/zcn/XfoH Bqe68eWrbT6HnIz38vT+4PD2TksRNT99ucJuV8CYE1PWXF075dTIgN09tkY/Fysqjp8L6nJ40MBD vWZcP1X+BdhYVFlYenPMYacud/vvzrpXIdeIwfRP8Z8ukxfnnh+zO6DP0dHLb25deGlC330Bgy8e LhcXfSv/AG2se7nxkoXX1V6L4q5mNUnePq1M/dP0VPv+j0dNCB866u6k83k4DI284c34O6O63hs6 MWLcoJtedsG3RP9ga0Fa8PRR53I+flJ3586l26/qJP+kkD9Q/R4Ly9DKD7IjEHAGzoa8+VcYqIra N/5IeE1rtDVUTayjEBpo6PfsoYqKo46c2XcjVdDqOYogTbVifilAf8hggmuuzJ3QrxsnYP6+xMiT HE7AsL7ttt5MfnFuXYBbr4N3EqUANGU9nNPFizfxUJVMfPXXAGPjgGETJuy+kfwBLkNRdeuPufY2 Fjwel9PVpPPa0LYwk76RFPXF5zbNcXUN8PBw5HBcB45b/zSlGvoypjUKg8xMAP9AR1mZdGz3ye2H iiVfhrb8hwm/git5fmbvq6JKdcvyIaYADdUSXAH+/TsT/FuAZwzW3sJ/rs0BK8aBwFngdfG/VKYg AfT2Az06AAMu4ASAjcdBpey7CkIAJR0gXxOKVAAuLgUPS76rCg2kEqasuTCu295RwXwchqax8tGc fQHDLywOKWo9cv8v0A+fgJHc5C074jcky80GcrvJIalQIUXViqa6yCJZzI2GmHvlj2Jqb8dIIxIl 9RAqzauLe9Xw8FHj8ye1Zx4W1bRdLIHNsB3msKi/kTsCVN+yfihTysRyucb1dQQSN0sksCZEf438 ExC4Rlp0QxoTJohPrk1Oaox/Kop5UMEXqcS538w/jebQ3XbNSCM/Lqomvbf/woY0oVJ8enTq9YCZ ufVlYfxcBQAVJS+r6jJGd7xQuSJnuzahqfxi3leQ/FC5QiqDPrVKakgqVeDN/wKIUQvBDbWSj2Al aHo2A+Z2sfQ0QglEqVTZ6mUsqJKKFSrNMNCt35RIFF/f34Crw5qFzR8NcBrXAWPA0MkAY0AiacUA CkEKmQL6LJsFAkOyj9uPihqleIbVVkRx6rfqyP4jAzyNCZ98jSpbiw+05I+XKD6SHqqUK6Ui1Wcn VcgM3X7zf3txf4F5q2wWSqVC8bn0EYUC+lI2C7K282CvigqfQC8va5eep9ZYx2b4d3M3MzLkcYTP I56FlNZLU+6fiMoVLxnSgUulefZdMNw65t6V+3fOXSh8lxRE+nT7rGXbklecCeOn3R8a2yQsLP8+ C/qBKZZ++4AOjlw9G6fJh3ZNq8262dd7fUJp88fvoOqWkPuvllHtDzaLprlpfdp6GD9xjWhsPgLh BbQtGVRWIhdkiZTKzxwzHFtE1RYycqv6MQ1SIi3IIB8+RxC5WKpQfF4ALBZ/hjlKZHv3mzQzyIRF e/c+pgBjVmzHFMDkM1w4WCH+2vj7AqmVkneIsW0S1xHwasCd30CxHGRFgifPgJsrsHmfUEEpARo0 8GukZQPGB4AcD3DmOrgwCfy2Ggw88+GvsBJIxUD9LT4QC1xBwapunzxDYByoC9OSvwrAimquBxoP gGH8SySay4Yg0Ib/p1bWx8gTo8S3JkZGY7+mpJ05KYp53pyeKMEHgVIpqWsSNCtbawusUoolks+t wD9NP3wChhvlsAQCozx/2Try8puui9hUmMLg9gjYOoWu1cNu5K2Z1xe4De1gsmlN+956DMedU68S AIFBYTeKGx7kJUnastcEqpGhz7Q+U3xNrL5SP6purE34/byP0y4Ob7eOy4HlkTVNalTFL70zY5d7 nzNz9j7d3+9MJ/092qtjIkQa5K2Bf0Bhu9mM32Ti7mHmu2bIoQ0u3Z3JNjv6j7TW8fj9G/nHlFHH tG/32aOdvVmYj/b+ob7ZsD+7J4y0s3C07tgekPCbANiYRWphRKrNJMpVFAqKxVVJEkWbetGYdKUn S8vI0MTBrf2mK5G4BUZliff2d/BwMjU10vHxIlAmZLaeRt+TsiLsztX7cS+Swm5fvXX1ZsjTvCpc 3dWAwY8N3TDYwd5Cnzptf5EURzRSSQQvzq7q24Fram6o13viqahCaVvTsKr23r65Hs4WpqY8tueE cOx7lTT+6lb/dp0P3E4tjbk9vLODx+DVaRXNTYXxl05cjoCgp1fO3bp6/eGLuCo8HxHOQFHkPYwB a3OcgRLZ/2PvK8CjOrr+Z91dsi7Jxl2IEBI0uGuhAm2p0Bbq7i3UoEALlFIKFHcomgYJgYSQhLi7 brLZbLLucu9/N1RJ8pa+L1+/93v+Pc8+0F7unXvuzJk5Z2bO/H7eWoC1XTVbXnwolOMn8GPPf/rD kjYN5Gh8XcCZ+Nib762Zw2QFp2W8e7vbDNz6ivxLZ3Iyb2efOXXm2P79+3OqfZEvZFPv3ficTCJc 9PKGwlbDr9aiLDqxfCyJw2OHBUunPPLCppPlLuBpzNodHazgCoRcGu7zs/UQ5BxQVpy7cDI796dL F44fPHzwQn79IMynt7naXkqhcscFvr7z+s9DNQzpWgs3PD1KLOby/JjpqzdXKO0uizpr2wcZ8XNX zJuSEsSiTFp5rq53hPojRsVGsxJmz0kJodKks2cnE/Djk4PZZJZA4Iepbumvrqs4U2hRDcASuQSJ wipSM1JGcR5777Vkds2l4i5vkdbWW1tu9j3y3aaHxkcwpGkfXn0P391r+89GFjSBFpmckZo6IyJ8 6tKVL984tz0yWK+xO4Cj8Wk6QzH98T1nTr6wNI3JDFi9bn+XxdN+ZUtCmDQ2bMqxujtg1ABymWpv HFw4IYHJ8aNTp7yxJUtrcXpN8PiL0/0E41/8dNe6t59m0pgTHn65oM0wVAG3VV95LfN0fsnVksLz hw8eOnC0sKXfh2nmNJ3f+nI0hcVlsxLSZxzLa7QMjbvuKGDX3tj/8pR4NpfHjQjDxq7c2qm1eQ2g p+jEI+k0vljIHZW+/NtLvWaPvfvWk6kz5z2welUqXyRky5/9ttMbyUMebWfVjtfmxUoDFzz6wq4z ne7BVQW7vtJrAPxJ0V4D+Lmfubp3Lpo6Zd4Ta19/0MdywVp0rsHHp+KxDBT9uGNyckTcrGUfv/fS BKl47cWRyNY8tee2BUjEXJFQxGd/ldk0YmxBCQRSFHBA4EYFaO4GdUjAZQIqBTReBdGhPn4FLh2s PeJDf+uqBE8/BGatBm+sBsFSsPgZUNkNhkWzw7PAxHQQPwqMSwUznwAnngaeKh90ttsILm0HExOA UAzoGeDYbeCEvO0KanLA4vEgMgG89TbISAXvbAMDdtBxEYTIQXwEOPbLN8IOcOsEmBgPBDwQEwGo C0GvFdjawclD4NYV8NMJcOwwuJQP+q2+vHJ7N/jycSCWAZEM+D8OyruB2wy+/gBII8AXO8G2N0Go HFBjQecwkOx47rivQhYG4GleHZodfTdrTgPATeItf9ofHDi/LP5Lrv92md/noZ8Ulto90ED7wXEf RSR8Hjn663D2Rkb6D8uvdXXfTaL3Pyn33QEjiDgOF885U/zGk0fWnNQzN05+Q4pGoDFUKtpU237m oxNr9zZXIElUChqLAPCAqhKHIb836eBz1G617mytzgG5rX36no7+jo6BwZ+mTWP9eSHRA3tc0J8M JNb+0reyX/+0r3d66DubIp9COvfM/OGRfD1EwrM4LHyect8nVQc4lIRJ4nTH8GBuw+mPAhg0kUFm dGtKvsl895uqwl63iEWko5FgqP7eUo1mtXLgF/0H2rr0v7AVwpBX/9+H737BC18dG6/tqz2W+30j gS9mcDAAHah4iM2O3Xz54Rnbpjyvs6BFWxJYI+4s2W2IjI837z98+K0VaeVHvqvosbsH6r7dfzrj mbWF5cXnXpoplsKokbqvy96v6dPaSBiTwfcfA1rLnXgbhoBKl/jCofz8nx459+KeApXX/VZm7f9i S9GUdy6Wlt46MNO4ftHbN6pUwxfsggi81DXvf33i1L7XBGcW7yuCMITwCfOWLMtobDCyYiZ/sf5t JoppNLncDptaZaLAsEnvfX+fTm9035kbeRVQDngVKC3M9Cpw8LbaYeg6suX1/ZX2rVcLi/LP+def W/3W/h6r8NHvnrt59JA76fVbVzeNkRbs/bHG5XGbDNp+EwJtsWn7NXq1ut830AMkjrXgsXeObX2S SdOqf+HhcHZnzxv7YseMPQWlpd+8vhpVq7KavGOSx41hPvvG+4dPn/zm9VmfLN/W5YJcVlO/zuqw Iuw6rbavb8Bg/XkFBS15dX/uV/Pm1Zb97GlcAxVvPv1OPm7xxZKm1ppbC1w75qW+0YagR6cnyIQt Zlnq7szr6zjNP+WUGUeYnbg8CKit/Nz58ydO/rjvx2twqNvtO1iMD4meNkbBvLVnly4gYZy/p62v 3wPBhtbLW08zHn5oQbgstODU9V4HpGktsdAypsQFkwbPSonSnjl1+BnBf7w36fFaL1mvRXS0NNXW NrSgKYCIQQCc7I2bp6d2H/zok53cWe9fPLP7gSkJZAxSmPTAjxfOzh641X4nTIFdzbdOfP7aBsmE dRUN9TfPPly+9+kvLlbY3ZgJL2/Z+3Hcd598Xd0bl5l17oOn5gupw6BZeCepFoPZabQjbBbdgEbd 12d1OL3us/SbRx/9tuDDS7eb6svfmBv59brPj+S2DWuWFnXDxXyNYtHe26X561bNJmJgBwy7e3Me GruCuuRoUVlp5vuTzDvf3L7zppsXtWI5t6Lycvzay/UllzJy1h26rTJ1ln/32VtntYGfHTq0IknX 7VHfGftx1FCvAXyYMe1XAwAY/tRXlnVW3Gikz62pL9nwcNk7G27YIWvR4Z0fvXMk5enPNj83oyjn rGbKCw+mykeobLcbw3nlw0+P/nhq7RPj16/a2T3iPNYFnKFg9cPgyE7QqQdpMcCq9LEQesehp14G B0+BQ+vA9tdBoxXw5GBcGGg+AqwMsGsfCFWC1FWgzQSsBtCjAmq179erAgMGb//1vh80N4K8m+Bq FsgpA/4KgHaCa/vAx/vArA9BRSk4OA08OwkU9QBNOUheAEIeBds/AcZqgBKBWTMBAw8EY8Dlq2BS B1D9svth6gYXzoKY2aCoGHzyJIgkD6pvA/1aYMUBgx5o1EBn9Dl12AQ+WAIOAXAuF1Tmgmch8MRS 0IUAK54Ez6SCne+CMgI4eBJ8+w6gDItFj/K4dT6UUsyRrVe2XLIz6Fg8jiTG2HX1Vnqw5LVtoz+f 5Q1Lrp3rdbvQOI6IoKx2D5CYs98JXgYGfnztxu5ijXZAr+z8bQzv7DWZ72V95d+Q+500AgM/Ydrc YDuiv6rfWflD1b7OchmRfXuaj1kE60YRLAQDwWbDwgif74NNl0uOumFCbt2PCDOq11WT39kZLNB+ nf1DpaYfP7jQ7Hb2JKXufT0xAPgWKXxLt//6/JxB12LSd44PfvfV8Y8EUPHhJzsmN1wv6NGnhSUs SnnwavcPiXEfr0ufRka4B1FzhxQ1vP4lC5i+dzuRVjPG4EHDLoQLRkDwcPrH05k5tzadbqw1g0Gy B9iI5T69Y/HcQSA7xOCZO4D4bb3Fremr/Pbyq9vVrofD17wYHYIC0ICh3W53KTiL5oqZmCZ1nalU ZZ9DwQ83grr0t6oa++qrz1/sdaEHWNhY7/vQRHZMQMjlwivfa9p5eMyih1OIIyHxkhXLnno+ELrU THh09YqQ3667HfipCyePi5P5ER9cQX+3uteThO7qbupAISxd1VkDSKuBIg81eVDOO8jVfxTIGz61 9Db+eLnYbjGbevAwpt0CxpPJTD6F0dgOY0kUiZRHcepRLsCKGvfKh9ybXx964JmXFwXi/6DAnIe8 CogHFfiiXvWMzNZUUojAzG0qu9EOu/BsEbbRarXDskAxjvHw8w+N4Vi6R0X2XGt2eHDsMdMekCJq iptGr1w+8XdsFmgynecviaA3K399j7L4XCP+geo3logBCBE97heZ7iTwIENXc0tXfe7Zo0qnw6KB YbTJg5cGjVnxiMUjKOClPvVgzO8h8FE8iTxAKAI5P/9/f0txU3/Ys/MWRYq5KMB97N3Np84+War8 eDqZ4Zc+Rx7/eGy4mLhA8nK7weH0TvWH6YAIb2PhHQ6H3mwGTt+6ma/tvDEQFo8dH4k9s+t6zHOf +Jvyen3HTt2VZw72UAJbSyo6LH0dmuzi1hmxGDQS6fCGeneiSySSJpH8at4eu83uQaAJeOxfP6aP QOgbb+XmuNoxnZ269GUvxwjo3k4tkAYH+8tFq799Y4Lst3uxHBGFIgtEau7YB+To6FSZBZEvPTtV 7o0meUtfHLdrbW23a3Yciy+Si+XRY1Zv3bmSNfJ0AENmpsxd3Nfelt/LXP7cC8GMO/ZsKtlzkvxo 0bzRPlaDWYsXFpV833y70ZIWMDQZCk1gi9jI2rLDe0EcEQTOjgyiYFDamtv5gBBvU+ZkdlhNVpqU SmGYXTCJ50enL123KCWChkfPXkza19qv9TSqe+FZrzw/ZbQQpH7Vf7S5b/DTEEiM1wBkXAEo+PVV SJ6Qi6UvePbBiSI+c9riNRuftTntxmpNMyE95omlM0U4wOz5/nWdkI0f/oMd+vaGZmV9wbmjSshu GoBgqo94bNihOicP9LQCbyzSuhtYxoIEGTC1gpvXga4WZB4AP5UCKQQcXHD7OlDjQZcORKT5prZu GIxdCr5bA85eBOQmkN0IBmHFgMcJuEEgMR646oHtAJixyXeR7Qe2vAhyL4NLJaDGCFgXQFsO8PQC b7C+6yRIavc9myrxbXWFe//sAPUVwNb2s3q2QNBcDHIGCTmdWtBrAnmngaoDsKhgQgSovgXQKBAR B1RFgBsBwgdhPBuLQW0PyNQAPQ0c3Aa8wbOpC/SowYEzII0H9DaQOAVMigV2O5CwQUUuGDduaP31 6mqcpAXvcBqfK14byH9+nuOUxuN0A1iCJ6uNHTe7OpsdFg8ehwQIMmfMitAJhUrNy1PXTiY02rI1 nza1tOgayku35mgdkK/rwTASE6h48r2McfcTk+gXud8OGNJnV+w5p3ItT1sXR3XuOTbxA31LTU9f Creny0WIkEx8O33x1cKPzwwoO0x92P6cXepGFHK6P8mj5yQ5u2uzmy6MpiVyBEHRVDEZ6etDZjdJ TCMMHsFUtXY3aMwmPaRu6G7myvwZ+GHsF4Mjo7HEbkNNlaoBGBzZpm4EgsElYExGZU1vZz8K5bBr mrsbpFwxmzAc5s5w+teqNNMJ/T0mtYiZ8vSYz+DmT94pKVRquxrct4bqnyGZz2ILQt0YD4LsU89t djOFaN/On65DXduu1+idoLm3NogSKaSQ+zp++DRr4+6BvnmBH6dQ1bdaS6cEx/b0FBiNxoWp81eE RgXobzyp3Fo68E6QcBgPCmtLFj7zwbbrDe9EkMvPHTh8rNQHNOXxcIKTFsTQWAyip794+yNroh5Y sTycMvTxO2J3wHpjn8UhtWvVar2TJZC4PC4C5BwMkdxEcZje7oCQSBSeTqHyQ6OjFQyM3SoXKCwB fMZwY7i75sL+U03k1Z9tT/VznXt92Qsqi9M9yDYBO2xOvcli0tVUGdFaB3pwoceFIsOw1mx02Fwa ZbcFIogCxF4FSJBrUAGXVwGD3YVAE8l+gVRSWGxsvDeeCBELwuxcDg1r7zYi6CK0G4Y8HqfD7oEG mcoRwOUGBs2A2eGwmrzutBXBj1BwcS6XyzsQugZ/NocDi8US2XyPp6y6voctYzq0vf0aLVUg7684 9vX2ogc/Wv9Wiqj9+pfjH6v2Pui1LA8EzEarwWiyWjGajjYjXhgmZSM9LqvdabXZ3R6XzeZAolBY MhON07Z1dZkdIjLC0V5d6URKWQS0x+5CutxYb4QFPAiC0OhCj7SE73E5YFLM9DkPpcVwzcWWzw/a nN6prt1tN6CDE2c/7JcoDQtuykE6bG5rf+3uH65Ne+YrnNMlVoRzVQWXr+XFpAVJ+q6fzSry50wQ UhF97Y2FddaJM0bT0LCxqzzzfFYTHLZ04SR/P/Jf8cC+bXaXU56UPPulF0fRyTQmjeg7ywV7vFXs HkCL/WjekAE1CBPiveh0uGGEz2vYvBNVh8NrJxgUzqIzNCnVwTSOS9de3mfhiIhIBOxwOm0uB5LE RvkOLSExaPSIgQGEwHkQ3qaz2K1mrbm9uZcZ6s8OlLjrq5W6cD8SoretU2X1BLCGz0T2No00eszk IFYAG9Nbvfe9D+sTJsUlkGhIFCswLDSBT3I5w/wVqSxFEA4FOawOMhIenHa6YKLC6PCgiAQ0wtHT 3KGNoHm0TU0WM87hW6qEXE6b3fv72QAQKB9+idNqhckcjMeniM1qg2GXB4njsVhQQWN+bmkYy5xZ 0O+Sjoh70Vd8bP3W+te+2/5BBLviwhdL3+nyWSBhuNne7t2g0QVyykHqCt9q8O0y4J2Hd3SBgkIQ ngQWLwTKOtDTAo7uBlwSUDWBgipQ0wOCeaC7DgxAIO8soOF8UeCdlScEGmhawYUWoGkCOiFYmOGj B759Dqx6DUwNB32tgGQG5n7voAysDuAvBt3XQZ7XoDVgyeMgiAo6GgFOBPqOABoWOHwUNKC+HcDH wADTRzUFm0Flgzcy8zk1owoc3g9KJgMBGTgQjzV0AAAgAElEQVRtoL4BwN+DCgboVQIHFoi5wKYD 2D6gZgACEhgRwI8Ais+CBgAqKgBM9HlfHBpgMb5Z0RAH7LRpVU6v1Rn8g5c/AChJgpiC4sNma/21 ulvflJ0JDX/mcYWEZiloNrW19+uEfhSPB5hs2qKWKyRCb5tWKaKFsPF0hlAazvBGFr46h2Akx4/7 P5Teft+PTcB2ABd3H+vOdabwxe1uVwBzVoqA2NRw6YbDQFLnHr1hKdeUFRvrslpji+u3FLsdGKxt SdrmpvxVB7pV+e1nsmUpq9NeJN0FMOwyNLaffz/vSIu5qR9u2aDz4Ga+MkEkGQqIQGVHTgycVV10 ctP1DhFSd0Ltmhv2bLoftrH58lclZ9tdqqt1G9uUE9dkrJouVwxn0cPoP0ZM7dZc/LGnvgtPzKw4 6TE0Kz31xyuvWq0Xh+p/riVldcKa1CEUBZ1eX5i1/qa5pc4OdtxSGT3vPhEdejn7lW1qAxZDqFYf LGrsioh4b0zQKIEgJZ51MqfqG6OaV6WsTBaviB6BtxHGsqbGsm9fPKa/6WrobG42dmVfvSIdTT5/ 9kfvHDU1RoaDTIEhY3nDL9T8LGxZFPz5zvWe6y69FiuInzrRWXu7pjSvuHJqhtDYtCervRNxuOmx TwJjR0fltBVmXuoUEM0ao9nFDhw/7LoYki7wZ92uuH5yX4nVY2iBnKpLuy9lvDCBxWUBbeaRL78o 8XTmdDVD2dXzE7yDJV44OSPu0Heb+/koY79JkTxzGsWVc7umKreictoYsaHOq0A76WTHwpfSpsxp utD0U5abgXEqTSYCb8xUV//lg9ccbegfLoxdGtJflH21nAAKWqInKJgUYTC9KGvnljYKrOvXY8Y/ JmHa1OcOnWtQVd1u0mt6DLV+/nOXLwiPXbBsZt6edz8ujhFZBpqae0nzFgdKgiQy4q3iS6d7il1O XZ2Q3HF6/zX505PxVA7TYr65Z6vmGk7Xbw2YvCJYzOq4tnf/LWVn9a3W5qpNX9aFxqaMTUqaPbvg 5vkfjJ23yEhrZWlF5LLno1ie1hu1V7NvBpBHtQplWfnVtbc7K+aPltIFd9cfZC7LLe2vytl7KUJO p333fZbVwc4qnUCvKc4qqHHWaR6fO9FSfOxGs7LxeCYju/a4EjwLcaYtntRbfO7k4SO5h4/PSnhz 2ZKkTRe++1JVLKKjOmt7rKz4lOmjaQDWdVQd2fXlj865cWlJ8r/igF3mgbIbF3KKcp2EniOZqAXT 09gM39NOTcXmrw/k12oo323s4IqiEsdlTApGmTqPHMtU9vUW9zi0e7/C5rO5sdOmhyVmSItO7fik Xia299aUWYOWpwTiQP/xjTvzG/K7SilfftkWHB43YdIkAXmEsQ5FCggOc5Ze2r1lI9PlDRm5S954 NWnNG8nrsj76rEvBAKr6RiBPSEsPGxYO3K7rzs08UeQMnx4ndvahAxLFTDyG7jf+wVlny85l6oPZ bqNJp8eMYfu7TF0XC1pqa7U35qdPQBcfyW5o8zuvnTA3JkF28tS2TxsDPO6+XKuafmbPnJRgfMXB o0XdTSWDBrChLiQuZdK42Oortw215XvOJkSvDv3p0BWNSXaqctyMtOnttf3Zxw/X8zw1rQMo0YgO mMiV++PL8s4fb7xqMWnqWCj1uWN5khXjaUNH69WzwNHzICEdvPo00FaA9e+AFhZYtQIwPgOkECBh gkAhGDCD+DTw7GOg6iD46BvAjQdBZEDFg6AAsOFtwBsyDzF3gm2fgIIOELYAvDcfHH0FfFEHZj0F Qpxg3z6AEQCeHzCpgTwYPPA8CMeDzQxQhARRbNBEAPgo8Mo6EIQGuw6Afh3Q3wBwAIiQAVEMmCYC 6zeAMieIjAYorS9rbP03IIrj87VH1oHjRhAuAHwBCJsA5o8B57eCnAbgHwlIKNDHAOOCwOzZoCsf rOsGEB2EhgFiNFg1BTDuJhPzikFdlKXr0xvPXTY8s3PmzrKSj1/U6ySISwXoBAYR36zNO1TN0TtJ kP3Cd+WLk6ekeB8xWnozi7fkQzodhvVc8rRobiBP+un0EXvD/ZT7fQ4YgUAjiFJunIItxKOJIvHU R2JemCTxQyGQfEHSeFlapJ9/hDAqXZ6YKIiTskRx8gkZAWGxfnFMLD5EnJYuTY8XhEmp9KEogU7Y 5STQ46WpadJRYfzwWEEIF08Ymg6NwtKDWGGRLDGTQmMwA6cFL1+duERGwjgBhKMJpyomJEtigv28 jwf7EUnDLACNoL83giOwwifKxyUKQhX8kARpeoI4JVYQmBgw8Z70R8AeyOVCoeXi5Any5FhhYAQv JoBKg1HccPmkDMXEWH5YYsDMyQHjwph0ClkQwJDTSVQkhhGqmP5U/MtRzOEBchEExqgQiW7ABAjM 0MSxE6MUDAbH31/B5TIoBBTC43bB5DErnpkUIxqZSw3QeAqJW2+AMQyBf2JKaggfb7DjvUWERUVz YEM35J8RyguMSgyUSMPEbKtuwAwBIlU8enJ6VCCfMAxQNZLCE+KR3jmEk8hQTF0xJ1RCZ/AVMYF8 FotKxdvtMD4gPi05PkwkDw4VMTEovCAuxNKvARiCLDQqeXQin+jut+KDuWyvAlxYp4QUE8OEgVFJ kWFBQhZS26+DkBhmQHRGeqKcjVZ1OmLGy+ncgBAhzu1CyhMUMqlUzCAQWSJ/lNPkcCFJjHCvrjEy tN2gbFHCTHFYYKCAQcJh6cERQSyWcHxyNNGoM3hgEi940oKFk0b7M9hCMQdndpphHHXU1MXj4wVE gjAkQkah0PhUGspmdmHJsiivo43g0gim7vo2HeQnCRwVLyBgMRyhROYfmhwbwUV5dCaTC2AUqQ+s emKSH9Zjsnnn3Ky44AAxi2iF6NFCTnBkrIgxpGVhp1ZtEQexmbLACAGyrR87YWKgQKrgUhFYWWCg v0wiFro1XS5usJgj9aPTk70ei84Ni5Q6jXqIKIoJiw8JCUuclBwlQJnMdidA8/1THls5U0L3BqsI DJHBFAaPGjcmPTaQTsDcuwOGXL4NdSybHxrEwlF4Qd6PoPiiX4+tv7JZq0gfI2YQMVgaXyiVyphI t6W5TWl3IqRJk0K4JAyeSOUHJY0KC432JzgNBrMHTxPOX7ZySnwABmlvLWtA8BUpSWIiFsPkeZ+X kkeE+USS+X4EMsZhs+Op7ITxE+OCJdyAmOhAql474IbQwsjkB5bOGSVjDYsRgERiiQQixTtzcjtR FNH8h5cmBvGxRG56YpRTo9I53VgiJzQ2MTkphIZ29lpJsQKWNCRaAPr7IOn4UGFo/JioyFA6weOd +9GD4qaNHS2hk/0jEzDapk4DLJAPGgDOZwByMdfSb/eP5FL5iqRwuqrdHjFOwRErRkWGhyXEy4Rs SUgsX5dXSUpZmBKOGw5Oi8AQSTlovd0CCPSkqQvTYvgUsigwVDzMip+mEwTGARELhIQDpwG4UEAc DWKiQVKYj3fBhQHR6WBcPCAQQWAI6KoBdhiMHg+8LR+aCp5YBgQUMHTBwWkCaheIFwKCH0gKBIER gAMDkgyMTgJytm/P2OIGJDpImwaiFYBAAqPGgiA+EMoBzQXMdhA7EbBRoKENOD0gIBUoWN6uDZhe z+oPKGTfejUCAhAezF4KkoKA9/PRWMARA5vex0MaEAGSRwE+F0TEAqoV9FuABwG4YjBuCpAyfJvE FD8Q4u8jT8TwQJwc4IeZQMKQG0X1T5ElxwhSojgsNAzEfjHjZGmjJWmpEjmLSueyIycHZSTLosL8 YsLpmMra40Uu2apRD8dIYqdFPjY/KJ5D+PvokO8/EtYgF6mPk9TtI2jFYv93ANtgH+sCDLCYfzX5 G1b+O/QHbrfT5YHQWPyfDpMelxNCoDG/6TmI+e9bHfR4YATmXrAsfCu4Ps7YPzvfBQ/SUQD0n5I5 QB6XG0Jh7sYDhwYPoAx9zz2/39s43m/ycRbfg/OAfS2JuhvjeJj7vF3W5R4kQv6tDl0uN0Cih/Jl Qb6znwgk6k93UGFvA3rbAYv9yxZ4v8Tt9BqG1wD+YEGwt1cg/iSR4n9OfA3o9iBQ/wFw82AL3IHV /vWSrwF9kCP/GmQbHhzrEJDbDSP/AIYG+7iSPah7wOi+Y4C+h/8d9T09VVmHMq/XdFi7cnJi3ty2 9oE0/IiA5LDT6UKgsP8+FI3b5TuZ/uvzhm6wfR3IVoIJM8GU8SAiAIxA5/Un4nEDrwmh0b94bhiY esAPn4AOOijJB5ETwNuv+FaMhxH455xXyOM7HOwdr35vhN6BYXBo+MOygMvpW8f+62P4SOIbZ2Df +PFL93VdufDgh415tS5WqmzG/LDHH4oI/JuhdO7/67wD2WDDeq30f23oGWQj+Dff/t+hv9fCsfcI bIfC3IX2h7hD4YC4d7Ban0u7p/t8Y9y93IgcotSdyyOwS9zz+73l3vuogbhHZe9g8d91DTN8t/e5 3nt8O/ruMv9uGVYBxN8A7j+yIEYwjL9WxN1fMNiAf24XiDthB2pIyyJ8gfY92dVfM8AhT6MJLDaN I5Wi09+bPX5CHO5f0YF4Q7f/zH7uGgC97i0oBsBygHX7Eqb+7WmXt6f+oQERAIUDTBmwosGDq8Do FMAeKVfpl9zTu0sYFO/AMExGz33uQUPGGRSLmZwRGDEViQIYPymF+vdPtv7Bgv5H/pF/5B/5O8Tj ctpsNu8EHE8g4jB/vopyX9/tBjYrcEM+10sgARzmvnEfwRCwmH2Z1Tg8wOH+J8AV/+fE6TBZ3Z7B yAyFxxFxfztu63+vA3Y6nEgsZuScyH/kH/lH/hGfeAcxl9uNxvwHs9O/SyC32w0j7omR8h/5/0D+ p8gY/kNxqbNG7cvQ4KeM43H/9Z1up87kwuL/oQb7V+LWdpfu+nZ/m4sVIuP8H68pU8mlH7//7kQ3 TqgQMjF/7zAGeZx2p8N3lhv2bUH+/xMcOvW9ead++LFMxZYpmCOcXv17xNrXeunUoT0Hj+bV2SJi FUTvlAV2ttw+sWb5W6TxcwNHOC9wX8Vw49iBXXvP6TmhgVzyXzRA560NLyzb/JMkbpQ/izTCo1Bj 9rHvdp+28kNkrL9a/j/yf0zuc1+CbJ17zj075Yuk9A3pg7/Fn9/Mt/0Oune4CTc89KIHABKGhLj7 +p07f3+/edcWZtTuA8NB3Q5T7D380693/PHvIf/wb178C/LnSo4kLuW1sYlb88s1vzzv7cXW1vIT Z66OgKgD/8m77DrlvnceEnGiQ+QBZK+QiIpJz2W3KM+9vxhLIDEZo8YkjArmEf0mj9+w9/AnT84e ExnI43PJ5NiZD76eWTnwpyAy8AiVNcxVCEWhkluzT5Q1NgyBhPaJW1f97uJxUaMeyWlWuwHcmflh GI6a+OGFX9kI/r06hWFHU8Gxx6Yl+fnxGRQCNv6l/Ob+P5j1f9bc/+Lxeyn3L7x7yK25u5Yv3lv/ rx9CoBDdva1nL/30K4jY3aX+pxUwvNxVJmRsefPNV1/YnQNhCdrOXrPzjmUhCChCCIXCvO/kXcN+ FISmMymNF/dVdPd6/vI3I0gyQlI42+93ebb69uJ1YdFXe3+DyMOSabVnD9xqVHvuvVJH6kL/yH+3 3OckLBhAnaDvlqMEQxDxiESzPv+NK8flMtNiAdFm0ygNnRqnC43lyOliFt4HdeWwalp1jX12BJ0i IAMXCkPmkLkYj0GJkm+dvJfG+gXCB/bY7f1t2jaNy4PHoN0eRghXxsQhLTaLGwVgFDBbDW4ECof1 LeLDkENr7FSaNEYIRSZKQpg8Ago4ncZefa8bTaZicDpLR6/NIWNHCsiUPyZ0wA6zobu/326xmU12 OpcND/QOwMzwaAUNh3Q5zGplp0pjgNFUgVTKY5HRSITLomtvatHZXFgCgUamcqRyMgbhdlj6ujpV /XqAw5MRCHZwFIuA9LgcGlVXd5/WAyHZAomIz8b69htgq66vu6vPSWEwsG6L3c3giFhUrFXf19Wh 1FmcGKKfIlhKHw4vaSRxO2xms87tsVtNJoMODZA4Ko1IZ4WNnrziaJmuvbbCYkXxZTIuk4T2Rddu raqjo1Nth7EMtkgq5RKGW8bDkLw+NnV0dRc85rVNEVyks+fdt0+o1P3W25cWf35oOvH2B5+cffWr 7fV55QP91MVLZl4oE7/y4czkEOeZNS89MBZZOfCpdIRIz2PTtTZ0aJ02r5piqYxLJyFc1l6lxo5A o10Dyn47QSAPl3Awvqx0p0mr7tUYUX5RM1IkneThC0ST+QnBzBOX95+/+UScEHX0iw86cCmHFybg Ibehr7eru9fkgShMnkwiIGHRDl13Y5fDT0BzGPpNTsDhC5lU8rCLKXZN66kju7T+U4v3PNObte6p 93QGg3MQ88Pd393eqexzAjyTK5KI2Hg01N/eobZDXJEAa+1v7uhDEpj+cq5tQGWwIsk0JoMKVD0G j8eEY8ulHIpNr25t7TI63BTv8yIRjYSx6/o6egxYGpNLBc2trQ4IL1OE+A0FaIQd3dWNNhLJpNNC KDqV6NBbAV8i4+KdXUo92Y/PoSLVjbUaBEkskjOIKJfd3NutVPWbkAQCGiJLA4V0IsJsMBs1aivT rDfoEQg0gUgcNu0fQ+GMjktWd1/RD/Q16E0IPI3P55EHU3g9dmNXe7Na60AQGTyJSMggj5CmBjmt JmVn14DRTqBSIDdeGiCk+iAgHP09XcperQfgmByRQMDAAltPR58bg0M5+rr6nRRxQIiI5TUAl92q V3WYjdEr56YtWxCIIzM4g/hNJk3PAMZ/+bavuJxfqwi2m3S9Hd0GPI1HQXm7AZYmoqMsvQMOtkBA gkxdqj6IwJGK2N5u3VlZb6awBByqua+7V+tgCyVCHgMN2TU97R3dOheMo0nlgXwmFum1QIde09M3 YKUEpc1O4veMcDjf26P79CajCSsPFlBwaGt/V7PSSiaS/aQsi1aNDn/0hTQej/MzG6bHYentb81x efzVWgMeh8TiCXi8LHHS4iRegV1bWVns8eDlgYF+tBFRmGCPrbu9TdVvhtEErkAk5NKHpO7/I/+9 cp8dMIogXSZMvdV8gxP8/lsxcZcvpD3fY7K53VZL24/5X+6uzlShCSaPeH706ucTJwhR+tM3P3/7 1h43SYiGeEyoXyie/ur4t/gDmc/n/qA2dkRH7dg1bby3WK/zulX4wVuFx/uJYpRTqfTMPL7skwym 5cDN/VlWYHSf35qjpBFEicGz03iEru7r32avvaQfcABXj2f0l9PeXRIsVfdmf3z8nVpicIpfUJUq M1dbtzL9wrqUCbQ/5GTCfY0Fn2zYXFTeiwUmnNifrDF0qbWrz+Q9EYEtzT783YGs2k4dsNMiJ01b tWpxlIRaeuCrj7ZmWphYp7qbzw9bs//EWBG6LffcN5v3VxpMdqfRXVSxoty4Kpps6e88sHntgdx6 rNsoGbX0/XfWhEvolp7KA9t3Xcm83R+ZFGhpaHIwVr3y8bQgy5lD+/ZnljkcTuuAYO6rjzzzwHTm UMyR4QXqa6nOuXRV3d979Rq2qx4HkYIXLR1H9rF09TRcv/ThgKu6UJf66CtvPD1DxsRoGrO++mpf ZlkPEWAprNjHX18+LTmSOMQoUFiSNGp0+tiWHkk4n+wmsBnTRud4I6YGA0gYN30ChXlxa9+EObME ekdpl4kXEs4OdoVGhCcm+AVuKtkxr8pgB2D4k8xAX535+sOfddNJaBw+dfFzL62cxzK1Hfpk/eVO qz+5t0ppqKeNzTq0IZYOOqpvnj68O7tASZXKLUUNUZEjJJFgqEwWU+IvyMtr7EkwHagW0BE2Kpvt tgzcOLRt695LRjxAcSNe/vC9aTH+qsIDcx48mbFyIranoapbl5zx4IJ5c+KCOUOzUz0um5PE4MjH 0gkUwbRVGbcLqCRvNXn66i58ufnA1apePIxnCROeeG35xGhuzrb1X16tTH7oIamhfN+FEhwu7P2v nq3f8/6ebM+kh1Y9MRW97vnvKiytGa/u+nSG8NC2z4+eLLWRkBQ6b+oDzyyZk6orvPjehpP97NC5 MfSdx0+TsNglaw+/OFF6t05u9YGVC49gZHbTAMGOZkpJnVrsnOWrnk5HvvvMjoiX162ZxT71wWPr qzwvb8tcncasLzy76evddX1OmISoLWbtuLBpcSR06cfLN4oLqjAXTuFFWCI/cXR6kGDY0AYGWI9K WVb93Re65loPWTRxzpMPzEni4m23T3z37bGDTTqyi0wNTl302kPzw2VDs0lhh7Gn4MKhLT9ktWmN dC6l/DZ607k9y0b5KYtPbfny+LV2FRYi8xVjHl2zIF3q3PPuFzeNCAW+s6TLrBJMObt7XRQTpetq yDxxsry+WQMPWPvI/MT5j82I9YYLNVk7Xth0KTh0/FNffDRa6DsAYxtoyzx25OwPZ6sDUybiVddq m6Y89nkGuXjtdxVz17w1jVH76ZebyvALj3yzKoiq2fXEo2cp4nlzJ/aXZufc1kx//IXVK6dbb1/Y e/Cb680QEnLYwjPefejZyYm0zoobx/d/n1uuF4T6915tHzNvWPuDWvOOvrfjWK0qdfexlyL8aJ3X vl/47OmAxEWfbXuo+sKu3YdOc8c+/f7qx0J4PnRafeOtUyd/KjToZKeOOiVUpiIyaVQsl+gCVHjH /m8vDCgx1v6ERzZufHE6YYQQ1qmv+/ajNzLrjd4JiH/agrdefCKGN+wpoH/kv1Hu+zEkBJnIxuMo 1d0/fe8srdQ7eZw5gQR3bf0PrxeeF/EfelEuzm3Zvzv3XRGbPw/66anbO8JkL70UFl9dv35Lm0pA ZHNIOCoIWyoXvVZxi2n7mYfPZu251XCoFRM8X/Kg1F50yy5lYLGQo6fC3qb2DkSwqtGOpyJgmcsb o9bsyV+/VYl6LGJ1LNG4ueiD1WdMAU8diiBLQiWyM7XZWhhaHLA4QtojoTOH7K8geWHJC3g8+rQx M6f4PfPslqcOHOKfydhY3DOf0r/lw029sc9/vjkFVt1+470Nm/jCr59KurZ1E5Sx44ul/l1lN8rK +8g+N2mryTytxAeveX4RC6k8+NbXbB8kJQwjgFQR9oAgBNK2HjtRUbKoN1BMyv9gzXZl8rbvdxL6 arava2FFLJwURy/a+dlnB9QPr35pSoxfb9nhBc89SAhueTmZdY8NgMJ6p7xUNMNCppApDIILi/9l 1dFJ4AhWvvoio/Xoc3sr6qelSmlg3+plmw1PH9/0KsvTe/bw9i++2soUbRwvIw0tFgYovWagXPmT tr41ZObslR9t9GPi0DOWmWg+ajAYAh4I7x8ST/QjEJBaSFV57ri+5Tahq/RS2syHOCNvzDmcyOgl C5PoJE3HraqsU41zZqQLFVOni/dtLZi78vMPIihfzYg8UPhicLzr9I4vr4D4t796E6O+tKnq0sjk y7DLQpy0+JGa3Jxvv9RHrnmLvO/tdq1lNB5QRLK0RYvxVOvVw8fzS+rHhMqkY5Y8qHj3fG342jff XeGs3/Plvr0ahN+bs50atcXpvnNqxQO56cIQEZkbzuc2F/ywsb+QSCRFTBvtL6YiPH3fr5z7A+7t fRtfp9k7j+7bvn67h/Xxe1PefsuiXbj+5MkZK149dvwlVXO/PDCcP3VhVvVljEguC2PFM6x9KS8t nxRafezx1Z/e3nj4UBwflBzfu3/t1xSW/+IxC9bTwLSHd11BLNl3/CRS3QwJaMN8KEa0ZO3StStb zp/6IH/7M1dxz60TV9e23bIteG6a2KH0mD1wyIMbD3aNTirsMTznxFTczu90Ml9d+yJdX73zUBOb 7FtWIJCpFIofHUOjkilYAhE98sEYb2UYdTpMWNC7T6/SlR56/9UPWP57FvBKVz/x/qh1+zemiwdq Tn331YajRNFrL0y62wPD7raSS/t3ngib//Fnc0J15ee/gk5ZHHbIodz4zMqOmO+PnZlMc6kOfbXu 4A+7eG+/PWs2f+/2mode/+ZDf+SG+WOOlTwXlSGmcMUJqUnyXHRgxJjp0yRkruROIlPs7DXfC0ad 3vy9/mcqQ3fNvi37rlke/mzLG2znqTde6YEeeXJRCsPKHlUMKdusfpNnvPeObeqLWofdA9jCpw59 a3kw4/x1wbNPvPn4syhA5BBMDe+/9XFfzLKPPsugY8wnP5z1+nNo/4MZp3ZsbeBO+mDrFHfr0fU5 zhH4EVCy+BSu/UDi61NFxqsbDsBPrVq2IvVQywOzQ8QixUMvBHOt3zTYzL/AkKJwZDqVIUShqHQ6 hUIkE35G5oBgEKkY8/X2hVDdqeVPHOhcNT14hBAWdgK/wPQZoVik6vbF6qtX62ZG8fz/j+d5/H8k 9/8cMGLwuBcSY2nrzb5ucyXIn4+jgIvKMiUCI0SgXR4PjR4Z62ryzil0A+0wBE0Pf3ZRLFOObT3a eVjESJNR8Vhq7FLMwxuassEvPLVYLEvBnyFo6mrqvNqOcGBoRLPLANgJ38zY/G3zgU+IK7bNXk6B IRQKNdCW12LoNqECAGSzQXiZcALd6tTbIQY/ZHzE5KMNmtTw1a+PmUhAeJAI5FA4AgyeTOOR5RRh gIyLxQQGB8qYolDvdatBq1TimGOg9ppqyA3Fj56IJJJhiDxqxcyiG2WZma1Il9VKoPboLPEcSsC4 ZOHxpptXrrBYaKxIXNOlnS+ktJTlFJZ1Iahus9Fig2wOjxOCHe3ZFZO+PZYW4wdZORkLO843Uqg4 Z2eLFYWjw8bushINBiGcNWumy+wNRFg+12K3WcxWgCOTSTj08OkZSD9F1BR8//pjNeMnz0oJ59y5 CQIwEsfzDwlMiQ7Csseyt5R7DB7YrSsthAXTWPrW6h6biyqKiWBy3A6nj8hzqMAQnkISyyLGSwXs QGZ3TRcmVjHmrW+85fc2DFIyoIihY+O9leVU5QGKuU/dDvW07j1dsq/8En8kK7Mrvz+ZZcOzVB1q m9lCAzifo0fgaTQyd+KjY2KjuDzSnFcQjkUAACAASURBVCWi95UGu8LapzTHP7siNUYOgGTut5fa AGLEHX67luQfszit45WDpu8/W1yb87bXAfQo67Jvl5lggtNiQTpcd0ICJJkrJhLGPvn+zNEyACs0 ZVWXa5uULVW3Ll7u0tvuHAi3O40Ji95dFkcNSVqMl/RUlFWqOiqOns8n89YvjjQX5QPewzRtc3W3 3cmWxQch5B6nhyLy4xDwU1a9/8EDYwgYpMLf9y526tjJVyvaayu7GsnFFOGTi8eHcDBHr55GCBYi zR1VlXYPTZIQxaMDGEem8v0YGM70Dd88EcTAA/8hc99f2pov5KOJ/IRAWVdohNA/Odiq7rb1AxyN zcMrgQeG0XS+3D8IaAePoAaGJATV5d26ns1COUh0l8vjggmy6QuXEtQnG5nTF84PGuEtv7Y/4Iel xSx6KDaMCUKeu7nhdLtaa3DWViFY07Gm+ooqu40SMiYxIAA3zI407B7o1TspwdMWTlDwMEC84h32 KEKwEG0rudCEXX9ioe8iYEweE1+f1dBrhKPpZM6UVWOjQlh03JQ5/G+6Tb6NXho7JCpKwDXKZZEJ SSG/rlzhaH58EZ/BRvxCDOLqLW8Km/T4+OQ4JgG1/NU5O16isWgkHIJKRxF1RghDJPO4dKzHgPTp iWHzxDK+UPLSu8tH/wwLamyoqnNggmiIjuryFgyeETVjYjBZ392p1SLGPL44KUoAol5s/upy7wgJ NGRB2NzE0Ms6dd7x9R9/agmbsE2vDV+WFoJDYnBUtpAbQOr47YQuPSh5wULDjb1XJs1fMk2K+63C 9GD6kolBAj8XPi4AkQeN6FGdFZlHb+oAyWJCmB1OM8altXgjg//lE+j/yD3LfSdjMLf216kt/Szu xBdiGe4Lz97q+OLbsjU8qrd712AwGC5VSAXmXj1GSGGy0eEIJOpC5btoU1h55ymVL40Agly6qo6a to6rBrtZN1B4oQRmcOOjqDa9xSanp0/zl1Z17DvetuuWZukoP38sGuf9AKv5zIUqETDVtCMpk9hy AokDtC4CgSmhUybbFCdsOCkVPdBXntNU1QUsKk1pdg0hShYuodKGejDY47DrHDq7zWpzwnCnzuL2 Tj3UdhvAk/yEBEJQ0KgUBXAYWTi0VeSd1xkra+GxD01OlVO1Tfl7Dhy+UjJnhkLa2eUQxcUmJEaR 0Y4LF9/afOLBVyJDK7Mv1Bumb/pwrqPubGvNWas3PICwgUsSt3391inkCqK+du+VEtaoBIDEMRlY ooQmjohLkdJsWhXaDmiCwegXslVc/fHwkcyoJY/PzhjLwA3R/tevAEh44HqremyMFN3dUNZg4E9I YtosTsiD8bhhu8PldtvtHg+MIkv5iFKZKCw+gYhwqdvZYjNKQBsWgAJyOy1eNy4RBWYkcYBD+ekz u8e/98IUugx2OiwmvdVjtpnNTgQOi0U7bFa3O3LFyiWTQ0wMz8IDG39M+XKxZLhNLEhX9/6mH3bm t85XIHKPf3/gXKPD4YAA1mqxu32BAOybIWMEapMDEIh4vLMxt7Azjorqr87T9OKsdjBcEhaAnC6d W6sB0xa8ui4GxNCgfAtMNurauvIu1/R/sumrIGT7pqoGp9Xq8hHHQh6Es/LkuerohQxHR1l1i40Y R+dKksZOCHN47mBouTx2kZxm7K49c/QodcbzL7yzCFIVLp7/WG+fDkYz5AKg9JeEJ8TigUPVwghw U7hkpMNmNHS6WRNxdqsFwmJJBF9T4RnScRMivjt07LU3+shjnowPFGGRKHFoAqKC4x8aJyOhdb1t NKlJICa4nQ6zxeKBkJDNbsZAeCJxpBx/k9EE92JMkA9lEnZaIeBxOFxON0QWgLyqxgXjomFrTWkL bLVYXW6H0epmSRInTY4jONor17xdOG7hxHCp9xvtdndvu1Jn8TN2NrUNwPLQCClryBqmDwPNrqxr 9dwojedE2dpvlphx0xhEAluAQCJ5spCUYKbTrOHQ5RTO0IUlXxIXlUECjt6i8sbgVIldVXP++qVE rlTEZ4a73KevFKQ/mEh0agrrmjRuPIOEtpq95ulwDBqAA83rswwSYrsHg1e7yeIwG4xGAp5E8FFb +EjrrXaz9wvNBrPVisTi0MKxYXVZx05ISFFM287tPwHZ42AwnwuCTQbrgF6nab1+zYwlW3yX3Faj ztaD5BLR3lpCYbE4DBpDZiAxWApblJCejPcGiX44WieGTEdjEOaGgnJlIN7TVZCrG+D7WBaGoQPz xq8JCzLWvrf/mjvotWdsGz74lKBY8ZYf1mvSDofT6O2HNrTN6v0UJIlIQCEQaEBkut19Op2JCpor 6100UWgQ06Fxm3Qmb/lOg6ENsjhsLoAftmM68ndvsy8/t3leaPPFfepvbzhsNpcHxv6zDfx/RO7z MSTIrjpbuf+csqLVxJiZsnwGGTrVeKDMMDAl5mm5u6O990aZoaawN9+ElE8PHx8uCBHiaPqe2i6D x+Tsq7W5E6UzMtieHQVffVN9utM+MGBtrerJ6/YkZfAcZ3PfPWfX6zzqLmMrBhu/MGZZKJ2NRiBc xs4f28/kqypuKysgTOiE0IxgCsWizqvSVZRrS/NUeXTmnAeiIpubj79VsE/pUvWZagu7df786GAm e4iVQprarH17vjtTiAxLkCmvnGtkj0lidH5z9Ob4GfP9Cb2lNzNv5hXn5mR3DrikUaNC+fadK1/P VPZ1NFWVlDXZkPKZ82aG+7kvbdt++ML1ho7W8rKyqibUjBVPTg6jm5QtV49fzK/OrW5uNWvbK8sN YcmJMYlx7q7K+saOrj6DSqsn+sXPGRfEouH7W3PycvMLbt7Kzr5sI4ijkkdLvSG7RX3m0I7d1zvS p8+OVQj+xcErBAZlbM46/dPVyxcvnjrZwgoPkxFVO9/dcEttlUTI+29mHjtxsoopmZkSGSglVeYf zsutzM+9XlpZR5VEhnl7/5CcL5dJk39q28YfLtWWlxXlXsm8+NPVeseEhZOD+cTCHY+9vyOruLa6 VjlgRIuj+JZD+/cePZ7Z0GgdPX9GRhLv8uZPrzcRUifHD4Oxj4R6i3+8VtSUe+NaXo9O392gsmH8 BYSzx4+eOn+dHZqkMGa/+Omh5i7d2JlzZRR94U8nz2RdvVhS3thT39zYqEiZ6s+h3DXc61sK9+w7 dPZmOX/s4rnpioIvVn6ZWd9nkyePFrXkXczJK75UVttt0DRUVwJhTHwAo+TI5wVmjibrxKGrN1X4 gBmL5ydHhygUAYGBijsSFBjCo2EN3TXHtnx8/FpFSe6Vc+fOu0WJS+dOF3M4YgG+NP94Xm5Ffm5O ZX0r0z86kAvt3bF1/+lrpU0NhdcvX7kKxsyM8LFxItAMJr6p4Nq+ErDiiUfTw0RoBIohkRvri89d yykpyM0uq1HjeEnhvOqT+7/afqCwpKShoTDr4jm/5JmyYWD4vQ5J9cPzH55rqB0QBbF0JTcqu6Ll yNs5BQh+UoQCf2rX8dzrVy+eOXW5uN0GoLiUUQ05R7fuy+xWtlZWVGg8wonzZkeKWd7ac2nbL3+5 60rRtSs5RWa8KDRUwSbdPdY79MobZ7/fdvh6ZXVVcdH186cqeRmLl81JFXjDUkdH/qnLeWWF17OL 21QgdFSUv4h9N34qAkkkEWBr44Wzhy9euHL21LUuG3lCxlgBixNE8dy4/O25i7kXzpyuUbvHz3o4 XebatefAhUs3+dHpAQPnX/j0cFefdfTEiZjOvP1bPjmWXdjYXJx/I0tNCoxX8Fzd1x5f/dGFrEu5 pdXlFZXXq1R4riwuPgJpUtVV17SoTCZDa5s99rml0RiEW9uaey3ryE/Xsqsaqitq6mFF6gRG48rn 1+YUVZc31eZeKtfZWWFRQgKeQkUba37KzrldkJd7PT+/nxMSmjImAu/uzT576lzW5QsVtW2quvrq +tCxs+XMYSJLPJ1csXFLa8Jzu14btfnNbZPe+2R2EKnx+oWtH3x28FJOcUlV1e1blzNrwyakcgne MQyl7yj99sSF3KzzJdWdbEWIq/rYrsMXb9SgJy9Krty8evv1JhjIR40NGQ68HqlvLTt88WZF7s2K ip5+Y09JHyI0PFTO/UtUV//I/5rcZyAO2GPr0jZ3WQZcgBnGD2IDU6mqxoHCh3BiUXZlk7alz+FC onF8ikLBEpExaKeho7ynG2BQNU0HPq8te3zC7pciBY0DTWqb4dcyacSoCDqytbugzYOCPU4IoNkk eShXTsH6urnT0lPWV611QUQMXURTiLxe2WPuHqhvMfRZvJMpHNGfFi1nUg2mjkpt5y9F0gM5Cj6J PDRVxKZTtjS39FvoQaF8c0e7keUfQjdXNKoDo+LIzr7mxrpurROJwXH5EqlUyiB66nMKepBIH88e hOMKAkJCxWSMu7umtq1P6/A47Q4YTxZHJ4Wy8cAyoKopq9W4YDafR0a79HpUYFQoh4a3G/pUap3T Zck6eKxIO3HXtxl4yKnprGto7dE7YAKBKJKFSER+3n6qb7+99vW3m1kzNqxbpWD860Umj767tba5 y+yAsVi/kGg5DWWpK6014ulSfynO6J3wqJ0ceXKwGA9srbVFTd0WDxJDY7Bk8kAuizY0Dxpy2fva 6+q7f2sUQPCLjAhgktCauhu16sErGLKfWBHEQ7W2tHardQAwoxJDGUSoo6xA5eDHJAYNl0Xi7msu L2/qdXsnHTwuyWFw4Zj+Yk5vV4e63+AXGCXFaotqlBgcPjA6ngbrWxvq29VmNJ3NwrltFoc0ItGX yPvHkcZp7Gtobh0w2iVhsVI2WV2V26hDEMmCoFBOb0NVm9qEpnP9KBiLwUiXhgcLCTvSeMaPi6ch urVoHEsgCxBxicNgJcLeZqorK1I5sB67DUITAkKjgiR+voRht6W5uqhFZYFQWDqTI5MrWCSooaFp QGe+8yQaLUlI9cf/jJvr7G6oa9CjwsICedQ7KxgeTWdTVV2bzYPA0xlckUzhR9G2trSrB349lRIy Ko1HGu6ADWRtzC/tgWAsTyHFaFVGj5hPHVD2EXlBfDqiuaJSqbfhBo+74IhkRViYU9NW39oLfLjX gMqTh4bI7/AxOE19jberelwwjkIXy/yFXMZQiESP06Jqb2juMfqoBp0eBJoZHBUiZJO8Ezibrru6 rFZtc2HxVDZHGKAQUInDZQzCHos3wqqv79W60Di6JCAwQMLGoJCQw9BWV9rcY/EgUFyhPFARQEFZ auqbvRXID4mVoNSFNT04IkkRGUt29LU3Nap/TgsBnIDIUBETtqpybzf+9hYi2z/AX8wiOi06da/G jiBq8r5Y9nlcTc0KMuwxajoaG1sGHEgWi2q32InCsGiO43ePk3giuULB9gY7Lqu2pbqupU+HxBIo JJ5/qJTHJDq8FVVb3621Ydl+LJTdbHYqYkfzKcP2RHdn3k2VIDJJhs7LypelTRKREQaVsrmhzfTb PZTolBgGDgVDbq2qrbyuzY1Asdg8mUyK0Le1KAesLmbs6BBLTX6jAUWhS8KipYThnKpZ3VpU3mCH sByOHx7nGrDjgwJlfPqw9/4j/3XytyJhwTAE/RFIveZqyqI6IxIJLFYNkx7/5cyj43jUkZ71ocgP /om8GwodGqQfQPxuT9f7Jt8CpTe6vI8n2QcPO0Lgd/r7as9H3ODjGPhNK9j3kYMqAOQfMd+9Og3u Pf9WZnvm2iXvlSr8Glus8gdf2vTsTAXy1w8AMPI34FtPT/mP6789KJrx8ZqZ4fdCZHOnZe8Fdh/y kbcPrdW/SQbfjryXdhqsf/iPDf0XZOjj3Td3JE9/gTTv5ZVRkoxHlkez/8WyPnzHyHxt6ENz/4O6 3k8YhOD+89yXQRNA/NEEfjbWe6qCe5fBDvP7Jv2lp9+x2btoMnx2Df6EYeNXZcFdLQAPVg7iHj7A p9SgWnezdPh4Q+6nBfYW7l/+ZpaQWVdcrU1dc3LbM3HIX1SF7/FDfcvuEOKPqvr0H6b2hnvYa9X/ j72rAI/q6Np33SWbjbvbRklC0BDctUCxFkppSwsttJS6f1CgpQIUh+KugQRJCCEQJUbcPdls1l2u /fducBIqH7T9/uZ9+jwld+/MnDlzZuacuWfOsS4+WNcIv50Q5A8R9mRbd3Oc/Imyffh78TeHojTI C5MrS1UWhMP3ivaO8OTx/toAqX8/1PU5yelVZK5NQHhsoLfDU5IvIbDFbAGJFEaPKcz68CcgLbty PqeTQiewWc5RwxO8eM8p63Yf/mroOypS0gr1ANEzOK5fqCf9fyBIZR/+jfjnxoLuQx/60Ic+9OH/ Mf7VGzAMmi0QSqE9r0jSKGQxgQiRTKH1HCQPsZgsCECk0n9fLrT/OSCQyQICBBKV9lAH8dyruAMy hUrtPrJEUUSnUIAMvuDJCCCPAzXodCBAZLNY/wI3z24X2/+BfiIQqFdrEBafR++Wc0zwLZD1ExCF Rrs7UigKw/jI46kqKZS/IBcBCumlCpOtne2fEBUUWxpA3POaSH6QERyBIRDE7xpbU4X+XUGaURiC QAjuznf5t1HRh2eEf2gyht8Ps6KxxcCw+e21+0nAped3frXhMCd2uHfPd2/+W0hvn/rk083ZMtv4 GI8edmBYcmTD11sPl4aNGWzzF6eBvgezsr2sprFLrVbJpW1imQWgslj0ZzWpLeK8H77/5dSV6uD4 uPsdhDTNicf27zyUxgsIdrbB91FQ1/7dtIE/G2Jmx7nf4xKiqKszkBkM2qMfu2Hl8TUfHrlW7d8/ TkD/+4+LUYuqprRKDVK5PAYAmZWdbQ0dSoDGYD410evvAKKTi2uqq+pb2+VSmdRAs7P5J/vUoIq6 3HWvvJBIHTAuzMm6WRlyzxw+dOb0sRNX2NHDvTn4SKFmRUnGxT17DyZnNwpdPZxsn+6mC8ura4x0 DpP65yeGJHuTf+xPY9+Z6/THb8V2lVzeuf/MpcSj+YhoqL/A+gxsr8w79uvuI+euKOgOHi64X+Sf pu3PAtGLa6+cO3Xs7PnU9DsM72APQV/Qq/9tPC/TC73rBfXIpXwU14KRJ01uBO7xRucTP/VUvvHs 22+dqf/9VOE+JHdB4Lp4t5/fWiED8fvH6GNv4k31Vg3y6LkBgr3aUw/o9p6MwsRth6tMPVZDoHv7 Us/svaKBe24EhuHnfTohvrVv7rz5L765aNbsBS++umLbuTztg04/hQOPAaf1yWElMYQRImHinrSH O0iisLy97Ksyy9skmm6eESm00PEDJgY5PNhRUfWxJS8fSy8DH2ufQPHxDIzx9eQ+dmTx+IA8IOu/ YCDeqV7l0gqwK2vpkMgFKzY1GxGduPzQl69NXfxF4p32bqqR3yzfW7XappObP16ybMUH7749Y1Tk xOXndPerQbtr7Tn5B9rzD48AQZAeZfWuK9Wf4heVx40a23+Yl+29USEJPQIiA3hXjmwv6rzntUyk 2jh5Bnkxywvra5r1vyFYqGrfiy+cuN30Z6i5BzLbe/DgEYLHVOtuR9AnUqwgyCNcpdu4BkeE2smT T1TI7z0jMPj2gYFusprMrDsVusdF878Diva2hgCPrIH67BPbtxxOQ4VeLiwiBD00r3qZAsB9f9QH f+Ev/tmh7sMzxrO3vFBI31qVk1tcrzaShHYk1HnU1FgXAIEUbRX5t283SxGSo8+ggTG+dhxMg4T1 0ryMpPIWiGXDtnfxsHPyC3RAsrPzpGZ2v0hvZWl2QaOG4Td01gh/RCctzs0qr+9ESHYh/WKiQlzp JLO4TdLaXC+ntze1sAhEKt/GjvfEFcZuwBZje1VJ3u0SNUrgkMleMfGhAZ5e/UdMCQKyS/P2FTdR OY4D4od527EBxNRWeyc7v0qhs9AcgsaNHODAJoEGVWl2dqOBHRzo1NVaXdPY6RkZPzTMm2yWY/SX NZtRlq1nZNzQIIwqALFoW+sqckvq+G7+I2a77c7o5YSbyB80c37knDzMkuqoKrxa1uVo69p/YKQN De5qKsvKLZGoDBSa7/DJQ9zYaOWdzJIOi7uta3C4W3tBaYes1SZsSIS3y1Octn4P7GNf2LMzoTX/ xNoDgu2/THC1d2eAioIbZSqUwjA3VbXriYGDZg4M6vEWTPdoS6tvJ2WVghZY4OLZf9BQVxs6ZuXK 2+rv5JW0E4T9ovo5AFnWNxGTVl6ZX1DTZXHxcXETCLolD1bXHT6XaRe+eGSoc3dPIOw9SeUNvda2 sbWlyZ4IEGxd3Hk0AqhXVN7Ja2F7BIgi2dR7xgdqrMnPzCpthFGmg0vYgCGBtky47lZWs4kstAHK KmrNiNfI6YPdn8xk8DSgmva61KzbCoUWpdAGj3shyKnnzA9UYejoMGBd5t7Lha8PMxddvpofPv6T IYFOqFaSeyO7olNiRil+scMHh3uSjJrakuJGNc3FjtTS0EDku0ZGRzpyGT0eNshKkrZndb3x5ZY5 A5zSNs19fWcHpsFwyYhO0Zafk1vXJgfIzlGD48J87cio9tahc22O3v1DPRU1RcV1Gu/QCC+esald qukkhowZYq+5c/amysnJ5BAyMtAGqb1TUFhebwSIfuEDY8L82DRCa15qRh3iFx7IBNtzi6oE7iFx 0VFOvEe9wVFY0VRbmFsGO9v4+EX7OLE7K/JL2yUmpt+4QUGQrPp8SrEwYoG/v/09WaT7xQ7xi3Y6 8Na6+3wnUDkeIQNc7Mk3s3KJ+qcdrENGjbSzIs1k8K1vbvWmQyjB1tmNZlGXlOXXd1i8PAOC/XhV GXcUZrFtZDyl5lo72c/Njt5eU2tm+fTrH+wsYBExqchKy5drln05weXByMNqSXNBflFDh4rn6GDW coeOjXUX0A2dNdcuZXZCIMPWNSK2f5CrLSbsPI/wiR7hPp17Dsjvr5BkWxe/4dN5dRlZLfcMF1DV cOl8Kd3e7Bg2xo0kKyso17AcRMEh7k9cw8U6VVFU1KajuwiBlsZmsq1HeGSYEw8/2DDKm25nXa9q Bwl8p7D+cREedkRNS8rN22aaS/8o9+ZbV8tlJMfwoSNCbSVNhaklTZ4hEUNiIgRce5EXbpojoLY8 LzO/qhUBeO5+4bGxPjwqWH41rdRAihocyxAXp9xuYgk8IoMdxaUVMhJRqUBd3TgKqdhkI5oxJpJH /vtPkv7NePYbsL4t/9C+AzUqKpsKa5oOX3M6Oj5miqmt/MTmzQUKbEdhy/Ou5d/uWP765CAH8/lN 323JyXXgeZG1bWIFK2buhx/NsC3Pv3bmQrlnmDsf1rYrNMpKzqhYVsnZbQfSxGQ6jaCx3MjOXfjO m0O8gJtXL+SXVjZA15LsaikUu8jBo2J8bXoiClG2lJ//eXO+mclmmZtTrwe9tc7T251OBgEBcOT4 abNAY1ZrauXUVa+OZkOqityMy+nlBBLaUnugkH5o01h30KSvzks7dKuZznVkUUGNvN4XdIjxZt7a 9tPZqhoS2wUG1Sk5+YbpS8fH2xZdPLk/7XaXSuftXZh3rAgI651ZuA5LtciaL375xRdtdq9MnxQS Ewo2XttzMLFEDNmySIrG7Jy64lVvL664fm7N1py4aW99GsDLO7p9V1blzDV+IZ4u/2XMOaZDwACh WaDP53LcB0T3o+FHxE3Flw4dza4LwobHYknbecnp1IExHj0Fp7R2oPZm0onLtU48kkZxtUHGX/5y P031tf07kyqblWYHp8LTtTUAlQigBkXj9ZO/nrvaauay2QTdrSrpSOsihurb065dJkDtHnP2fzXJ C3tikrXlpF4v6FLY3ExLJXYaIcLweUvC7SnYEtZUnntq/w2/MXPt3nnZA/drNVdc2vTtzyVGBzqP AGg02fWq8S9OGNCce+m7C4XuUeGIXtl086cC0sFNCyL+yDIDd1TcPn/xKpFGNTXnXCvl7f5hWs8H pnRbO57QPzz41oUMoV9bg9FuIBUGKDSDOD/l/MVaC0BFZCcu5m3YuzmUpK3IOPfTsXz/2GCiWWcy 6a9lzFq2fKq3sIcjRMiiRdj2FMQi0xIHzPt2MSRnAqiuq+ry6X3n8hR0BgWU5qXn5674aFWUo7kk 5fzhurZrQ4YxzeqmBlWkjkjyMx7bsudKa8C26H5c5Z3Nr/5ImTVw5YowfXH64eMpJjKPRFRnpubW Lnpr0cigzqqCsyfyZSeEAbasTmWjc4jKySvoyQ1Y2Zx/aP1XiojZy5d72nGAroaC7Wu3GId/NmZQ EKhpTb10GiWbYhftemuY60PdAE1PnnXhltdv2I7GrqbMK9fuqDSK61euWuoMCDVh9suegPp24uFN h2qmvP2xu7t/2tb1xzrUyzaJeFnHfzyt8wzvZ0eXdSjY6ZXxc2ZPiHFC2ysLruYk5qoNt0/6W1Vy VCepSty97XxOF4VPJUPypMuKtYnH3xjiKavOPnPiIuDI1Wm1JY2yFUvnOzPvKhI9hHuGYdB65+xu d4zixG3fFBi73tkzhEuoPPTTmkbnUZ997I1twI+XM2uLr57YdaE0KE6EGjUmsyHFd+Z7q2a6UGVn ftiQ1tFFYdjpwfRbt2sXzpkb7dRVmHnpckpL+DAfurKrRUcQqhz6+4pqi/Py6pr1TLJzOontEO3l 7cSgQoVnv/9xXz1kT2NYUOPVrHb9zClDA5sKM/cnplzIGOZOA+ubOshEN9qcmJQtG2+TnGxgpdFI 47nzWqrOOofsH+vJf/pw9OG54tlvwAZZa36lzGfIpMGhTh2FBprQlQCZ6vKT91woGrPsgyF+nI7c HRt3bI0bFmkrv/3pt3lzzvz0WpSXobHw3NE0CpdGs/F6aclicfobNSb2C2+tinAgiFU0Y/OdPesP SOJWvDs9DJWX/rBp18/nowNej/cPjTRV+rkCoRGhXmQSy4Hf2z1O1KBsrSorpo14b3Qcp5ZrL/T3 7HYOgfTA9LnzfpzpVZR0+nRKkWLhaBbulsUjkmkoagI68zYfydsw1oPOcxw/f36ndu+5Qs7Cj14M dSGaKbZAZ9Zn3/4iWrVtbqyDKiY3RgAAIABJREFUQVJ0fufmM8SACC+f/buvm2LGfPF+AlvfABVf KDbgQZw7Gsru1EhJNHwjgGEz3TE4JsgDW9bpQN13H32tzxGs27l6TCy2IOuST5/Ymyibv3TuAD9b dUPS/Pe+EQye/e6YF8pz2uooBAadKiFqXUe8ODY2uMfUgX8U2CJpDWJ/92iezHEZHO+yr900eOEH o/w5B+d6HMhaM8YjsJfSZpjMC3AANBirmjpvXSt8abb39ZNHStROcz9YHumEZO9dvwfQAAjUWp55 8kRKxOubpg5waEk7np+Z2V2e7BC7cYPH5T1LruvvrnZUjq2vKCyMx+EEhYREhGNk2VsXRLqNy6gX 32RIVIWQ9G4eWFPLpk/WUKee+XZ5LA/Q3Dq96/ClE+6i2IRJ8cD5erd+k14dJxInvjH8h6INCyJ6 0yB6AoSQaD72xHYdYAKA5F+TOtZN8+9ZshCTHJi2Yl7j1o2JUr+Jc0axmQqtGbJDiAIvO3KjArAB as8fKxN/Fx0sDI0U+V27JQwbuXhMlLbxyqevbklNiJ0fYLye20xhUqwDAJHYwuDgUEHAmJfC226f 331hv4nOYHmPXkwlgc3FN/duSWKPe2vOaD+wM/eT/2zfGDFhz6KYWd9+KZ87OAec8c6CV/xsSAiZ ZSeg6Muyk0+72XNotvaRrlRxyLwP4mwk2zb8fEcX8fqb02xJ8jMffP39p15TBgWJpr71Hv3naSvL 5/34ysj+DphCaGv/RNR/IsVJFBY7Nj5fG8muz914CRk3XqTT+M4YGYVxheo+aO0X7KST61sMPX5K +cOgcu38wsNDmUxnUbgo3AcEyHZMIovuNGHMpJKCQwiVQKPT2onKgClvT4gMYfqs3rXpRe83v3x5 go+s9PravSkXhK4h8wfHzVnhG8ASLbgXzgQxNxTdupbZFL/4y1nxHpqGTFviKa7VjQAGyPZ+dl0W s6arvqIwp0s325nZ+3XwR0FziHrnq1nLFm4hU6g0gEh3dIiJHxHuKXhSW6NxhZERfn45t136jZ0z TKSuvfD5G1uuTRkxnZ62ZuvJ+A9/mhJhq6y7smfr7qtOAf3eHvX2e0trjkxUwIPe+eAjV7pJC3K5 bH7EgISEG/kVpODB46Z52gq5dCpgqPr5i41Or116b2E4wyJN3v1d8uVkn8DghOVvyyvOb2rXj39j 6bIgvkam59vCTSMSUCRqQVDh+xcILy2d27RiYnm7pm8D/nvx7DdgtpNo0rhBLTJxRZlK3dnWcLtI /nKASiHVMx3sWbBCpiQ7D5nzBuznyddUlbfDUYtGRjpg2wBv0ELXAD3CppKw7Y9LpnlPXfDqsMgA Oong6AY35uUolHQXV45RIYUR2/FT55MDPBlMQUT/wcR8VydW1KC44KcSReS7Bg2bNalQIq4s6+hs bsktaoofFMWlAgQNMGBglKMtwdnZ2YZQjxKguluJp4ureT4hvgKqnaEkpU2BTWI6icThcdh23nGj o0cNFXUHNpLmdDSgTi+40DRSqZkgjJ22xCbAB5R3dKhtpkdGB3m4kAGXBaNc9x7Hs37WFV4/llTN ttoWZrPaPm5+sLcrmw5QgXozGmMma7kO9o58NgCJpZ1mG0cHLtkslUjJ3LB3V7wTbEsRBkVOmBf/ XeKNvWfFt4z8SVNH+2L7kpUMBDGIWzsJTHtnu15y5P4WHtnGCRQWg+4UnhDq6yWwYw4eGXSyy9hb QUnOr9/uqRo7J4ZCpJAsBDGgh4yKOy1qrwFTYsJ9hTTC1JcnAD/uxzbgrq6OVorTu6NiPG2IHuOH OR+uJgAITj6JYWMj5LMd7tdJ5dmHREX48Dk24ZGxA+PuOdECBBKFwbERCJl01b31zSi/0oiufzne Ff/QxxaJRHa3ayRqM8uTQXUeMCQq2MHWziY6Hmiy3LPEUDxutUIDsPgCHqu3tKmq2uuHj2cy3H0j /O0hd2JSrhTq/XMZwSSz84v1S3A/qQqfMIhdVtkKmMV7j50Uw7zQqH4sG40MSLeymEyjsDy8RGHx I/y9bQCvydH8zVKVTlWbc/Bwtq09rh5AkJHuKuI6+aB6JGr84nCtrLmt0yQt2frj2tEJB4lqvQlk +wipOrkUJbvOWbCE62lDIpC4fFshkzf1pcWjox7kyxoy58XIfetLG+fYSnYXDnp9c4IvpSFFpjKw PLwxVVSBANGz5zuDIiqZyKDzBAIbu9Bxc2bG9e4WRWDwPcNC+9WeuXQxSXfwkoGARtUHJ8QFOOG/ kZkC/NOP3ROlSHiQRtIjRw+EnkInPwaajVN4v0gvNtMrKrr/oPvzmuQWO2Ty5Nu7azKOns64RQv7 amq8PYtCJNuwuD6TF4zw5QCenLjQi/l6cZcFIWBP7e1tCdhYdwOFtEo9WeAZMzjcQUhxEI5779Ng upsDoC39+Mf9gfGTo7kkCdEgVwMPE9jTqQmRAjwU3IfICBw0d8HkG6c3n4Yj5BpmzNyx/bm0HsuR aWQGJgBxQ+L9vXmA1/Ro/o52pUFHahKTnb3s8FRjIMtv7AJhQH8XMpnK5PMAot/8ZcvjfAX367Bz 9fQT2ppojt5+gd5cayvqrrQOys6ZA5xwL0dWlMg39VqHUg8xvbClhDxm4dvzRuCqs4szgGgaWAxX W8TLzUHiHMFzdXc3CkmSvu/AfzeevROWruNOYRcSkDDjxTlzJvX3TruQqIDILAcXgAzbe4cnjBjW P7qfgMSBIdQxJI5ATtpxKleu0baVp+37/vNTp5tB0KJXqhRmghk06xQKLa5WE+gsrosrGXX2ihk6 fFD/qGBHDpeGdkfswHT2xtIaiVZVU5R++uSZO63aHmhCoc7mqqy8tsgJE+bMnzOiH1hbcUemMcFG tbYBUMoUKAQrNco6s85sMHeWlah1pInTpk8aFkEqlQIaicoIIwio0mh1Kp1FZVCrtUYzhKIAx8mT QNSQ+N6DR48ZNjDWA/vThNCF7gxe7bXb6Q1iWWtFyvotRSigNpA5omEvrPpg5TIrVq784JVxMTYs ik4uywQiV637avmy4PVffnomv9GEUB3t6ZCAaRccPWrMiH4h/r5shEomEKkc0aCRwbbGHz/9wcmv 3/DoINq9VUBWcnrajJlvr15dKu8lQ1rvgC06uUqr0ugtkFau0hiNmLIBa7V6hUGrw0MWGTUIs1Gp BXsprqhOu3SLOXz6okmDwwSI1Gw2GgFmMJ1zPSnzVmmjQlJzYNN6FEV1RtCW48Cqbz92Jbdd0pZ6 5mBzXbVOb0KwZVGFt6/SabAFUqlR64xmfE0gsbwIFFmnVK/XtpTcOLD5QJUKAk06tVKpMxtVeoNG qdJixVmOUwnE73efa9EYdMrW9OyblVqGh5Cp12hBOfY67meCDy6g13V3AFJnnd776vTphy6lPcVa 03eU5eSp/OJemDlxpAvUjqIWldrQ86sWLSY/cg1t5LKN36ycyyeYVTqzWdFxKzuH5BI6d/bUODt2 OYrqNSp8YChIW2nB1RNJ1U0NOeeOpciodrYcgWj8R5+u6paKd9557815MwKd6U03j6w9kEbwjJm3 4OWpw8NU7cUGkMTlsQVOVKpn4ICE4XH9wgKFNCamPiKgVilV1aFE2KhRa4zmuwPFdh24bKHTL6sX zXj/2GufvOvCIDF5jk6uwTSCMDIuPmFwXECoM0lIIBKwsdYqVFpEacSkGhuR3pzWCGS2n8iHDGZn 6Gizp4C3zm6PGxzkwmPi0qKSK3VqtV5t0amUGo3BjKk7kE6nVcm65CiqkMi1ao0WG2oEMhm0SoXa ZNRo9FqlXG0Ae/cDInN8CGRxR5fBoG0oSDu841itGiEybAePm2Cjrljz2fYhoyfE+DlbZwBiVHes 2XmxrrUl73zy7fxOroszFTJibUqwoUd1MpVWrdSYAYrAnqeV1yZfL+hSKhoKUz/66sOMegmsqEtM yw0dMW322KF8JqXFZDKZjQimIht0anxaaBp0UqwCrQHELw1aDCqFTGE0yPE6MaEAsUWAzHIc99Zi csbXW87lRk6YEenYS9ZAjIc0FBeAs1cxAcg8eRATAFchi+fqBxAw2yRg6KiRQ/rHOHHsETMKmY1a uVIO0yCLQStX6I24sKIIbNCounS6LrVKLe/CFiFcvrmu48yWbceudGgNqs7qpOwiBcp24FAMWoWy FqKiFmxuafS4Am3BqJerjQaLiUDWm4wW2EQEUIVa0xu1ffiLgD5rtKfvmBwf6ukfEh4REezjMO+r szoIVnfVbf9oyTC/4LDwsJDA4a+s3FrcKoNBbcapjZNcvENEoUGRUcPf+DyjRFKbvnnReH8hx8bN 2y8kJGTRwQqsTlAvzT317bRRvqKw8FBR0NS5r53LrdNbYOwnTfWJybYewaGiqLihy9YerJIYeqAJ MZdf2TOcybZSFR7gMeDN9ec7teqrX45wBACv8HdL6gr+M8aVw4ta+Z/EkowTsyYM9Q8OCQ6YtHrJ DIDhMPyLpNqS5BeD/Z3tHYX23sGi0C/2J3fqIWz1Szu2brxnQFg4RlXs8DErT98s11kM+Rd2jYwf gNUQ5Bc/BDPpBL6fJjX0QJWlYXVsKADMLtObG3OOD2WwXPrP+ul8iaK54OcPxw+IDQ4PD8eqWPb5 5qJOPO8KCmuTv/s4LGbS1ltV1q7fhTh/GwBwIwZ+UKVB/uhg1Z1djTHZ18ORyXILEg1bveZ0u6Rs 5cJRLAfndw7dqEzd6O3IYHqFJzXoeiyuqz87AXAIEoXGxUXPmz8pJiDi0x8v1N65+dGI4RE+ASHB /oMiiUSq/ZD3Lijlzee/fneQi3dQcFBsONeWR3ed9F1Ne9kHIqz9YDdHjo2rn0g0bNV/jkgteFer zm6KjY0RhYoCfT0/3HC0RalIPvi1SBTi42LnYO/gFxQSuuDHWrm6K/PcW5NcAkWh2ItDRo45lFKs NXQeeO9lL5aj99QtjZLyN70dSHSfqTtysFot8pqN78/2iZ9zMqsG6p1Vps68L0aOCvcNFgUHvv7+ W0P9BSOmrGs29vBm9Yn3MPkJ6D88uUHXXpi0KsHZ0S7my19O712/cEA0JiYhfvNfmz3U3z922NEi SeOtI8snR0wZNmF4YIB3zNjVWxPbVT1Vipqur5vn7yL0DsRnUIi/26otiVpsvVQ0X9mzetww/9Cw cFFI4OxX30utlGhqzoYE+TuSKa5+QSLRuE+/TVXfEwxjR/okV3tgwlqJGe8qDOpLbpx45YXxQaFh YaEi36kL15zMNuorloeGYqNPp7tggzhn2YclXZbe2GJR1X+7avqU5Z9kp/4yOmbc7htVRqwtc817 opDgID9XR569h3+IaMT6PVe7JMUvz50sCvZhkYgOXoH9BiV8frFe23ZnxyczQwK8BTxHV3f/kBDR lvRac6/DAJUf3xAcHhGKDWxw4BebznQY8DcRSHFg2cvewxderGi/W9RYMJnDHfnSwoCgwJi4kZ9t ulArNZSfXjdtRGyQrxOJ6Ij1a9CwUVebdGZ1a9Ku5eOHYfM3JMCn/4L3Ntd2aRFT85cv+ntjzBs4 aMALU4f2C3jxk82lYmXa+pdG9Bf5OrMABy9RaP9JM3aIdZ2n9n6FFXUU8AQOrgFBIXO3pOtxRRw1 qVo2LR41eNzaOi3Yq1ShUPWVbZgATB88GhMAr9gJmABI9SBi0ZzatHq0dyC2hoiCB02f/01KcW3e 0WVT4v04FLZnQHBEVOz7Z2ux8tq2ko0rJzoLbWzsnPyDgkWzN9VKsVlpab564JWxbkE4o/xHT597 Ibta1Zrz8uxxrnS6g6d/qEg0Ysy2TtBUlrxnnJ2D3ZAlX/307dDhcV+euHDqXWwcFlfreye5D88f zz4QB2IxYGowglksBhORyeFxuXjWMGwTteBKut6CMBgsFpNBo1NIBAK+MGjUmJJGorE4PA6DTgUw 9c9ogu45apAZHDZ+pIPNPRDTqjG7h0hjsJgsJp1OJlnNdxTSYxaUASEx6UwGnU6j9uhZCltMmCIL EQGL0UyksrhYWzQSZNBi9BAIVDabCuIp0IhUGl6BCbfGzFQWh8OimE0WIpXJogEG7QOricpg0qlU a6BXi16jUWgMVAabzWDQmTQ8vjwMGnBjzUJhc9hEFMIaYLB7CvEPG9Q6C0rh8JiYKYPRAhHJdDqD TiGAZoNapdJDKIvFZjJY3Z2C1M0/r9lRTgha8/U8J9pDkS1gM2Z6YNXwuX/4Ci+MqdiG+7nt8e7T aSST0WgBISqDRSNCWr2ZQCAw2NyeE5yhEEaoVG2gMnk8FhmGYBKVgdUAYiaOSgOR6VwmBQ8STGVw mBRsCDDLFTMbGCwGmUhAiXScvRqt5UF1GAE0OgPvWzdjNRaYRqOxMA5QyaDFZDCaH7xLxopjkoGY MANTqbYAZDaXz2WzyCTUjL1nARESncuiGDFrGCCQ6CwOndxVnrL2k3XGyNc+e3+WK7N3TmH6mkEr VahRCtuWz0RBE4xnYO7BY7mbewQikcHikPFkzQYLTKIx6GQCpFEqdJjZig0JAbZAKJ3FFN88e/Fy Ruib30byIIRIZjAY1F4OwY1KscIEEBFQozXQbBydBBxrIBc8OIRWrdKZLBQ6k2mdAkQUxKyzh7iH 1Xrv5jQKK9tb9Vxn13se4AgMYbxSawwImYJNQRbGaDKgVz843iBRqEwGk9TboRiKaFRqbLrw+VSp zMS34eHzGoD1qocPSLDZiV/eNhiM9y/JEAhECj7kgBlbESwPTh7wMek5QI2VWsiiw4gFEWxOsxhM mjXzCigtX7VyJzNuwurXR9l0dxQqnen79VcV+5wtIJFIplm5iliMeEv3DGxsgJhsDoWIB97RafDj Hmw+cjgcnFACJi1ahUIFk5nYkkBAYMAqwYhZb+wOJWKtgIQtT2wqZDE/LIFkOsZDjAhE0Zz11fQP w7ecXjTAoXepQqoT96RklkQvWxvMgbsFoDs+DwyatBqN2mCh0fHZTmdQAdBoNIN37wDeWz0wCxgT sO7wINbRouMrIx6IHsLMdZVai61eHC6fw2JgHdXrDdC9O4REIp3NpeHrr94IkfCgQDBowcSUjGDV kdjcf0NMm38w/m4NoA+/DVCvurL78wnx8X4AkDDn7eIWzd9N0f8ioPqMbSuXzzyU0/bXt22QNWz7 eAbgGhg2dv7Go1fbdU8xlfrQAwyylqM/fzguOtoVAKa9s6FJZj3oAlt+nh9GZbIHzHz9u52XJb1a 788LoDjr7bmzRg0AAFfRpD25TxlUTAA2vDMRE4DocbgAdBmgv47KPvyD8a8ORfm/AgQ0NRRn3mlR kTFjS+AWHh7au793H/6JAPXK+rK8inYDgKCO/lGhgR4cap/d8QcA6tXVd3JrOnUkPGugf0x4gPXG vz7/0qUmC4UMoTaufjExIcy/OKarvjn50m0DHlqT4ugeGhPm1lv7mABY6TcCMOAYEBke5MH6PRnN +vD/Hf/cDRi15v36fUL6R979J+J304/+7hSDz4mAPvyL0CcVzwHWKdzH1T5046/OAgCbtJL2luZ2 2cNfg1AE1kjbGpraldp7QRtRY0VOVoNM93vq1EhqsnIqjM8oNhwKGWXitsYGjBwZ9JfEa+uZfsSi lLTX19c3tXQa7t6DQbWdzcVFZR3qJyMc/BdAEYyA3PzqZ8XAHtuwGNXtLS0yjfHPUY5AFll7c3Nb p870hz29nyNQc2dzXYtE8xw591zxVPotmubr1wu0z+Zy778SsFne0VpXX9/aIb3nX46qmqpu36mR G3q7WNCHfxf+6mQMho7Kc7u2777S4S/yc7S56wmDWAzFF3794ZckA88nrDugHdT27eRZrUGjBvnd vSEKGVW1DVWdIMee83j0p6Jz3y/6+PbkV8YKnsWtZlTbduPKpUtJJ09kGuLjRaze/USeFXqi39yY fuaXQ8m3i/MLcmscovo74dEg4boruzbsPkXxHyhy4f1RFRrUS+saa+UIT/hotE4ENhcn/rTs27Kx c4c/Ewb2BETanLVv2/Z6yCci0OFPMNSkkaYf3XY0rZjhEeZj1+tNj78aaNepDa/tL3EdE+/7XLJ5 /HmANYkXFXwnWzb9aW89lX7p7b2DJx6ZsnK24z+sbw+A6govHLnd2FleUpKbm1tZXCxRmhgCO5Ky /mpqWlZVjbi5NjMzr0YKeHoKdS3VWSnXbleV55dXdqpMbJ4Az5nxHA1RU3XygY2HUu6UFlRUdDqG RtgzsIUNvHP4m69PF/pFxXkInuIH2Id/C57XiovCMIQAlCd2Lyrf0Z2HlF5p6FCYwr3vXnonkqhC R2dSV2pBhXLeRCtNRP64+S+zvR/c7rcoW9JTT6lDloqcHg9q5BAwbOF84mNR162ZBAikx3068ccE ApH4iEsrAoMwQL7rk0qg8f3CYylI44EfJSYQAf5suhEYBBGUROkp0yCCsYZEIN6b/T3QjyrP//Jz kcuLr48PBCUa9t28K0Q7UfRMkpv/E7svRj/xcZdaFAYhgES5zwCztC49NQmNWhZg/0iXCAQyRsDc mbT/goE94NHiRCaTRSYYyms03eUJj5aHLCBAJJMfTS+DdYpwj3wyneXmbk+oL6hXmEc90RY2fihA JloZ8GcWNWskfCL5t7PbWOPao3jnu8eOyAv0gL8434VYg+kTfkcNeC4FFCBZq3i0fYDcHbPiaVXc Yx4mQSiJRLpfBQrBEEB4KEUeqjz++cf8H874OfAerwGxDt/voJ/hFL30TTfHx9VdFIIQIvG3BaDn Dlj7TyQ9URxPJAETiH8wwRCqLUo+dPimBAkI5YAaoKMNcB2wZK3PAEvV1eTEKlVnc5nF1ZfvGIIO SwhQNRbuWvt9DdPJ3pGgMdL6RS5YvWqcm81TFZTeAUMwLtz3PM5RyJpn8WEGorJD33xTOfLbdxOE ZhXMvDs7SS5xCS+703z6dt8+WPEcNmBYW5mTcio5S6Iyk90GvP36LG8bMgpbJA1FV66kdUBcJ8RA seV1z0BI03rt4rlrJeLAAGeOKwGkErEFV9WQd/jsZTVoO5zavSegJq2ksqyotq5cSykr4nfROA5e bg74LQhEkfT9N+kUVr/oeex7ez2kl+alHL2SXacwEFwHTH5l2ggh1dyQfyM5pVHoArTWlbcJo+dM mxDrYUsiIM1ZiT+euI5NJ6Gb76yXXg1yYhPoNn4iG3d2C3ttK/FpZ4tgWdKelGYIaKWPXTXbkJt4 9ma7Z6hzbPyUEL4pL/XYhYxqtYlIHfDCxzOH2hJ05TnJR683xQweZGeoybhV1CmMX75ojK/AkvwE /QZpY27BtfOV0n5xXNSgpXlG4Ay0aO/kpZy6XOgVMTSS9sCBB1I2nD24KaMG4dlyPYKiPH2jh0e7 qeoK951IbO6QoyTytKWfDg8QmHRdFVYGouzSIoaYznPydLHrZuD5jd9kUlgDYl66TwCok9xOPZ6U WacxEdyGzFg0aaiQbGgovHXpeoutA9xYU95pH71o9pQwJ17PFxhQU33+9eMXM8QKg2toiLKRv/yL WU48N0/v8KyM9J2bU+samKNmTR8Z54Pf1+mmvxpCuY5RE2bOjAvgkPEUHVnJ+y/ltOhhYszAUB01 +pWp4b4R0b5tYgBW51zNzbl+mx45Zu7kQWxYeunwhqulIIVGtvf2jhry4ojQp1wF6QGSyltHd5xo gBAGhSKKGjR08ljt7VMXqtGJM2cEEhtXr9nnETJy3sIJdiRI3lpx6UJyXlWHjbu7SW0/c9GkKG+b 8CHTzD9XXzz2Q1aWwj9y5MzZQ+xZPc8p2KgqupqUlJYrRVDXyBFzXxjjxmUQAPOdK8f2JuXDFBqF 4xklips2PZr9uM6GGtWS1OTT2U0agljM9vRiaFStcvLk5a8N9rPXNuTu23ysHoZY9p5jZrw4KNgV 0EibGvJSDDq/ojtltiYQJbn6B9sxiSaVOOfKxStZpXq+WxBLLYiePT1e1DP9iCb7+N7E1maX2Nnd eSQRi7Yq52Z6nsTGRl9XUyNzGfjGnIkBQjZ+O04nvnruzK06ZXhMNEVcZ+T7JYwe7sx9wmpGzeK6 grNnkitb1US74Bkzpw4MdCQjkuMfbtT0TxCYajJuS0P6j5s8tT/amH2ioEJfoRu8ePFQu5ZfvrlM 9UdFY5YO8OI9XidRMGH1xuas8cw3Pp7iRuy8fXVffqdYj/CDB737kUhbd2LgdM3RxIVcCp9PprKC RL7RE2zZ0W8ucs6/nvjx2h/8hoW8Pcr/yZHC1p+9x4vdo4K4iopLeVUxY+aMGhZtA8uz05NTSjSD 4vtTmnPS8+vUbuM+WzrKhqTNuXjsxLUyGOCLYsdOmdLfiUvVdVTdzL+W2Kif5mcD6vRs9yh3Hgkx yW5cu5SeV+cTM+b+/SuoK++nDekCf2FUwnBzfX5SVltA3MAJI2P4fT56/w48h2/AoL69RQJS+d5+ Ltob3y67VIspzV21OWu++OlMtQY2tCWnF9SqDQA2Q40tm95598trLTQmpbLoxpl8CWA9XMQ0SRse o/bAruw6Cf43iuhlDTdv3rxTXlWZcyM19cqtwmqN0fotkEBiCOzNzcU7T1bc/TZoll4+tGvHuVzQ xsXPQ1Cf/MWK5afkCAG1yAuvbjuSdA1mcTuunLp0LVdthvGT7soKI5Xv6ekoLcs8cCjnft43uKek ZY8CM8/AtI3f/1SqolIIFmnbjV8PX2sykRB16u6thy/cYbsFhIe4Kq+8v3L5JS1mV1Mp6uqcTR+8 /+vFm3oCoOmSGSxQD/TjX44Msvb2VqOppK5B3N7a2aXpdryiM5gUY8WtvMvV0nuxIY0tG15btuZW l62zEyqp379+7+WcVgiAFR1tKhPB2cdHYKpY/fZROQzjDMzMwhhYlm1lYHH9AwbyBBgBBxKr7zPw 3K4tGANJ9u4YA2vOvo8xUIHiDMxJ2oIxkMjhYAxMzrhjZeCTgJqyD29cs6uqE3Fxse24cWTzL9/m tBlRgACbOhobb3eaqUjKCaclAAAgAElEQVRHyraTF5sVBtTYsvm1ZUm1RL9QkRdPeW3H94eOlZkt 8ku7t35xLFvHsnPkIec/+3rrsVKzNT09GYZ0rUUnDh6+VdlFwO9hEzqyd3xzTOUXEeVmY8y7fvjq nY4/+IlYceb9z0qIrmGh/oSuuhuX0zr0MIUEJZ+6Vt6qQAhke4b2h++OS0FEIy47+uPXp1MaefZC S1Pe4V3fXi5phBAUQgiGzqScRguHLElL3pN0LxdhD3wx6jolEgvd1suFn3dy79WCBiOE32P54KsN HO9QkbegIT89Ob1I3wNTcaPX1FhTdPJih0Fz49LxWw0dhuaTu9MrzBhhbbUtBrKbuzvUUXbmyKkm FWSSt+Vdz6xT6e5k38AG+2pKeocOBvXSlNPbfzmaBDEFfLRz//69v6aWWyCkZ/oJJBpHwFRVf783 H7xHAWIUp5/9+dS1bCqP3XTuQFJOtQFPyac68/rbP16qQhHDzaTD6/cn1mlQYo96GWxRdXUpDURn L1dC3ZmNl2/JMQkkUA2qO+u+/fZWE8ilSC4n7UsuaCOQ0PZTJ7YeKdBaYICClp/5YfcNGYnS4zk4 HpVR6IRIu8QFxWW39Z6z50yJdmRS2EIPbx9fTyci0SXAL8DH04EKEOksDs/Wic93DgiLnb94+Qcv yK9XNPU4UmQS2nLz4IbP379S2cVhoKm7P/7qywtyiMSgEVuzL29Y9d7JzAqEgsjbpCbEmLHjzW+O lAl9QwI9WXlXd+89eV5mRnFPl5bWNggqrqySiNulcp3V8YrIYrEIiszLebc6NHdvvxOIFGVH1g/b dxU0NuanH0q+mWUikp9VQu4+/PPx7C1gBEZJAJSffUOp0SjrK6sZBeqpDiVXj5d3hf5n3atBLLjA iVhzFAFAoCNr708n6ZsLVsQ7scTl6VrpAcCaPJTjGjpjnhd09oAEtU5/ApHjEDR2wmQ1CdUFTHqh vz2Jwed3f8gkcAfPe4d/mbjwu7sCrWy6fTG5PmD8olfmDRKQoc5yh3HDP7/+8dgxnr7BCYE1bkte nxVdyVu6W1yt0CUI6BBColpqzpy6SVB06AKAGhU4kv17EwyRfeIXvLng4pzjdB6borVhOfk5zXth hjuxftO1K/X0iFAOn8228zbkfX9hx2c/j/WNjJ8wuFAvQ6a88v4AXzvQQrARcrA5+Rj9GFj23iMn Try256xgyNjJI/yoNDbZGqHZLzxhkUW842az8V6YEknhme9OkXdWbRjrKjB31YdczITdOBjzUSIB FedezVCru1oLK/liy1v+DkHjxk3Q0WhA6OQXIm3J2Cp8j4HD5i2zS6Gu2AneZ+C5pPaQmYuWzB/M I4HiEsH4UZ/f+mxcgqevd3yo2HPhG7Oiy3lLtzbVKHQxAvoTB/Sg6uaFDIv3gLeWvhzqwlS1DuQy khw5FGvSB25A8NjFr85lJji/9FmXVGp06Mpce+rS+M+n2XFYBohtqDyayYscFeV9Orkxft6biyf3 FxBNVQGuRxvtsPIWAkldV7h967mB42av+HBpuLc9i0qWqFV3Sgsmmoc4OUQMig8KCXP5gx+YUbUy Oyenf2xIgEf/4X42Xk4clmvM0H7MIooZAvj+76x65eLWdTBsaa8uya8yTf1g9bRoB4uyxpl/xs1N YD3IRVjsuPmLXvex1O/6JbEmSwoN9OhRgjAVhEjQ11VmtiDyltK6AIkC27/pqKmhqNFhgsHL2WFY QrxDYCSnpxmJbYfhEdHDa6Xhb7xy/qfd7mOmjwTg1e0WGAVggAgbq88k39JBYhd3ptIIeTv4JEyd NGznCdexkyeO8IdQgj2fqKqpuJxymz1x5eoX4miINsZZUM5zIxEJSI/0E5iho2Z5OGo37r2rz2Di 5+Lj4zq0HyF00RuTQvtT5/5SXTd/WCi1M+OLxKufZJSO92A2ZO9FmGbP0DB7Zg99QBGUgEBNtWUl je2GztqGjmLZ/HH2LJth80Z9dKVi7quv+kF1P35/sTZHxl8Z+8aSaYmrrlhQGIBM142mt958J9y5 tw//MEyCpC21JdLWdsOQN1+NoRPvioDV7elB9m9MgUNQ7BmuVpPZDuMGhZ1vx9gnSf71gphK7c6G AZP4UQPiRF4h8T5ovc/Elxe96imgVNzcv3bVppI3RiUMHjUs9catFtdZr60Oc+UYTUR7Yscn/zlb 4L9ivpMtYEBN+vqDFzLi4scMcwuZNANKXL8vcvSMKWFMEhWblZiywY8aNF5grv7+DsNyjyySQLTs m88dDm5d//4KUbDfR2s+HxkZwOm7ofSvwTPfgMHSxF1bMiUJi94d6MWtPvXx4nw9DENqmYLBGRpm TdMV7OcsYEgABNB1dahQryEBLnyMDg+vQDdWbfeGS6LQGAwmC1vfuucSgcq0cXXzsLUVMlzcvLwf SnmG/YS9yGQA92xCUCfT62luDu62bAY2qdxD+juiHQotTBJSBXw7L09/AZfn5hMIlPJgBG1L3fjK F7Vfb/vPYh49/3pyWrUevSf5pN/xNZHM4CcsWRX6w7LUktFQRRY46o0EHxukxaCy8N39XG04DGzF DZ618+fpzrY0rCdUMtXJzZcfHRFoR3tQ92P0A3hAI4aNQCikUHlCga2d/b1sBAQSmcZkcKnkB1+t 9PJWFRA4KMCVg2ktHsFTF3lCAEVdlvzzpovOA2Z/tiiIIM1ImHoVJRKpdBsXV3eMgWRXjIFODzOQ 1k3APfdznIEGNsZAGxadDNA9Qgc4op8pMQbaUIW2TnRPf76VgVApq+ds8yio0UBCfw8XZyGTSWQG xL/7n3CGkEwwASS2QOgd4mzLIxlc6KCGAKImo1wG+EUG2TFIINkheObK9fY+ESRjidrEDXb3cuCz KQA7csZSNx2Bhm/ABAvf2SHYKG6pa9dAsXQqtv05RExf96kXwdDVLmkrLyjuUAfFisbyrcc6oEbS 1qkicJw8nbi9jyF/zPs/0GsRbZdY3lCb3VVr9ItZ1o/GIZGoJNw6YXIZuHCiqMVkRqk2nv7uXJyo 8IXvehLZXBIRmz8I1a+/v5OApVHxuXbKngxYHJA6K+P0rvT6yUs+CHBEr63+jGo9fCLyAz9d962K jHS1t1SV5ELt8uhB4f78x609Ah5MjMJiUzhMJpnEYjC4LIBPIJABVe705Wtmr16/wdemM+tyYYHS mhyB6+LsxKVSbN3cPLy8rBUgWpOBZCb5eQXa8XFhGTPvzcEAnUYmoj3TT6DQ6GwOCzDcjxVMIBEp dnYubHdvHofn4RdsqqFjmxtiULSRiD5e7gI+YHKwF3IoZEqPBhwiLr+59/Bh4pC5377lJM359fMb FDzWOEBgMuk0vyFBTjZMjS2HbqswIiQKw3P0C8uj9355/jKJ/I142H/mx7nSej+qo4OMwaOnj+Dr JU3i9PQMe8+oWD88w89jqhjhkeM+Y21BE2iPbfDq3GuJtSxrBigUAhnuNl6iYF8+xUz0jIzydbVn Uoi+IVGu6D6dBSFTqASKe2CYb3iQl6B7jzS3KZWkyMH+fCrJRHSc9MLSSQL3ACGNRKNhc01IIvHt hcL7KVIIRDKFzmJwKaSHxpdIsXfxFXnY1paUsBx8hfbOPMY/1uetD88ez/wIGlW3SWzJ3CGx4W5M U8G+O4CiVQlRHUMCqlt2Hk8rba7N2bnj4p3yRpUFdAgbTiRtWX8os0PakZZ4bPu+YiOs01ssOqVS KZdqYKhLIlXJZGr93fBvik55bVVjR2dDyuHNP5241aWxQHp1p0zV0SWFILVEihXTcTyibdw6TqSd KWlRGNUd59a/X0icHufFMVv0bTKF2Ky3ABaNxVQnV2tAWNdVW9fiGtl/iCvdJC66aTCaNBojAhk1 apWkE6tT1alQyTplvS2qGOjOwz97z3PxkOiNFzveXDiGRQKYto50LqQD6BFDR08YO8zPjlaWWqKy wCa1QqZSyU16lVSqUuohq37+JP2YaoxAZoVE3GoyidvbVTKxQo13HwKNSrmkSy3XYv+pZBK50gTB HnHjAGDzp9tSJApFXc6xVXOmfb22UK/pbG8juvr0F7nbtt5KwiyBLim+jKLdDKxtxhiY/OtGjIFq I4QRILYSYAZxAlRqPcZArlMVxsDqTjXGwFNfL8cYGO3Bvs9AEDBjDKyRqTRgT3yhcoMD2CnJSZdz KpSKzrxzP4hio9M6zBazRdkmM4mNRguiVRvNZo3KgvA8ggGgQUv2TJg4acSgCIpG01DRzvEK5zrW bD99uqShU9VWte9D9+HDEw0orNdJCWz+nPf2fhDP//6br09kVRoRpPHqf9YV8Se//u47b7wZH+bT 0dFgvGuzgek/Tx8RH7MmR/Y0aTVXfvn613r/IW+8u/KN10d62zRJmpUwQGIAlakZRV0qScaeXzJR VKUHBY5CWFe599jV1q6uqsyTEybE70y/AyFAp7gLadJpDLDZBGpVGgNkNvbEFRS0qCTtRgItPDzE FpTe0KvalDITDOtqz7+/LiNqzIJ3Vy5fMCTaVizRmno4w0YxoexSd9aaZGodhNQr9F0mFK3RyRXK zpqmDv/I2CAnRnNnXbZRrzfo8PapNuFESmtTu06nKr9x5ocvtjQzXBzt0Yxf9xQ1icUN+d9NnvD2 tjQjiPRIP2zSyxWqVnEXiuLiIe9SGmHEZNa3yhUSixEETGqLqVqq1MEw3X/8xyH6lwa//POOnz7+ bO3JLIDTyxGESaUhKk39I8KDnBnNV6q01Q1SrRmzRqXtEqRJrzViBJh1GjlGgAnGE/st/Pwz1Z5P 53xZv3v9En7vFqFZJZaBiNFkENrx7Wjl6Zln6jQWGNTLlapOmRpFNWKZXKnED9YsFlCv1xjMWpm4 4dLm91Ycobw2Mhyg+X64+8iuTVZs3rp1w8cT4ryxDZAsBC59te5IelFna8WR79elUfxceWSDUiHT auUGnbKrS6U24sY1zS4iEKhBOOHx48aOHOhM1Ulbm9TYzARN0o72FgiSNDer5BIVHm4VtZj1CkWX RC03qGVq6xTGkzlAuvQT69/4OfVI1u1Xh/A/WP1Zcqn4n3TTrg/PGc88tpa09MqM4ZHWumM+/vhV 7H/uS07KlZ1bVs+xPnTwA4RCAIhcvlOsNtec22B9SOUDPqEA4Bo/d2fihXlTBjxMIW/uYR2KIhbV zU0fdf/gFjlxx5UyrQlO/WjQw2/GTpqT02FUNeWvio++m+UyZOmNFhNs1iTvfRf7K3LqK0fOH5wx DPe8WH30hqIjZ771LRsHhzmvzYt0c5/75u7i67unDHB/uNpfS3tORdANbWvqALbd0DWp9wPhKetv roqPuqf3Jqw/mdnekvvlpAcVBs37srhNi73ZI/0dmbuHRzwwUnmT9uoQc8WVvfGPjFvowcxaE4x2 FRwe3/2A7zzqox2VEj2srd/+4rjuy1uzVq6cEgY4uy+p0KGISYYxsJ/1uWfsDIyBRvBxBsbPfQMj QFmfjTHwLv1hK3AGGmX3GXj63K77DDT1GEzfJDnz3Qjvu9fHQjacLIYQc+mVnbHYXz5jPz2c+sNL U/DuzfupUa5vz/l1yN3G+ZFDV17Ir8dWZU1T9up+QXddbhJeS69TKltyV48G/IdOu1Airby4ZYA/ JkHA1htVxVvn3ifeJyr+dG7T3WQElrZvwgI5wJtNTxdWU/msB713mvDS1nIp1j5cfuEHXxcbvPcJ YZhwBoZ/02zWl15dOym6+023Vz493KYwoKbiKdhfTLuwd07fPP0TLvRxc35Mr++pJbC1JHFBvDNe OnLYpCnD7HiMV3bdMpZsv9+8jU/sx/tuqHqIUYioWnI/Ho294v/qsh//89LUuBmfHz643tmety69 eNfSELyw0Nlnysx4kXPcnBW5LbhotWb+6uqAd4FKZ36+PVlmhjurbi2fdVeIBr3wQUaDHDb2TH/h nnfCXB+kthQ4ux8vrD7y01L89/krLp7bMirGE/v3FxeK8Y7p245t/GT5Wys2rn9r9edzTxVJeuS0 Tly14Z1p1vr85syZ6+XlDIz6rlWeh0svXTh0xSmMABH2736zdmZ1D2LX155uwNfXnjZ8YM1rj0wK IGzi0ssl0qbLa2OsEmIFxdljSY1Rm3Nio+jeI0z+j2Q2YvpHL/UaE1cOmfb6K3Np+GmT3Yi3U2pk 7UUn3hr2oKHu5Qt/tS3z3Xt++YExI3ZezFOZEYyAALd7LmNkZuiSk3pYl7Hzm+hHiI1JbdWWbMdH wMEnZPf1nE0f4cI4YMGnRa1PW3D68P8JzycSFmjSGSEqi0l9+BILAlmMJgse6/yRvASoSaexEBhc 1u/49opfrcEj2VNJvxVAHDbqcCcnLo/9W0FnIMzsozJ4zN/76fdJolCTVoWybBiP6P54Uj88lcTz P1DC10CNkUSlMxj3+4DodHqUxGQzHr+bBFlAGL8cRfotRw/YoNWDMIGHn1j+GViMOqMFZXLZlN+6 a4nRr9EaqXQW4xG5wAlA8DwZT70oApnNAI2CGo0mmMpk37/1ZmlKjRn7xsD39m1bMvjpreMVUCmw 0QCiZCaLfl9eYYvBhFJYtEeGDwbNRqOZTGd05wb4o8CLm0EqDU8Y8Gj7qMlgIZCpdPoflxZsD9Br YBKDzXhCgmGzDgLoNNqD70wwaDQaQYKV18/q8AtT7QyYMozWpezbc7kgfvkPL4Y9mRv4busmoxml 0Oi0p3EPTzphgTRlp6Innz9acWKQzV8dLAiFDacWj2mc+t2SEWFsFoPymzfuEMRo0CJkGp4e468h sQ//X/DPDUXZhz78aSirkl59v+rjra/2c3vi7kofnilAY+fWd0f9WOZK6VKMefG1D1cvdGX9V7Fr ZKWpu8+lFp+6VKxWv7Y9/d2xns+I0t9PwMVX31t7h+ozSsCb9PX6SZ6PBx7oQx+eFfo24D70oQ9/ HghsaSovaFKAAidPH09XzlPcpX4fDNLmyrpmrRkhwDDXq1+kN/+Z0PlHCGgorWk3ghbYTPbqP9ib /9xj4fXhX4u/dAO2Hnrjdwr/rlDkfzsBfzes/Qf+vf3/K2ENW/VEJLF/JPA4VChAJP4v0PrfAkUQ lPDvWAJwCST+5te6PvydePaxoFGLuqGqsqqmvkMB2dnxHrqUgCjrSy+n5+vZ9s48+rOUCgTSdDXm F1frQAKHz+09nB0iq8y/erMY4jvac2j/QrGE9F030242KwFHJ9s/GPSvD38UUNWZvUfaGDG+dv+M bQ3RyjuqSkvrmsVmIp3DZt5fl1HI1FJx82pWh5uf+3P/honnJ2guK69sbJNT+AI27XmKIahrqiov qaqTKIxsW1u6tcMWTeulpAwNkWNvy33uOxOoa6goKa2ul6ktLBsB/Xm0h2jKb9/uMNDsbJ+InwaA 5ce2HZII+vvY9j6qSEd5Xnmzki4QMin/DDn9l+HZMx01KmtLC6+d2/H5z5cU5oc96hFFY3bShWMl LaqnG92wqm73Lzcb23W/0zZHEVgrrjx18ODOg9fUT0vegkhrrmMEVIk1z83qR2U1uds2fL77TIYa T3gClSXtWbX6w6tl0v+mUtCoTTu06dOPNqz54ouVn3+z/cTV+k41/Mf7YFaLE48kJd2oM/9GWXPx np3Z5c3mvyQZ1P9TWMovrtmTUv7nEiUpq5J3p1eaoWeYZgnRSNuLb17e8vO6/VduKR+KYgaDpqrM q9v35ah+ozWo+UZKxplkmflPUwU2Zp7f9N0PB89cOHPkeFGLCn6OaaT0WTu+ev+7/ZdTL589eq5R c3chMkkbDu68ePNOB/TcRVuHEbBiw2GMgMRTSfcJeNbQ3zr2/vr9BeYefrKUnPlsZ2rtU3mMNORd 27J2Q6Gkpwr68Pzx7CNhEZjC8EEJTnzF4Q+MIPiwmBMdwhKW8kRCr0dtAhQGLRCJ9tC3I0PzhbPV okFBni7sh18EEBiCQBSP2v+I4kwgkW09RJFBVTfzO586r4guMeOXOg9y9HpcJURhCEaxWn+jayiC QCAehJ1M7l1xsahSks7kSyWi0OBYV/n3H319stF/8ALS3QogrCECifyHo82B+tbb2VdBz5FhQuOJ fT8VdC75ZtEEx+7EUChqMVsAIoXaU+KHh0Hju7+4ZBHJxoX5xACgBArJ2imcLkSdduEkIogQ+bs/ 9kUPox+EUDKF/OTBFgLjmQpIj+eEeKQhrPfYKJAJsAXPfXDPE7tn+hHIDBKoVNLDR4VW/uHjTSTi hN77BQZBjKtU6m8L81Po7+FdM4hSaL9tGOCh+LGtkkh9xIubGvvWxh8o/Z+gCcWIJRKJD59NI3h5 ApVifddKl7b6+oUmwuwB/rTfMUFRFAUhKwOfdt5NFLj4xk8YW11cqGrrAB9S30hUpmjY7A/9mMJH 28L6j00KCoWEdOvpqLmy8MaNeoLDiDFC2m9ThVWA9ZREeYh/qLE461aLmjT5lZnOBLO9A+dPx1zE 5YDwQNYQKwfJ5IcYgChP7j7KW7xrVryTRWtxZt4dGrr9/7F3HmBRXN3Dn9leWZZddum9iwgoKIoV FBV7ib0be+8tauw1xthj7w27olhAQRFp0ntnqUvZXmZ2Zr5Z1EQFjEnMm+/9v/t78jyR2Zk7Z247 99xyjvucpd8LXRy/xtcyrNEgAOWTrc2Y/qMI+kAYhD8wXtB6XADBvMvf+bN1KvQ3ATBEH3gDr8HN 58D1kSrwakT8M3EuCNz2HTwO31aAqD7MBUj+eHs5tfPSwwcYPp/VIH3gGQJIeN/4iA5+PS3PXJXC AIK/XN98v/rVBr4F/4ACJrPMrVlcnRMVKid8aOYYJH8RfuanU0+8eo0cadbut5trM59tmbc5FUEZ RKKPd6fRazba6qrTX7+pqStLTLLU1LNAuoV/Z3c6bhXXZJ09+MvNF7kA6Dh46vQp33Xk0nHhFfE3 zx46cl/t1dODpZYCrR5ZwbQNLx5e/PnMM88ew8dbvzumjKZe2broSWOIp+DRnYd8a9dZKzb2amvR crPCIFH285OHTkSm1wCmnjPmzR/SxZXZQiMGuY4enSxtX0XfSCiZZ98YeyO9jNx1ZTdXY1V9+dXj v5x9GI9nSc9Rs+dMGMrVZGyYvE7TZbivaXXUrQSbkPGjR/ZztWA1fzmJxvTrNXBgXW1Nu+mLOhol hG3e8jShdEB3AdtEV5N2aOvC2ykIZmLdffLiJaEduGRAJc6/fe7s1WdVIVOHmJRGhSV4/HR+Epb2 8OjhfSXm3aaNnPZbC0ekhae3T7/wGqHRCZZtPIOGrhjWlpqb/jyiuoYZG9uWpcRVnWOHQDsOEYOU mdGXj58+/7YcILTtvWbhzB5OpursG0PmHfQOmfJdd5N7P+95BbmNmbVwSoj7Z/2zRl5z9djO61kS amEhw8XVWK0sKNeN3/Lj8AAXQn1Gc/ml5emnNu2OyC3REImOADDyVHhfe2qjKPPKyaNXIjMAPp+g cVu6cUZIB1syLDq7/YdTkUUYjefdZ8KqGYMs9J4gdKK06DPbDsXwfKZ0NXsTeYPTdcuaUW55zeRv ZcSCihIert59vKy6Ae8OF+y9NLy9ud7DTFVexOnTYVmKNh090NIXVdxhu5cN54CVxzf/cCG6BGCY dRowacmkECGLqBO/Xbr+Z4kKaD/aq7d3U4qahvgHt69FlJoJZKkpyRWOA3Yun9HBkkMEVS/O7t5w KhKl0Ykct6AuofNmd2ooyEt4+zq3jB4TS6WimJmzXxubVp15iVMfbFy0Ox1Fja3dx81dOjjApZU2 QKCzTexcXKxNuEUfe3lDKvfPGPeYIRzab81vqhJVVj658OOBG9lyLcHJlc4L3LF1lFNV3pvHmVmv K6iukZGVHIq5u4+T0KiVgShalRF1YNvh1xV1GIEwZe2RUcFuoLQ66dXdM1EJMM22NOVVFdd9lG/L Z+HE6Y+2H4i2CexgUpt0+kFsz7GLp40bYEmHM8NvHDn+wOK7sYHc+tNnw4qqjdafOhTkwEmLOLNr ++kyFLBv22nWgiX+rkJ5UcL9qPDbZfJBkvyEl3kU6x6++JAT02Q8ufTr1fNS24ELnOzeqT+o7NGc KdfN/Sy6j5oAp4WfvJfv23/glNF9TLUlYcfWn4gogxCC8LtVB6b3NaMhdcVvjx06/Di+EDQ3B2XO 235d1tGa02IGSIoSbj65iwswQpKb8FLJdgjyZhB0qvqUZ+ePnbudV4tZdhm+aMakDrYcAly2JXRG hl/IzMHtM+6fD4uuGzB55rSxfUw+Gflikorc+xd/vZ3GCuzZb9qUAE3qnWU7HgO15Ilnd7k7eElS Y/Zve/LoiaRz3/Hz5oVasEm62viZy/eiBEaH8YEhv5WKuvFN+PGTl8Pz6wB9jBN28NbFoXw7WxZN /OOuHw7lJzn5B8+fN6+dzX9619v/Mv/UvD+KfbK7CyRSXNp2+a6PfW1tfG79B7eHQO2FiQu0g5fs +2n7dz08RSnpdVpYUlOakJxSJ8l9m/w6+lXUk9gsOYLJqtLPbp4d1ei6bPOWlTO9Y65tuPQ8SQ6r n2zpM2bBi3ajxvcSyiMOX9MArW7BBEl0XIBh3U1xAYoa3823gELPjg6Jxw/dl02eN6sdHz574l41 1MrzKAprQKFLzwUrl47zqD8R+SRDrGjxRnzIzyA5h3R3SE5PD78TPXjhOMAYt+1AGIZZPLtxcxYv nBScfCf2dXolyjKz49Uc37NuZy49cGivmqSTa378Mb1W3TxNECRQGRyQSpdhuPEEw5ViGQV/D5Gg yF3Ra3iS0fAN27evGuNdcmLjvn2vpQ3ZmzZtCMvT9B3WVf78yNLtx/mdXfkkItfaq0/IAKRKlZb7 +xJAybOdO1532bj3p8VTgnXVcfEFYpWsPj0uuaSmITc9IS4mOjIyulKhAxBNYey9X3bf5XWbu3Xb ujFmKVsm/5yUX08VeC2c1id+98oFy7ezAkcM7dlOSAebz0GQqCwHY1NOYpZNz56IOKuGZRrYRnTj TbpUnNlcfjUgi/8+qOUAACAASURBVDl4JJ/ddunWnevmj6h6/rxMCeMDuLjI6w8z6pZt3r5qVBd5 eaaoTqqfINfIlUTXyQuXLRrXUZ5x+nRqJf46Udy11at+ljn5j/Qzubd03aV0h8B2vNKW5G9lugSR y7S+PQcv37D++168NdNP1SCAsrbw3N4tlxMau3fzlD++cy5c6+bmQMP1j1qmY3hOXbRs7lC3itTz 17L04UOITPMRo8b4caJuNf2pL0Ey3dSMXpt9+WWpLHT8JJf0h+Ex6UoIgUoez958csq6ndtXTnMh 1WbmFWo08qKs5Lis8rrsjFevY15FRqaVy1oWswmVRGIWNGr58hW97KlPLp7PrftypHfs8xgjBOMu w6cFcGiPY34PI1H99ur+CPrEZdt3bVlioYq+86ZYpVWJstIzskvKyksSXr548Ty6sFqqa2WFoi7t /sKlqyQ2Hdds/HHRxJ4nl0xbdzcHr8M0EgUDwWIlDBEobPqncxsfYSS0ttC+Obx+wWuFybSJQypu Lv5+wokKLUno2dbHlfxw6+yVx1959hzQ298dN0TF8b9OXb3PZ/KKLVtX+jIbft55ICq3jkikMElE OQhkNmhYLBbz3cwESDZzC+jfs2dFdmNRxfvGSzZ29u+ku3DvQXatuCAzolxa6+HpxEYrjy5Yeq/U fvHGHXu2LLKOWTZj4o1GVe2zh1dzlKxVW7cvHuBRU5BaK9e0toEVF4BF1AuQUafGBWDgAujkMbdO bzn8zDZkxprVizxlYfNHbsuTanEJAsb1xu5vm79sWzbZa2j/bhY8Nva5G1yQQqXI5dW1cpFHWxNx eSXCdehAj4ngmjgJybjpq5RHSTiBEwZY5aRcfpBSjpcjkWU1bsJEH9q9S2kN79PQyeJun19x8AXB b/T8mWNUkdHXw9IVuDUMohAZQWGT6dNGE0QFd8PjpAZHXP9B/ql4wJ9DpJo7ePfrUVUQkfrR9BeF 41hxZfM1wRJvExO34Jn9XLh0C/POM43VkaK8yTOGdXA10T9JQMtEubculsIhClF2FqKqq64tP/gg o7crtmN/+tLH96e35YDqWiMCdikFanXBg0jHBejbvXdRVMGHjgMUegR2ABQuW5eO96OlGpEazxXB rbQovSd3SJH44vq19UkYrFG78cQjFagluyV9j6kAQeeB4++f2bIoLyQi2uX+UhQEcLk0jUWvT964 m12FaDRt+i9SIhS7br1dFecHP9w834wMBvmY/XTkyM3oArZ9/eMXSY0w+m5TKqyidp8x0xuk6Ery j23sfJYIwvyQnT+P9rAwaky5fjirYOxQICcpWaUQS6vi8ktjC1MJ2QTbmbPn9vY0Q6GupYec2gd7 M0ACZmobGBTy9PkzuPr3TCIQuOWJh6/doTvwOJ17L/Hr7sy1ZH43b3ZhdAJp1MwZA/1YZJBMperU 4uzMmOfVtUPENampDZLqqrL89KL6SX7OzoNG9ruy4vCQgzeGttFP7IMEYvMqRaIwHLx8AnzjPL4b 9qK+geLTe7gZIz6LVpcd01x+GdyOYSZ5sfcRBKk83E2CdxzqYomLr6ZgpLK0jGvhj72FxhPmTuzR zhq32HS4apZkrJy8HcR0ENtlqn+FJtA099Qju45Dps0fY8UmDrMXOwwXdHBgxMS0IL8/xmtpKhrG QF3+/W0742tVKg1Apom1iC43T5mtm7Br+0AXtqarMG58kZ+DLYVI0EGYpDJxxfYtIAZruT7WXau1 /hZUhrBLtz68ok4X695XEJBI51tYWfQfZO8947s+Dm1Ud9aVliq0fkYMFrG89uKdmz3tLTwD+7j6 BHDZZt0HTbQBU/NKei+aHsymEAjkL034ogBWHnd8z+FCxAjybz9Zo/cP+me8eYAM314DdIq6+Ku/ rwoTQHZDwb1bd4jtnByEHbfs7tzZiM33Hzp+RpkoJp84bdkqZ2MSiUIhtTyNr826fTPN6rtzs6d3 wG0ppLOxomrelqtL+q5v1zN05IvXqVqHoWMm2xmRWlvyoZo6eVszOszYuXrmEEsOpW8v93l9VseW jh3h4taxg0eaitF72uo+bczxMTGBDN3ctLCwzEerrUxNU4jr5OkXypJ8y7rNaTdwFG3ghiNeQ8aM 6GymX7PQJ0zkWbv1Cgq+EJaga3jfzkEjh8lr9wutNo0Z3rdTnwG7jh7sYm+iLnoclpnO8nUtTk4o oLNgSX5u9Y06uBsVATPjE65z+W2FRjOXT21vbdTaXDHL2nPoOPLDLcfbj5w0wosOgkRtfU5cdKaJ 05S5kwfjVnNPf/PEblPuZMx1C7Tx69Mv9fYR98k7VvZrQ2pqQs3jSjN45gHeXatFGYD82bo1t7rO Xc1VATMnhdpQwQoAFJiOWTBzHK/RR1z1pC5FqusKUBjmPXoJTfP9T8rfN3aVuOT166y2naduWDyY TwT6dHC1vafgkAkYDJiAwhVLF45x05CrNeVSJWTY+PEf5J9SwKRmwQz0YcCJJH008d8x7rPixtkR VaXFoqqU16dfXn7Ldt4X6kzA7ymDML3LHHrT3XrPdGwu26l7Gwdrqg6w37y9p4mdmwUpPRnClgtN 9Gt/VDqDg1ds9AsWfVMYeeLHAuBaCf+DRqeSCAQ8Df0CUstLIGhDSfLenVsaBuzOO92+MeHU9ycb ia0f38IAqZGN/8zxAZ6WY7x5WWjG63JxWfzPa8Jy/I8/229NLJ4z7wSRiIAEENUpAS8ul67/AjZH YETma+skDfTizLcpYgR4F6AdauR10Tv0hDgunpvCzw1Q/zp3STIJxr8DhLRqGPDq4u9kBUAI0cGr 8yBzGzu66A4mxfOZRCSRyAAqx7+pKSQM2FQA+rXTjwYpFp3GXrsYUFeaKxKnPLkcGfuWtHffd3wA 1GEYgUqi0qj0pllaGEMhiMjne/h4ORgBCOi84eQoY/d2+nA6IIbqKF3beZhRv9TtY3hW4+8mNGUa BpBQRB/tAlexzeU3JjPaDV59wCknr1Akb6h+uH7bAYJ38TI/r54jtrNdRbU1YlH2yUO7yignN44L DJvSeb3Hobf5B43U2ccOHq7GO2WAgApRNQ3BzSO993waAXDD+0msRflb7ECrXp5YsDxy2Oqzm660 xypuOHa6gldbgA5CpjodBpLJZIhKBB1Boj6kuuLkKK9D3a6mFhyjNSTuP3IZRN+F89CHvCfideqj 9EGMYEpjso3YeMEYC7zABg6eK4CRx8/XrtRIKsvKK6Men7vzOsHceV9bPhUEKQQykYZD/eKiXN0z j9A522++Kg6wKb9/+f799D+a0yLQADxhvBb8Lpm+VeBjvY9qBc+915791kXZWTXKhqSnW3bsFXsX brPB2w6KwSQCGa8VX/LvhptTEMakUWj6eJH44MuIx4c1Eg0CEikkMp4IESCSSWRy6z0PiCEKQGBt wqRT8TrM4JgKABjRnx3CSxFzsXFwtLX44EoMUtVrqN36+jhawSrEyaFN7+kCBycH/VsI+viFGFlf Xr8njDcBYlMT+L3tgmQK3YhGVisVdVKtQo2QCKDeExdq59PWxcGej1uDbqsixnKE5mw2K3TCZnNv Ua24rjz15IWtStvny4I9KC2NQvDXkJsCKKKU9wJoERjR6qgMYwZJ381QWDw+EUWatrPh0jBQpotP G/oXmhBIt/XyoqYlHz95PzfzKfTEoiau46bNtvi78dIkuboaU/AhkT5bEQT4UAOJ+hr4ARSBIQhg UIxZ+MAJAIyce6xc0pSDMICP72g0/aKwvncm/nOzogZa4NsrYJ1GKq6X1uWXaLXivOJSDZ3Ac3Bg Ycrqisqq8lJxjchIVJhrojEzExoRC+YFD3XcH75qZqii+AVK2InUK/EaT6Sx6PRrMVmuFgy7rOi7 z2s9F44UOjhRyhCGs68fSSGKe3QvXUqyDvFYzTEa/P2PkTtGkSpenP1lp9xpXqNMbc5vFiMPwLRq WW1VtUhUhgtQXV6Yy1BaWJqR5CVlaYAmvxx2NauoLkyU1DRWS22sOM2bFIYSTAksCz5DVpYRcSKy 7A2ptKYRRsypnzc/TFnfUCur0Ihk8+YfG0jF3l49gyKpBaUKDCMxyOYEdd3rZ1fKs9NEZbUqXHsC ZkDawpVHnab5mTy4eOpOKW3n4ra+rl19Q6d8+nZdZXZZdqWo3qLaauDCuV3n/3DsmJnLyhBHHyN2 QVkjq3+oO9pY9vz+i6JC+fDBvfzRFZMWr5gz1Kti045rABDUtM1HUltVISqpqa9Q1onyc41MzMxM jRg51+ZPiBn95tBME2UxD0US1RIdXgA0ng+L8zi3sLRMqMl/efdOweANS/kODjogCmPbd2jDFRcm hV16QjKz5nDFVaLiKrg6PzufwaYaCSy4rJZC0SGwTFRRnKk2qpHokBKptEzJA/IaKhAbr+byW1gA JzeuzRIGLZ472taYYFW1e1NZo0bT+Czs5LEo2t6f5zuwGogpeVpd07SEihZibUqG6t7cfhh1JlE4 t1KsANsO6n9g2dZl1SXdbXTL1/1M7nWURGW0JL+N0IXeXL+hmI6ICYwZLGlZ6qMDPxFAfklRXVcb Z5axas/CMQX9Oz+9feO1qnfTeA1ElbReljyCqjo27NGry0kellUNKg1FWivVaPOqq2FxSUEJboEx bWxM5YrG7PIKvluDGmZWNIrTS0saIJhdeHHwhGc3Xh7vPwD0ZoMRibJ3UToIJErJ6+T0vm1MlEUR tx+zghdM62rZQltTapg0oqkxvaHk7a03Tx8rqN71tZDQktJ8ZIEhMll9bWV+QUN9sa6qJC8ftrSy MWVBdeVF4sb8kjK5kp6bX8xnc3imJpUvDi4Ko2xdM2+AJStHWPF8WxUMAQCdYcsyZdYXFxTkw1Bx +PU47xkL+no09zrJcAzqJlxw905bZ/6g9pqy6C2LL5iuu2JN1h9AyqupLdZQSvKyMIG5jSWP3Mqu MbIAuLtukzkNG+xr/ODgD1HGPpNMqYrG6tLsmtJKoCQ/l2LKtbQ0pVFYXcZ/T1tRigomdjajlGa/ efjytYrAEbDQqqLcAgimZWeVCJUg09LGjIVq1fV14qrikkZpZUV1WX4uZmJlYwI2PLu8a+ruJ1fT CqT3ty+ZNVO596cBLo5cvrxSArr6deEQ5MmRD8MfZAutSY/PH4+qsF+3Zqw1rTv8KosItXpIAFZJ ygtycAFYGeklDB6RZWXJs7Ztb3Hn3uFb0aaB9vSEyxujZf6T3AWYVlaSX1CarkHyM4sREyMTnokx s0W7mmNux9DBd1NpP2489OzCkYReM20FTHy4U5RbCmUBFY0agUzZIK6BjeVyCELFlTIIzquuQaTF BSUcApFlLbCx9TG5euuE20NWTzvK66uzVh8bHJezlFFTVJYOa8tqtKZgQX15ro6ikGj4vG96TNRA 63x7Rxzi1Nvbfjr2PK36tys/Xn/hp3nzw4QVSb/f5bTmwJbBftSdQWNvKNX6HbQY1ytg3Prtk11M KACgTr19fPX+yxUNagKh59qD84d2sqzNfLR724ZnWSg+YvfuNmjWvLntHQWA+O2mflPvIihuKpvy wUrIa+qClbMGenw+ksTg4rjwrXM2fizAljM7yY/nrbxUxWD1PXZ2dOSayadzzfp9N3PZsiEmzUai sKL+zuk9W048wACrrl3bVlZmFHNCwvZOdzBhfFJTEUnk0cP7TlwXAe13Xdrcw7jQv/98fEDhFLpm Yw/FzsU7UlDAMyDAktKQmMRceWSL1dsVbee/Wvx996ioNFu39nNWbAzysWquEjSSyosbQg9GA0Kf fnMXLOlnVbN37fZb7D5X1o1klj9ZOXF9IoKCBI57+yFzlo0KcLcCJaKoR4/f5DS08bO+OGD0wAzp CNOGc1vn/hpd+Vuao3/YP29gYM2dtUO3PMLNHxTFrNv4L167uaenOd4p1uVEzli2rbBcjA+kxy7c 9f243iyoPvLswYPHbpbqpygdh3w/dfqErvnHBiy59H45zdi5w6QlmyZ3Mm8mPi5/ycUNQw9GW4QM GOnBzI+s5A0ONj3765m+K48MN875XH5n6t0NWw8/eF7f5DOBQAw6eG9bF1PtkxuHVuy63uQ0ArD0 G7Zi5exAZ0FN7NkBc/YiGNXaupOXF/IoA5s6b9HsEFdJUXL4/QgRZtGG/XzS4U4ViTMpyubyB1ka 0Zt3NKiy9NLKH49GJ8pAwqDp06QvzpUTRv1ybhlPWZHw4lF8kVpgVLX3GvPoge87u5tWvPh1wIKD KMZ0dPJ3sFdFFrEWzB9NvHvy3IuE+vfpEflmvY9cWlLw8Pjq3dfb9h/3fbD1pZPn4jIrZ/5ydapZ mt+ILbi6xL/UyLrtqFlLJvf3ZREBVJ5/YsrS4/mlEEjwH7xg4ZzRnsLmw0oc+c1tU368kodxBba+ PkJRKuTUZ8XCuZ5mn9+MahtuXzmy+eew3660mbz919m9U34ZM/di/m8XuwyfMn/OLKOM80v3nM8u k+DVgsJgf7/l1PRgV7xWKCqzDh/65eKD1yAABo9aMGfmGAeTFqXS5jy7vGLnqZJqCW6J9V388+oJ PSg16ZeObjt8L+f9La7jww7NduAxWuroNRFrR17StRG+fPVEpaB5Dft588IOptpbFw5sPXzvwz3B +y8tD3QXEADlvaNbfjjyALeQCRaOfcbPntc/kJxzedmu81mlkqbsp5n1Xn9rez9VQcLhHWtvJP1+ IBDP/6CaI99tfW5i7Tjzhy1o3Kmdp554hU5fMnuyrTZ13+JNd4srEZBgzAtasPn7UG+jh5eObDp0 750zG+vOY7dtmucpYLY4gqiKPTVn0+mSGsU7AZwHbz73QzDQWBFx8sjh8/eqMIxg02f9xsWDfS01 hWGB32398JzDmBlL58zqzGpZ+2lTLpy+/qax/8Khr/bvJAbNmdG/PRvInd9x7EuWue+oFdOs8vf9 eLig/dAf5w0WH9h1Ljnrw94Bio3zgF/O/2CuqQg/8NOJ60/LMIDg0WPzquX9vLg3FwZuf8ny8B25 eJLFjb1bH5V5zPph6YQhvgyDHfwf4V92RYlAkN4VvVYNIUQa45MtVCgM67BPjnbgZpwWgggUKuWT RRJEpVATqAzaP32QHEVgrRYhkv+aI/6m8yeQfsKHSiUR3/0tf7R1RP+7/qlXJvL4VpYt92VfkS6m U6q0ZKp+Jv3DmxR56dlyDFNWJ04bv/9gakpfm1YS/1AAGggh0xikTwtArcMon5ytwSD8CxD8Eyh/ +hzVn5Ef1ekwIhHQadValM56d4ADV8Y4+ulJGEbxMvjtGA8GqZQwyGDSP5ZdK61Mza4mERT5Tw9s uDs8OW4048/Jj6pUaoBI/7hK6jSysuIysUTamPto21mTvUcmdXAzAfW6TaVGCHTGX3NioS8AMgmD NDBIIn96kgqF1Drg0wJoAQxvPcqm1vPtZrM+FIBGrSXSWZ/GTkEg/QkgEukPD8ugGoUKJlAYjD/4 gM+BFVVnF0xI9587rpObvauLaQuTFJ+iD5WmxouASqOQvqUzL1ShUBEo9A/y62ugvrNEdfpWTKP8 mdNCv8uK9yFaCKEz6H/BR5o+lAqqP26GaNREKvUvfaxeAFinX3f7S/Ib+Mb8pzZhtQKR0nSSlcpo LgeBTP4svAuBRKaTmi+TEBmsFo7ufHsIRDKd8TdiG4FkMvWjBSncyil+Gg/04Lw8fokSEDRxbFfb v5guSGIxP8k/TF1z7/TRNIWypl7badWxrq1pX+D3AqC3VADN4uuAFHz089ekbJ3m8hPebc8h01gf rd+9W6nU7zD9tAxACoPVTCZZScKRn+6TSKU1Gt76A90Yf1p+AoPxuQt+bWN51M0LTxOyMApx0OxF jtbsdx0YPvj7G976v9QCKM0DHDUHBKmMb13/PxQAndWsvoNEyleeFSXQ/iCSVSvIyjOyyIK0+ChC ZkL/5et62zD+4IGmQwL/QMAEAuuTjkVfA/X/JxL/RoQzkEylfXFT3RcfJr2rLACJ/hcH639TAAPf HEMwhn8NVNOQlVOKgAQUQ43Nne2F364bRbSVpaW1UjWVy3ews/wfbG6wor6kpEKlA3kW9laCb5Ox iFZZV1VR06hmcoVWFqbUP2nYGfhKtJKq0oo6FQyjMMHc3cu8uY9FAwb+r2BQwHp0Oh3hS96tDPyf BtN7rQcI3zhwAtoUutpQqwwYMNAa/4nuAdNpq3Je3Qx/llPZsvOKfxeNNPfAmvXxNZo/vvVTdI25 d65fDX+Z+196ch2VFT+8fu1JQvk/6JH3HwVtjHt4/c7fzX9MI6m8umPdL1EFX/Ij/qeB4vYtn3X6 1Zf9YhgwYOB/mX9kDbg+/ebhXNPJQf7WXP30J4ah0uLsu3sjStY6ubXkavEPQHVFb27s3HaBbGtS XV1Wr99dajNh9YqRgUZXVs66lKGiODnYEyGRqNGzc0gXN2H846gKCSSWVioEDoODh04cFWzyxaU0 VFOXd/e+88x1gPBPCqaVF0StPyte1zXQlf2nv+pbIbkQOt7hzK3Opn96YQqDJc83rI/w2vDyypj/ yCr63wJVVj+8+aYKcZk82f19rQV1Rc83bCta3evv5b8OlpTmhNfaj/r9Sk3CzOXlP+zqa2f2RwuQ AJAWvuMWYeyGvjafpVpdcDPTpOvfkMuAAQP/x/lHLGCotjCrsk71IZYLgUS1bNPBrwe3UUeAYb3n /E/uxjCtUqXRtG6GgSDDmM/iU6KTCxw69B8U2leoyCspK9NCstiwGI+eoW0pkifPtL5thPVFL0SY wM2yJhHSeAQN6ueE7F0/+4fwvC9LS+N5r7t9vbv1JxtGUFij37IMAF+wioj8NuPGTSh7qWpFdESt /syzJYbov/5r4xghkBoB/uhepPpWzMvyFsI7oTAMfdmkIxi7DZnsVCJXtzgKg9VqlfKrbEsM00Fq dfPIPV8lf1MCWkitgf/ADgdRVbVIVFKq/OiSSZ8hY0VVMAnDkOYVSO95oGXPoqhOB+nQD2svIMPE cdr2aytCXX9b1AXh2qSEGr0r/s8ERRCtGtJ9+qnSouTM+ubBZGhB6x9eXBj0NSNcFIVVas3XhD5C Ef1WehTFPrlXXwCfS/VlYA38uyPJ1h6H1CqV8pvOChgwYOATvrUCRuR5KS8joiOSXz16FHEvLCws OqsOAAlkJgfRyW/vnNW7DV8QOv1sctm7mGbaiviloSZCSwszL78hByLELQbFAolCl05jRo8Kceq/ YO60iZPGjnSyIeCKHMMa1AETVy2cOagXizls/tQJPm42gNCxZ2B3364hQ0eOXbxy35VZ/Ku/RH/B l27WpcUCM/v5m06n1b5/N6qsfLB/jI+bmUAgCAjgdl/zrLU+CCTRWVxTUAMQJOITi/u2C/Sdve9B VVX6j+Omjx2zZGHfNs62Au7MYxX6hDFlQ9mJ1VM9+QIBnz98zubM6rrIAwuChg7ichfnawFtY8WJ lZPtuUHLluzbNWP6mOHfb1s/09nZgc8dFV4obU14WXFy2LkrD2E4MuzK/dt3nrxMqlai+hifaRHT Ore3wV/F5a45/VrZyuMgkc4RcKDoGzvXzQ+0c5+y8nBGpT6r4IaCs+v6uzubW1ia4vIXtva8Hl3i 6TUmJqYCc/OufYc+yRIDOvGtFTO/Un4cSWpYf66JUGDu5huw804C/qqGjAcTB07ceiVZohXt6mvD DQy8FF+rVTS+efb49duX2TnPbt+8eededHmDHAWINI4plBK9ZXkI36xNyJDd2e8qECqNvbLdy91R KBBwuTPvZNTgKr4g6spA+7Yjfzhw99qBob28habtjz3LxJV+bfJJMwubqct3P8tqfFf+NbmpD8Ij G6WvI57cvxMW9uBJikp/WZ0dfXpssKfQXGDqPfhYRLYSxvDq++xO2JOEqOToB7fu3br/5GWpWH8v XBkdGtSpz7ApR5+VNO2URsUFsTtn9ApsP2j1uosp0ReH9hzTq4PV9GPP8N9S7/7szxNYmJsF9h15 J76ktcqGQdK08J1DAvBaKfD2Nuk25xdRo37RpC7r4fwQvACEDr5df7wSW68BxG/DhgaN3/cgVwmX bQrkmgeHhCXXwTLRr5unOPkE7Tpz6ciK4d6OAtPgjcVKCDfUjy4fbioQOHh6eHafvPDH+02B6WSv rmxwdnGwsLC0tp4ent34hRI0YMDAX+ZbK2CdWlSYlZxTJS0sTnubkBwbm1L2vv/FxPVssuMP5++v F9anPXpeLYcBacrUNsGVPS7mlItSLi60uLF4zarH8pZSBQkEGiitKni0d9W8SSt3a+aumzkmiE/D bRhvPoWMAggGYgCdzReYm3HoIJFULpfWKSR1lWkv72QgnexbDSUDAA6950XePeuUFF6ufm/t1aTe Oh5ruelSZmXp2xkdkVdZ5V9eHEbd4YyksON3yvpO3bF6XKBQ6Bja36Qg4SRt+JYnj693/3XWyTfV 2kbRjX3zjsaJdz968/bVXauSx2M3XibYuyY+fbrv0XKhrCi3UtetX5fufXWkXr2GzexfXRYVXmF7 NTx8z4hHY9c/aC1Wp7qu/FVkCoToct6+SYh7k55dIIfQ2qSwefMXkENmPE/NiXtw8MHUziOOJbQq PcZSQ8+PadtvO7tTUH1t3tLlbwryjsxbdKvI51J0fmVJwg7VLF+r3a1HM0bUoNnRm09TU6KHuQmO 7XzQSOD5jQr5SvlxVDKo996LCckpR5cMTji5P0mkNbZr15Ml0clrIJQ38cCV7169Op9VA2vl+Vmp hRWFlRWZ8YmvY5LSKyXqJguOgqBhMvtFETfW2ZGuHY7I0AGa5wdnz13yfNa2sOyC1Ms/AmM7u4bl aKw6Bs1fNVByasHsn1/2mL394Nb5blY8Agjw3QY+fXA+0DYl8f0mALShqiglK0upKUlLSXyT/Com pUBvBqIogWozZPZPr1PjL08k//TsaX6DCi+ApDevMko1ipy0hPi4t6lZ1VL9t5JNvY+cPL88RPS8 vMkXBEDgFUUvogAAIABJREFUWrh1aNdVCqNgJx93/17DWOIssyljgttVRm4OGLt+0f2kkrLMxd2E +1esvp1S3WJGySsz7j7Jdpv8qLQib+f09uK6Simsw+qig9uPqO51LDEn88bmIW+2ztu0PYLs4Neb WqGQ1+sw0+kn7obGvr6WKyYxhSMnL1rS0/LAlHHhMqddJ49vHe3PICkvTTFff9HozKPoa3uXeesi s0Uvyxul0T+P+/5A1rbrsdW1xec3UCb38XlRY7CEDRj49nzrNWCqoNfwGe4mjeJMlxWj+rmafpjX RRHQ0cWt76Kgjg6W5c6bMmrFMjWrKu4Bgo5QFF3/NUelqZECUjKYJYf6sFtestWfozVmsZU6JsIw 4eldmra9K9mJ/5DZpDpZNu2/m9ge0LuhMSI82Dx27w8oJFfZry/dEPQFeWmmjm40pp3L71cobBum 7PTxn8WJbb1MbNZeGhr0xTN3FHncgr4TzIbuubt1tNc79w5mFjzO5D1jB/RzN2cuW0ta9VY0V6hN fSVqO+/KgI74m1w2bZvTf8KTximzFjDpMjY19nDfhTd8Dm7r48Wx9fd1tSMq2dyR4yeO9Gnj7LV4 99IuclwztHiUSOg3eN85l/I7z0dv/mmE87tboNhnL6pthy+YONbVhgPYjHt4N8l//qXiyX72LZ9G UnAY27N3T+YAgIcptnH/kathT0SSWjm77kXY+Rg6UwqxGMzHtarlpi0thqJQg0KluLi818wCEIa4 PYd5qHQEMyuzr5QfwHQyCC68v9FvTR5qCnvZD8aTJLCEdk7GDUwMwChmzu0DegJyAGTxbMbPXwlz HxVhHTbO6fBRrYVojEU/zO3PV1SUpsojk5S64TVP4ySha6ePHuhnQgX7Ltj/04PL196UjXBv42Br 33nQmEXz9oW2+Wi1nyFwc22XY+7zQe+R3HsMXevEuFlQvGLtOFeL94vLiEankpbfPHtq5ow0VKdV uTnIZ2gwYbsV2/ZFHy0ncVZvG+P8e5pkIxs7I7VDd6L4vaQkhon/4AED46q1CVXaznA8hmxcMCzA lnZ7w3qMEFCe8fhUgrKxVKpMqi+JrYK8zZq3ABJe98HGe9fWorVBZuyQNRN72hjRsm8eLaaterzq OwEAOIZOHZcjelQUJdJ1cXRhq6j4+IRq4ebn3xVI1M92kLmWNtZWllNW7pq0apGjcdOOAUXqiQvA 5oxDg9sw8WopsGpTVE2wZctPRCoa6hhFMXcORZMwjU4HkK/FFHcf4QS890YBEPTRbA1uHAwY+Lv8 I5uwIB2gViq1OhiGUFl9PcoSsgCUBqCmBADvVllmtmARS7/kpI82YO/b3q0th6TDdO06BBmb2XNa 2kuEN3utjsmz7TVl3Zx5GmXyueMXKvoMDu7IoxP0B0j00RoQHYIbKXjPgCJQo2DUmoiRQ5GHI8Yv Ks6skZhbc0gt9hf6AO+oDtHgz8MwiiAIbmozTO3Gzl0jkSgRRFsUu2nJ0uwO0Bnnlnc4YQAMM7jT 9qzjXTyxIMz6yKCOLnQKEdEiAn14e72XJAYvQKN3b02kMshaWaMK0lFBnbRBDTOIANF85LYBI7bt 8q+QsKiJh64YW3D6TBLSkCoIM7WgU/XO4DSwDnjnO7617q5ppV0BqXUwqJLJIPxWOo2EqBUKpQ5h AzplbbUWMGFhLa8P6oPDY1h9Q6OSziTIFYhOLeBgZAwUOjq4tGvvSyGgSJvr7cczzFsZgxRcX9J/ LvYyP+cMB7p6/PCDLDWG6b2+f6X8WF2Me/DkfU8yi04JC59ev3omusnXEAbSUFGtRKmBIEDWoAB0 Tf6R8eKFxY0quFYFw2SNQqICeHwOAOtAOztqU/BLBED0bgIBghIAFXKFQgsZU/A8r63FADaNhBc1 pIB4VGMhj6NDECLhXUR0vN7gyev/a/qX7p2/D322FBTXKzSojqqU41WBqhPFHv71NG/SztzzjoX3 fppxDU/wfZ6qNaiGpIB0sE6lUEIY04hDI+rzG0Z0QFPKevVHJLLN3boFmN9NvHb+iLbQLXSGpxOD RCSTuESfrr7u7vgnIG3adh5Jc3S3a7FNkpkmgYMnc7w1FEAlyji3YW+MxYtTthQahqkkjUoeh46o VVqljk5g6P200bHS6ka1FqbrJI3vMhBHB6tgvhHXikUD8Faj975PIHNYQINYooapJBSh84ROfLoR CaNSQdfOzu6enhwqCdN5XPIeZOVrBjSNl3LSk1PzJe38A1xshS0HQzJgwMBX848oYKoRH0pOeCqk 5FMb096k2w1f3odbGJeeJ6Nn10moWXkFqW+1xb16+tj7+ftS8lNK7QMdMFl9bnopx4ns4unM/MzD AYY2VuU/fx2fUVz16EG0JQNKehhF4HTQ93+oLP5hTPybDJmM8/SlY7s27YSYKCUzNTWFlOjT6ftJ 59ZcHTJp2YEzm2f1dTVt3l0gyvIHESkoKk6tldEfP+CKrO3cPDmFT49dSvbpOaSrkzWtvpuVG4mo aznCG6Kqfvg8ntyh67jJA5n1WRsXTNbs/KW3r11GoSg1XZRV28eGIH2aUZmveyUdM8y/u3/6nYvn 6DXWlMaYc7dZPUa42/EczMZrp/V5u/DaHv+08VueT9k524QA5ecWNaYmxSf59PA2Sn6RAiOU53kN g1xNWu7umNZBLpYvwu9yc8klGbk0G/8Avx6+r66GXwmDu7gSGjIubonquOmyXUsaFFFVPE+o0Gjv 7j7MD3RgpLyKrOG4TR7W/YksIbe+tlGh5TF05RkZWSUMn77dmvvHBvSWHk8ISIqzUqrqspLjYuWa trnZxVLx18qPohR3K5ZUlPdKnhgdGxOjFNunp3mZtrfyto4/F3WbS7bQpF5IAOgBcZUqT3MKgy+Q RMZdv3FLpSsvKtJYz5vTO+d5CpxHeZ5e05Vbl5eaUYIZFyg8R3u22xIdcVFA97XhlMWHXZF22NGW Jy7PjopJTU4ugx/drTSx6tC5nRmfSUAViQ8el2tkCRkFpbVP71EcbXG942ZDYgkcLSLuPHKR2rKy ErMQh6BRfvgohK2ozn/5KD/1xtuGHFJ0aomfI49OJNCZJlUP79w2LZKW5tWT7PqGBjOrswtqG3JS iqWNMffDpWSqebdgPzaR3Sm4R+TzVUt2la85PMbOlIUr5o4TFrstysmplLXlU6sq83NrCFRTBydr bvOsVtXmhd84nc4eMCXIhantZOdaQyUA9t1mernO+mmvVWhXR0VpyrNUmUe/UeZGDMzPNvpCuCcX Nm58cyVRJ8hMKKszlWU+ic9MqQYqBXfJNs6+fh7WTIblhCn+Ww5tF4iDjdRVz54+o3oELZ0/zi+w 7YOUuvJGFVvAFJelFxWLUcfOnuaATlJy4dc9247GLDt6Ye2UAcYUgwY2YOBvQdy4ceM3T5TBt+AX pb9OiE8vrOC06TOgq5uqNDE2TeJuZmQtYGRnFOsapPZtfN2cvYYHtcu8feNpUmJmbjWJ69Z7YBdr k8/9m+O2TWVe3I1naWwTsqgwJysnX8LhBvTu62EjpGB1t3YdTpFh9naa6nol37GtcWNSTEIOUYGQ uc7+Hm7+A/zlsZH5bPcgD2Hz5W64PmfPkYu5+eWYwB6qKcquVNDNnDzMGPJqUW7q27eJifli8pyN 6wIduS32NHBd5tEbqW37BvfztaGSyWWVUhVCNhMaFxRXYbW1fCdvK0329XjIiy516TGks78PHSp+ 9iwqLbuYEzBgzYyhLgIW2YhvVVDqPnl6L1c+G6MPHhRiwVRnvk6TaivEJPNuHbivrr3muCNitluL 8jdBM/O1irr/IDOnAOSYdQnq1c7H19dDkJX88tWruKwisfeCLVtGd2gxuAlcl3UxpsLD3Z1HqXyb VMyw9Jw7a5afs7VfO3egJOtxVFRSWrZIbBo6bVBba5MWR2ocSxdOVcyTtBSRBPbt2Z0PKoh0rrax QQN/lfwElml7czgi4mV6aR3Dxb+TgNyoBh1dPW2tnMHi7KTEpPxKuZmPjw1dbdehpzWXLTDhKcoL Xsa9FYmNAnp18XYmPb8cy3FDxGQnb4Eq7XUybMcV2LgHD+zqalz1Mio67k1qeSNx5fajIW7MoszY m3F5oAm7trQgJ0fr7O1hbsok6Orv7T76vKBUA5jQlZW5ORU0Y0tXNxs6i+cpYLyOiU1My5XCbkNG dnW2EeoQVfyL6JxClUvXzrYWQIWW18vfmU4icPnmYOzjqMzcBpjh07mHjzMn6969h1EvyyCBFbEx Nzuvogr069mBTQRoHC4NoFKdg4YPDLJvikPAcejoayu/c+tB0tu0EgVo7989yMeJ3ZJXZwx/fV1N QVZ6RnJSVrmqz/hJff1c6Ryb0C7uBQ/vP09OyRcTAkZMnzS8owmVwOY7Armp8UnJhdUqs7aeNmyd wNYq7/mVrAbc7lWXFOQ1su29nSyZVKZ7zwEmdQ8jnqXnFNVbefSZOmG4A59j6+PvhGY/iYh+nZBS Wi1tF/xdD1/cXgdBfMCrgmgs3wH9e7vacA0WsAEDf5N/zhMWqoNQgEgi/bErdUSjgUgUamuxyf7T YAiCgQQAgyEIJNPI37Cb0c9ywjqUSCaTiB88oaNalY7MIOtPDcFkKvWvvQxPGAZAMvEjWfXnqHQg UZ+tf/w4XgawDiR9XAIoXigAUf/9f/Q0qlZD+I2UvzqZAmvVCNjseRSB9KEgPk8UQ/WRs4hEwh+u QeogDYygZCrjL/ui0q9PAB/5skLxXNZheJVuFole70rr8wJoJU0Y0unT/CQYBAprITwL8KL6wkdh WNPhIxDVwRjYJAP42y/6w1EgkUT9OKBsU8wAyldEaNBPTms1KKhvgh+/Xp+BGEilfhIiBS8ABAMI IMGwBGzAwN/H4IrSgAEDBgwY+Bf4/8PoNGDAgAEDBv7HMChgAwYMGDBg4F/AoIANGDBgwICBfwGD AjZgwIABAwb+BQwK2IABAwYMGPgXMChgAwYMGDBg4F/AoIANGDBgwICBfwGDAjZgwIABAwb+BQwK 2IABAwYMGPgXMChgAwYMGDBg4F/AoIANGDBgwICBfwGDAjZgwIABAwb+BQwK2IABAwYMGPgXMChg AwYMGDBg4F/gf0wBo4hOp0MMARgN/DUwRAtpYQT56ynoYwojqKEGGjBgAACIGzdu/Ldl+E+ByiJe bxx54xSZ5+/DN/5CQHFUp5RDGIlANIQd//8fGJIoYDKN9J8YStaVPZgbtiQTEHYwd6L8UdWoKbyz 98mNl7mRRSpzbwu+/hJSd+vFisF3IyzMvT2M2X+ubmGaouLoS0/P3E9PwVjmZhxjctPzdcUP9j66 Ep2fUKUxdjM3/Su5gOmk9elXo369Fh9RLAdMuZYcKukvJPNfCoZhSpUcIFGJhrZu4D/Ot21paEVB +I6nu6OUDluGb+hna1sav2VY5FUeu+++STt92cSm2g4AYHO1pr/ewuX3P+oK8y4uu/VzPYnd9LdR O8chC3qOdDTmEFp9vKUEMUxLIGMgQERh9CPbv0km/c34P5oe0UY/nTkz1eT05PUBQv5nMn1B0C9+ w+934a/68KIvPfrh0if3fhAV0P/26b3A5/nasjgtXv39XcAfyf9bZrXy40e/fF1+fHKnPnO+5hM+ uqg4dMBiH/1I9pxJjK94U2uJfmWxEkCMToHJxK+aQ2moiDpRdr5GpTavtRvewZXdlJaGQCECWgKq +/RTW2gX2Idr7y9i2mJZwrGCPTmwNdvDvwNmR2/6oazsxp6SayrEvA/RfbCPx19oz3JZxo5T7fdC DAaZ5AJqrex8rNnUVjLg/d8t5V+zytoyrfUAf1Bd1NKiA09/+KUg14H4rpzlyTqfiJlr35wbfEr1 7hYKAJDFgHCi/0BadeTryhIIJONXySS7EYELp7b3pbaStrIuPPTMkvaB938KcP5aWVv+qi/0YNqS socbr64r5/ZaEbyyj51ReMTGPekndPz94VMms39PoIUu62vbkIH/Tr7xUBeGq0Sa1ExF9PWCAf6m lMsv92RCMneyEEHheklpuaxaqoUpdKEj355Po2oVVSKVjERgoLrKChXIN7ax5wjoxOaDeEyBKePR rEaIbs62IECZyRkP6JYWq7xDTMioRFpZIK/QICQe28raSMAik3SQokpaWC6XkZmWPBDTASjPyI5H BRVarYvVyHMjGVamNsT3KesaGsrz5SItRmaSqVSisZPQlgCrtSiM279qrUKmJJEobCZZP3SAYUW1 RFShbARILEuOrRnTiEyAquvKZCjGppsRdbXF0ko63caJZ8P4zBrDMIWyqlKlQBFIhkAMEkmtkTOY Dk4mQioBaS4/hmjqZaXFslo1gcYmwgqdQxcbMwCBpIqKYkmFCiPTiAiNbu/ENaMRAbWiukRaJlap QRLLgudsw+aQQVSprCtqLGmAUAHTmACSSEQjaxNTUNdcfhCD5WUNuaVKJYnCIANkDsPe2YTTYntH EW29rFwkq5FBOirD3Jlvx6VSMKixuKEWI9K5DLZcVlah0VnynK3ZTK2qrlQmalBraQxTB2M7Exq5 tQqjVdUWNebXagAGjUoh0M24rkLa+xwoV9QpUBKbYedmIiAD2jqJSIqCBFQpUSuoNGsHvjmTCCjV Sh0RwPB/qKQ6kEijMCgt1B9ceFgir6yHdWS8xFX1GoKRvYm9gMEggiACSysaCis1KozIseDYWrCM iIiyRlYrgzEuiwdqqnMaq1lGbm1MTRFto4LiOLvnzzxjK/pveYRqaxpLy1USjEAxogvxEmSQiKhO 3aCoJ7ktfO0cOub4kDI6RV/fMFii1nk7Tr7qbGzLN/9NSpWyuripsJh0Dgkg8ti25nSgVoo3llqp FmGwLTx4TsZUIkDgBHmveMiwXhZ5jQj8XsN8u/2a4xg66uwaAvH9Ra26oVophRGIybRgo5IKjZZC IHJYVi2WAgLJSxsyn2qFPVz3Hg/pw6MbMSkktbKmWiVFiCYWTFJVXWaFlmhj6mXDJCuU1WWyapkO YVOF1rihTNKJ6sq1BJJOWytDGEwyIIUwK76TJZPV3JrEUFihqi1tLK/TqAlUEwcTBwsmG0TkZfWV EIFOBjRViho209qea93U3Jo9jkFUpFQO5eYzzYxIRAxR6DTFGm1NtCSzguHAJcrLlCoTGh9DUQhu KMWqYjXxLIaDGYPc0BCz/sULW+vs/sIWRmh4SVVXpadgmJ9OKVXJiEQKnULDhUdhJV4ExUoJBpAE bHsrDp/WioGs0zaWNRZXKKQwSDPn2tsZCegtTMZgGkxdgJW9qnzoXdHbm83bVfYwWqW11cIYgMll ojJZRZ1aQ6RwbXiOFkyaQl5Vr1GBBKpEJZIjNCtjBxtjE7JBDf9f5NsqYIKdQ5+2Dg8j3t56XpRT YIXdgvSrZaFtD3oQqs6Fr/i1PF1HAaogq5ndNi/x7ljx9sj42GscugdJE5+Dko05wTtCVoTYOdM+ q8Ag2VEYtMzM+QzqtD5wE120a0PSRa0ORTGktuLRkWcHTzVUGhEAJqXNjK6Lhzm45hbe3BS1J1Or gkFHW1QqAXQLQx9+70xNzji/+dkVOctvSd+lw5wd8S9HVPm7wr7fI672MmHUSxVtXeYe6jupNP/+ zbLsBm351cTjcRSqucP0qR7mOqghKePMwcRbCepGFCa2t/9uUZepfnzNmeuTTkslfi6TTFUvz5RG ediM2d77p25m7I/FR1Htm8S98+OeUEiMYriGB5DIWCWZv/DssMVWmtdHP5V/hGsHrO7V/ocLrzRo jZj0uoYsqfHxirmTtJLsXyPWn6nIojJoDbJSN+edJ/pOtWURkl5uXZhyX8syUmkxe7t5+3tPdgRL 7r0+sCrlIQpCFJgCkDgC7thz46bU5TSTX2hWW3Bq9q2laYy2fKJUpOCMCji0r0dnSgsli8mlhecf rT5XlYuQkArIcVnv7XPbtMMqHs+/sE1EN+vt3qkk/9oTOTy2044V3o4v448cKkrUABqJnDq+6w8L Ogw0o7ekgzHlsxfrFyTcZZiaw+pqMrPTiqCj4x1YJeVPDzzdHKVS6TCNCOl+aMCaID70661ZlxrV fFAjgUoQVuiOwdv68rQXXl96ptLJdPcPPhcZ0a0CPYZ0FHKav0ejqrn/bPXuwgI+mSqBCwsg0xG+ C9cEjnRiILEpR/a8OJhPNYERhpv1pLWBozyA3MPhe29UVnX37k8ueXipMZHHW35v8lpt0f19j39N 1YL9Oy1bEDDQFFeKmLa04MbWZzuvSRuYANmM02Vlz6UhtvZ5ZQ8vv74SXwcI2eqXAGDTZNygUP3T +MNHEx7JjII2hs4NsbXG9YxKWnA2Ztuet/cQuoCm1SlA2/l9931vKdlxb+ljuYxGwYrr4FX9w5f5 uRDftQQCgfRZRwyC+NCR9tGFsvz7a2PO5krL+3Q5NEB+flpWhg3NZlqfI+PczJvnTEPxvU2RRxNR iVXprxvCiwb7jh3oap2bdmp13JUqWtAsT86dmMOxGNDP9+ouX8bF6E03CmPFIIVE9JkYsHiGM2vT yYnJVAEFKihHYT7drlgNTOy8aW2XUDPK50oIVlU/eb1re+oDNZUuUUBBnpv39B7OVSQsPzkrk+ro YEROrI+15AWvD9ozwMGquQZjcOx7e4x4XoY5tlvoy9bR0bojGQl0EoD3L6HtTo4zejAuNm5Ku8WQ 5BmR6Tyf1pBX9bar78FVnmanr3rv0wBaBG2h+gFAfemjQ2/uaKCGuNzTB5RmVoIOfdv0EhCUcbk3 jkeufaahklCJsdGkFcEzBzu501ua368suDb93oYKhimIQAJO/3XBq4NtBJ/fCNIc+J1GuvV4lXIv VxwfD1CVqloAcPtp0HAjAL77fMPGnBcQnSbVMru2Xb6lc2DSi7X7s2IRmk0pVEaEG4WCOdtDF/Q0 N/0fWhj4n+Fbr5yRGE4khgfNilT//GjsCQ3TwxEA6jQ6BIVAjOtn/t0YqxA3Ut7TgrgqhdrU0t+c KHojL7Vrv3OD7xiGMvxw0plMcWVGacKLnJiY3Kb/siOz6xUkEs2YZVErK7iVdupScYac5uNqbEFD qw/emrCxJHGMy6IlrsN58mu7X+95mPH417eHc4huCwJ2b3cTVEPpZURzJx4LJNCshT6BNlZKdXkd pHs3hagRJ+ysekWldvzebdYosyAHtj0F1ZRpK0oQOQxISrX5Wdq8Io0GwDW9OHbn49VvIcZMj8XT zIUJOT/sSn4hhdmd2nSBtLk3cy41stuv8FvU1caP+XkHifeQRA7XloTVM4zah5jbQsY+fe2CIUlC riT7l5ufy/+yRiIqf/y0Po/KCf7ebeZInpe/uZCE6aolSQ/yX9K5wWOcZwwXBLVjvxuSw3K12slk 4Bj7CcFGpILqB29EZW/TTv+SctfcZsKObjv8zYwL1W8FFu6aupbkhzSpb39+glA8heNnOY0ZwHdy 4LBbqRAYXoIkQBBgMXqMVbADMTU8NxE3cClGLkNcPXLUMY8qsizdJi32CW3Pp8Qk7d/y9rItv+/y tkuGM/N+ip5yJLuq5VSR8vPxx0RE11CXudNthndkOQhoRE3D20Mx24/VGvd1XLTcY6q5/NSSBxuz tDRzoUWDtoxr3XeGx3Ci5v6r6lylqiFVUyzGzRisKleTk6spx23cFt9DprDMhM5aOL+C6TS607bp 9pZ33264UphdX3prevjGV4QBC9ssG23ulJCx63DyvXqiMMDWQ07KuZsf0eA4aW2HcQOdHakggcdr 29WhDZGUUQxVQk3bqGB56uLL466pzZcG7NjiP8EMfbnx5aF7Kfd/iN5yS17fz6unEQcwxu97JxSR 4WrdKcCcV6esboTfbeOC4qPmLnh72dNjzU89Nk7z8DPHDWgiqNUoGkle3cxHT3UcaQ4UHn4bp/yK loc1/YdjzHdx5lNKsFKYwhYwdSXaLIZFV1eTlmfoMQJI4FLNQBCgEREjENFbn0SBmbclU5Mj3nci L7VHpw1zPYe70hUPk3/ZU5rr6750T5dNfXjyvVHLbtVALiZApqY+sN0cXwKDweocYskpV2TUa1oo BZ1OK9OxbXlDxtmP9mYSw7LiKrUakGnpbAwXaOKInMDVXhMxcX5UeZaqxfl9kEQh0uhY8ZP0g6tf LH2iYK7pssKVZdGxzZh+Do48OpNGplpw7brYebfjC3lscwqJnlgSdij2+GMl2ZLfx57Z0qhSPwFT XkrUYADcgJbkqrPLoQoNgkoro5c93xxN8ljbZd/PnVex1TdWP974VqJtMQWFUgaxQ76zGTfArF1e VWqkqKTFKoj3YHSmKZvELqp4cyztBoPMY5CsOAwqXok0EKENf+gY2xGdGPK35c8y6zT2AoGMVJeN YqsCtm/yHa2sPvBD1O0KZX1m8avnub91jDGFUkWLIhn4L+JbD6pAAAUBJ9Pe3eHYi5U133f5SRSd gJuqUnlxMqJqhFQCioaGt3lMv4xp7hA0iU2KQ0I29RrHFqfWl92/ra4pq0yNybqeIa5nNs0laqCC zl1uLm9DAQkASIAlqqy8hkKUN9ff1IEB50Qq8YGtF5OgVSFMF9PeZKq9QirWqqS+NqFDvQbboGYX Mu43MMYFmBnhysre9v+x9x3QcVXH36/s295XW1RXvTfbki13uVcwpsZAaIHQIVQnQAIhEHpM72Bs Y9MMuMtdsmT13ntZbe+9vfq9lQ24SMA/cb5A4t/R0Tl6emXu3Jk7d+6dO1N6lbO1zVoJAdApI4nw EhYK83zQ8MHukAcKZOJmPSa5vvgPsc6uOzqlG0ufmBMlZYAgSWFuv74tLBQJVCSBMdlZxXIUATgU KC6dd/PM8jdrxNc/t/oRFYMiKRKGzl1AAyEkOaZkNV+siZ6fy/ISWM4VKn697TgQ1p9PP4FTUsm0 TPG8Tv/Q4R69kxIlQE1mdBnt3hUpUyoCw8cHdTCJK0PhIIHj3tEKwmcnmP6wm4IgfoT7QY3HYA1K 7sl4aEElAAAgAElEQVRff2lGwQy0+TNtyxU5JXDoq0nop+CE+Euz9NUea/lBBxVksqaTGi+eKzlv DkERYbtvrI0IBsmAjBHmgCBjYgeTK5v2u9krHh2rumXWC/cXJMEUQAVHXxnfYiESeBDiDePyqOUL WF4UxSaXFlgyM6a42x+s6i+TE05AMtsd9Dn8I8M+SwBWAYQ/SHKTE5YnEGgYEk1LKSkcdizNueNm 6UCZpY72aRjSkrfXZGwa+noT96a3L72RTzMfZpyzjXwKCEuYnzRnQd1OMmHdnfMvMzaaKwy1o06n zl4zAIJSBp8gAgx2Qq7KLGNgAEe9In+RrHtrcc5f3ly8jAXcihMQg+5V1fTLpl9RYamiaFmc+EjY 1vktAKijbn544TUM31AIHbir1dQ43BIIOOel/+WuhZcLArmdAydtUESUIYYwL30l4ayrcOih03vt wf7hw0yG6Ja5d61TMb0p0wtHB8VynsmuYxMBiPA5MJgNA34m63uRoidzIAiB5y4RQROBAaelWh5T 8uDMm+uMbaPW9ibMxWYteqj07qIoNjAZFGkb3pCIrhu6naV+5IM1K07dFJO07Moo1W4z8eDiN65N igUo3OPo+7BsMClqwZUz7l4eJ84CtEfNr3Z7OPemzf6bG95QtPrb4a8Go+fnsLztGARPsmlJeMIW u9fCo5g+LAiAJIQgtGZBnIzLUma+01m3oeSu2fjhuu59AdwdpgD+5MutEACzxFFx2aAyg8ft9o2m gaseueRDBkw2dVIASYIM2brsm+jbjF2NkbuZvkHdsVqMdYnyljzR5AY4Lu++l4DA0bLNa3Kfe3ZW OkUCCAxpXSMo6p2X99ANJSs4MBTQ7P6DvXvE5Z8jZZ37POXqtY0qQCKE+wIkgdAPw+cpz6kbKZIk gUzZrGjAV2XjPzxrva6rzOxDCWi0hu5onOPHKFpMuPTACPILkldK2vbBgjtunrWegafXNW1uCg9o LP1lFZtqvIR04gPmMHLbpS+liPiTtusifi24sAaY8rj0A05Dl1+xIPf6RzPFeRz/QwDAN9Q0sDXb xtvXZSyfHR0etDfVOfsHPY5MqZR+JoSXv1CxrRAf2O/yKRKT1Mp0JrJueijMmbBkIUIbFy3xB7o7 zf1cZtbK9N/PYZJbtAc+bspCCvPzYbAaMFKIPFEYjaKmMAorpHFsk7xWs+OtWhsRbO7GUXryTQCk 16vrHO7o0PSZg8be0eMHMev09GlSKjJbnZtwS77Yu7vngwOjh4qSLyuSSGEABrGqysHj6DhaZmta mPPEDLY8BQpZwKCAp5LzWAafHmaxwJD2eGd5G0Ci2Fh9z1GVOHWaOvH8/SuKwm223v6Az+vs0bCc VsKgYclRYrTPHsyDgLqz6RcgEH0fiiuXJM4vlPo+qXny6762a+dvzCJJnKEsVC6fxzN92LflYM+J W2evkIeaX+z+MjX6HxtT0hr7+g449H1O8wphsopfvbPlBdKQ0zZ6jCaAoCjuZPTDIGH3mphwwYac RUSg4sO2j46Mxy/LXD2JAcb9w4aKLwz912StLJG5Oyz1HfbuIa9HEug53tNIkZjD0V3VbU6IyU8R 8OOYPDHowCF2rDRODM+P8R1Qcs4buU6BJGnLzBKtvi1F2abZ/KrmcHTMssVZsSyOBPBgXK4sQcBe FUgtc0YpmViPrncM91pcw9243ouGe3RD5gKUz2PBFBbw7T7QEU36+rQM+drMKwqkvEk/BgCmet2+ j6tdpvGTelR1rUyhYORPOIGEhB+jYoI2t1fKjmWExmsGG92hQDgwfqJ5vzhm7sxoMRr2DI23tI2W j/ssqKHrcNuh4rTZqaKk2QAw4P7m67a4WLy7brwtUTwrXZlEW6Z2/YnKYRVg3GaiUDK0b9i1NhYw d471tGuHnSFz5/AxgS9nZlZ2gioXGx35tn1PlFftdLbV2UILBLKhwb27dPa7F165gGNtAACDr77D uLRAQAxoO3rHO/X+Ua7m+KGwpyBtbjIfbeyoHHA395M+paX2UAc3KyYzJUomi196Q+y0B7peasGG VxWdmDOF9aXhs3Ud7KwcIgNRtspDHbzs2JwUGVenadxjt/spQGesLXNKszIWqBAOTxijG+k+PnCQ 7xHv1zbZcGGSAGscaCJIXrd2OAj47K4+HdujCejHPY5UgfKskYVCddbGnb1HVBn3zI5PClgO1Pm6 WnS6jBT+SU0bhqNdulYh1D+M2qX2PhPdC5JzQ8Rx1DdqHxtGZdOEixaLhWFX2xNdvblpS2J5/orW E83aPtrA1wwdniEozVHJes1d7rA3R3jpnwuW2L+5q334tS0drHWZhbLzFsZpiGVJStzXpa843NY4 4GhRxK8rZikYCKdZs+vwgDwOH9nm0LLg9Bg+ZxL2YfrPGj+s4l57TdICv8F+QtOns/Vafdkx/LMZ TmF2R3enppHJKrwkecFSUBhP9MPE0NGOxsXpg28OHi5OeGZBYhTq76y2a/sdutlMnJ7Kmq2ffNDA jPLvrKaYAm5anCSudNqGdBwQTjTCjCHFCulU3XoRvxZc2GNIhE5zYGv7tmrX+MysB35XuHqs9oHX HMYw5pgRP9um3Tcc1Gk8lmAI1Xg74mMWlKii+1s2fesdB71ohb6aI1l556wbZyek5ygz82NysqOz 6Z/82JJEAVOrO/hK42dDKCdOWXptZp7WWL577GSKev3l6iSvtf2YvafX2dhsGeaKZq3KX5UjVeFO rdbmwTF/o3sQ4V/y8Iw8m+nEG4f+/Lm5YyysH3F31ehchalzlMGWOxve9xBBB6bTez3SqBXX5yyM 4zGJkKNmfP9xQ9NJzZEBp6A098rpUXIx5R2wdtY7OlutdX1ucFramuks7Z2Hn2sNmVF0rN04YMNU C1NzOeeHnxDhlvY3/zFWj+MBIBTod9r5AGvA29yGTf/rzPlhe+eZ9C/LKPaOffbJwN4BzGHBDBrn UKLyrpumL/bbT75V/2EP4XKi+iFPoCB+zXXZJTIk1Nq+eRh1jbu7jT6GLziIcWRrc6/K5PMM5kGr hwABX7t3/LJpj5XIJ6F/dmxU/fG733ObfZRNFxhzh5H56bcuScrmQZN4MH7vYMPg/pHA+JjHgYaD w+72lPgVsdbddzZsN4Wdo7b2HqdJJp1ToJBHsfmkd6TG2tlJWxRDlQlLXTv9iizRZDYY0z5X9ngN 5g2RplGvhcHOvi5/XXFcsoTB9Bor2pyd7famKkOVQn75CrXgYNWTezx6LkXaLV015pYhF3dl3go1 jxt0Duwf31djbG/UtzM4BbPV0ybbb6Z83uHjXR92+n2j5s4WD7o8954b8+erFcki1G3WHWrxDjZZ ajVBsjhlRSrR+3rTR3UujdbZ16ArD3JXLU+I8nvGvjz5t1cHDg4GLEavvsNYJ1MumhmXnc1CBsfK dmlrT+qqTaji1pm3r88ukeCuspGyekP1EU3XMO6EKUdOzNXSYM2mo09/a+3Shmkj3H5SG5qdtbAg Lge1a7cO7G43Vh0crdNhyiUps6W48ZixedTf26B3Sphwp6+HzSkt5I7tOPHHd8caBgNjI86+em1N bPzqPIH31Z13bNbWD6MWb2CoxeoWiXKKVEoI4sSziIMD3/ZSq96//N6kSTfgJ2Dq23z7yQ+GMDv9 eKvVKRJPm6FkHj354rsj1VbSPGTpaTDUZyRvyBILeEyR2VhfOVpWoa04bMNX5dx1W4bi/YqXu0kX jKdBaFu3z87AQj1Wa1rMzOmK2LODhsBQwNahbaj39vfa9GGU1IW6LeT0NUrP3ypeG6bgYEAChLv2 WVpMhLwofl62VHyOqQz79Ac6Pv7c2Kb19Hc5W+rNTZqA7LpZVyXgXY/temSXpcsStuidXSQiy5bI DnRurrCNjrhk1y27azZl+Wrwy5EgVpK8MoYzib8BM1ja/n27DJUt+vIOizkzbtXMxOlyCu8c/PaI oa5idG8Dmnt/yf2XpGZyJtELYHzkxCH3kNE7MugIhEiDJowUxZUkic7y4Ski0KnZ/3TTdiMWNTvz hhsKMusa3z5k6R1yiq4unt3XuXU4bB33DNsDgN3fxxEnz5YIdg0d6rbVUx7HvrHO2ISb75n729mq uDRV9rSY7FMDY3FchoI9xbz2In49AE/Hv18YUAG/dsgx4iCABGlBAl/kMNX0oDgCMxNFKXZ7pz6M cTkKGYPpI9xycYYSCm7dkrcxcOOeK28AQFzFS0yUKjmTRBtSfr+uy0rPsjlKYWKKkKu3D+uCLnXU tHgOYrAMdnn0GElxWLIEcapaHAWF7cPGMTcFks7G3x9+QJxZVn75gnDQPGTuc/zwTmlOdIaEsBzU 9dJaGcYIEOTEybLSJAo2BOJh16CtWxvwACBTyU1NUSbwYSoYtI1Yh8cDDhJkiDnxafJkKeits/Th 5Kn9PJaEq86Sx5x/PJSiCLu9p8tnZ0McNsjwk4CUyffgjiAcO0chs1qHzqZfGnT1djkNPorAMBxi cBLFBelyacCna9f3BGAQx3EYEaolGaliOQIER/UNfT4fzBLJ2XKQcILsqFRJCubRDttMAAL3N226 rmfH5ptcN6kF59MfxUHM48fbUAiiaAYAfLYiTZYZLeBPtg1MhoKWPmOnESN4HKUMhj24WyXNlxPm Jpfh1B1MRKwWZ8by2LS7Y3eO9zk1TjRI06/ipWco43mTRLZGTmbX9ld7WTCO0VN+hlyUnCFJFLEY BOrV2nuGPbYgCTJZ3FRJYSwf1JpadQQgYknYFOlA3RggzYvJkjKRkE/XYe1xYCQXESdI0mOEUtZ5 DSDJ4Ojwrj/v+iuWfM8d06ezYUGKLEUeiYIGwgHTgKVLGwwBEFPKi0mRpggAV79zzImd3vNTioqy JHwc843besbDge/fqZZNU/NFIO4ZNPWOBqwEwJLx1RkytZjNDPpMPfZ+UyDI5spgKgBDrERpgQR0 DFqH3D8QJc+PTZcisMM+1OYaCqAUkymOFiWnihVUyNxl6bHiBJsZrWZBBtQj42cn81CaAOMZG4wp iuI4NtA73mj5/hIkUYuTEwWsQChgHPhs9aHHFMlfHr9y2eTLrxMIuofqnbrvHhepxWmJQqbR0qsJ OE+1H4YY6crZShZM4CGzc2jEpXPjBIsVk6lIj2HhnfpWFwiJkFgOYHMRIAdCvBgZK0uN54vO0WMM 9Yxb+wb9dhCWxrB59AgAI8kFEkaHqdsPwByGUswIGUMOAI5Kl6VEc8+dxxJ4QOfoHw2cwT9AVhiX LaLcrfoOz/eX+OokQZTROWgKeQggqjA+i49aWsz9IFOULi8QIZOINkVhBnNnr9dMgLCYExEAKYeD Be2j9r4xrxMHYKkwIztKLWZNLsE2a2+bcxQFBRKWjAMFAwAvTZYSxWGdfaYQd9L6ax8DQGGilGYO S2fu0oW8GEB3oVpvaBj2B5hsaRRThBMuDi+W76i55tBjXs5vXl+4CkT48fxEtfRiFPR/Jy6sAf4x UBOI7GCdkiRcc+eOG/aPVxsoVXF87mMrvrkk+mee5DwXJElMnNeDTr3a0PfCn2q3NgdBEvOOu3Uv XGO4O0M5FVEEGTncSVKRPT0IOlM/6YuRt0Jnn4CkJu6l77yA6nAO/ZH9ou++9v3FU9wDTh+1hM6k in4cOPMKYX7j+NNbBk6EQdrtM46F1nc98n4OF56Ufup008mJ84bQjyceOd2DP6/tkU2v80g9/y6S PN0o4FyuRjbNIqSCPycbSmSDDQTBKY5MEmOmQ7d9cWeTxwaxo68u/tMfim7I4J/pFNJiQJ5HwP8B Ez149uNU5NLPfCE9RSPP5v8E937u4+cgbK996MRLR8fqRnwWLidl1+96SqWTGo9/Bqe6daJT/u+k UdRpOfvlnWydUATg7N310xIIQz8RqUp3NTnRd/90q85UYdTVcP+hP24drAYZqkSRePst7QUXHd3/ Xvz/M8DnwVPbdGjIj0fCW2DurPw1ybwLsyGN+sfrh5qGHU4ckRamzMxXxjAvpLn85YM0mzprR9vt QZQjzpiTUZzAO/dg1/8YKJ9/7GTrSSvJoIe46OiC6QmZksm2A/87QAR1J3vqNV4vPf3BAMklcy9V Xjy/8usBETKe7Gsw+PwAiGNA9Jo5y2T/U6PX/xj+gwb4Ii7iIi7iIi7ifxf/Pj/gV2PYSSJs9dhD ZyXIP3daQpF4GA2Fcey/MY3+/6GnKIrE8HAIo1mB//jUjcQ8Rrf95/Dr/9cUkCIIlKY8hKE/WgyB vg0LYyGU+Pk1O341ov7rAkUSKBYKohPC9p8m5jQowhtwucOhf7qgyy+lIRfxy8C/oRgDhXv95iFb 37DLaA9axp1uqTDqlxxBYB58fcbXDyTH3ZQtPLUvSHmcA102L58jYJ3Ka0iGDeMHn97zWrPdGavM lU0ejvErBWnU1/b6ONEC3s/pIp+989MT721u+OqknsiJUQtZU8b3jDb/dfZXrxTnXZXI/pEYIPr7 /k5Nkx+WS/7NBQCwoPVE08evndh2eEgnFMbHi6aohUD5qhq2vnvi49aAolAVzZosseXZIPX6+sEA V8Xn/oJl/NcHivA39u/64Mgb21oPdVlcKQkFoslP2P5/Be5qefTgbfsd3CIVPVr8H70XCre5NaMu N5PJZ/+0XP0rwJ0urd5rc/itVl9YwBP+Ajh3EZPjwstBwN3+VfmjK7asX7991Yz3p8/6eOPAdzlk qEi4AkFO6jBE/vdTddoiESBTPB6JmMC/C0j+vwFmKWcoC8U/mAm0teFv1332WrfLRZ3+LOEKaPda vygzH3WiGEH+LLeOiEQx/5yZO4UTGDHRtJ8qUxdp40S40DmXacadPyOnCcDPScBH0ndGGEhG8nie fiD45RfLrtp98Pw0PzQ9+HnfIjCfGes5Zvnm9a4To8Hgj5DL4auKYpIF5w00dDfT+L4PKXf1zdtX vtg+dv4bJiXgNBk/KSoT96AY9j1fSCJoCvZUuvZvHqno8ronf2+EINzi79ht2LHXoA2en78wEi51 jgQGtn1xyS1lR9Efp+aHF0RU4Bynn5pgyvkNIgkM/5myRlKnX3Lm4xGNIM++kxYg+pUR2fi+FRQQ uUhEQo7OIoIW4DMZeOpegozceT4JE9fPupV+26m6jbR4/2QbTsV2nXkb6Wm4+uB979o6dYzBwXCl B/0x1Z7g6iRqOQkDT7P65+glcapwKYH/wASKwU2UZicKZOca37NZOjkwy6HWF+888FaDxXPe/yZh 4D8P0rnn8AMbPrniqk/WrPnoD3WO0IV57UX8G3DB3Q5isO+TbX2fsqS3P5yeVT340U4jBk2kYnc4 e5p0jWMoAbOSZsfPTBeLEcDb3l81jlOxsgJWuL/G0q8QZSaxxU6fyUsyU2MyCPuQDkNxQD4/q5AZ traNN3R49AAky1LOmKFScxmgcfxko9sl5OelC3yNYyftcNzsxNLMc07xU6TH2V+rGwSYogR5QaaU ozO0D7vsXpKbm1jM97Qf8Ah/n36VijEh/bT77rPZQ34c4lucBi3gZ/GilTxuctyau2N3vOMZLevZ 0spBslQLilQpXMakrjDlc2vaDI29bkuYBLiieZdnFoin8JmJoLFhqKw1EIQYbAYoTJDOWRLHHzb2 DLq8KXFFMaRhn3FUyclbmJIIYH6NsanW3EM7i9EsCUwGVfKiPIUyaO8u157UY0wJP1lGBdjc6NyY XC5mbdPV9HqtKMQpUC2bEReLkJjd3lWnaxzHKCYDwqiM1ekzEniQzalz02QAXr11nAMxhYIoAZNB Yu4hfU2DXeMhYS5/5qUp+VImGFmodwz3OUPz0q4zui1b7YzJEh6dYkB4TNs8gCddl5kqBSZaTs9g nIPN+lGQJQyiJm3AnqlaUBKTzsA9I8N1HQCZ7zeN23gIwpcKxCwIpAno155odhpOEXBZar4IQg3W nnazUSyKl0KBDkuXA4hfnZIyoOsjICaTFafm4yNWHYGIkhXZSTyyT1fbZNe4MYLFVS9PWZEsZLH4 6msXPCtCuA/WG38suhiSrMm9fMvYyWHfWOPQMRJiqaU5OdFKBkD6vPpWfXOPxwTB8sLYkny6H8Cw 2a5108JNenQ0A2E2nwnqrP06nwPgpM5PTOfCobae4yaAzWQpC2LTUHdHk6lTj5EIO2Nx4kw1n0vT Ybd01ujr9Sgu5SfPiJ2l5gHD+q5hHyrlsnptbUGQvST1mgzJZKlFMFvDQL0TZGGhYRvJl7LYhiCZ GzdnZnQsA3P2aMqb3WY/xRAJZ69NzhEhlNejbdY29vqsDAaTwPmLslakC8VkQH9y8GB3KAQzaMbL clVzZ8UoqLCta7y62anzYiSPn7IseYlawMJQz4C+rtk6HEJiY5hcgAzGKmdPU0Shfm3dyJG+UBhg RGcqi2cqY9gQpjd0VJrb7SjGZ7MBQnFJ4WrZFCpAYs6usZpGj4ECuXGivOKYDBmH6XHpRsdaURyd mfrECzOSJLK0WP5UIxWh0zfUm7usBCDlJsyMK4njAgPa9rEAEcVjdVvbMFiwMPnyCQYSHre2Wd8y 4LNADOWMuDl5UQrkfEEgvEO6zjG/n0B1o2EqXRw74NBIxHPWZOQyQpYWszFeskAuVbPByHBBhYxV g01eWMxnBPudw0pJ7uy4mXLE36ntHPdjOUlz5MG+b0yGFNG0mXEKn320x6YxYwl2t17DCgiFCjEr cmgx6B1pHKvoC6EAQ5UXXTJNrpyq8MPPBYjIo2LMI0e0YR8ADL/T/Oic5cVTngS/iP8oLrwB9ofJ MA5I2DylZPodaQFKDEth3O3s+KD8xcPGcQ5fZPLhx+Ku2bjwqnyR68iJZ16zGzLjVyrQkUpra7Rq 0Up+dMPo3h40fuPqR9H6v7/jsoKc63bFR423vvJ2X4uHIQSCFrYg884FTyxLSBzo+PjOtiPyqCUL o8INQzUjjLQHl6SmS7LOVHaKws26Y0/vfi4oLrx55pOyDFld89vv9Vb2k0UvX/Na8sjOPzfuieZG XzE3N1eaRIYth7o/3arpsIU4HzT4VQxGQvqf/zIjGYycEUEGLU0f1r0hoBwqxe0vr7l/mlw6maIQ 4yOHP6r70sgRMsOavc79EGfLTcnySXk11PniQ4dfDSivzGBZm4zu2YWbFshjTrS882pnw/WrP7oG bLzz8GspUc9WJMUYxg8+U7Gp0WHjMWV4yOXFvVfO/yQONr5W/uS2vgalLB31e0O4O029/o8lv9Vq d37ZVU/yOAHvyFZ+3X2L/nKZAjtc+6d/DPSL5dMgX3tDcEWiMjWGMLx84q2KAObGvnzmeIuQm7qm 8LYVMUhj32fv1u7QQUI26GtzfDtU8qdHZs90WKo3Vb7ZZbATMGMg2ONjFE8pApSvtfObj/rKh0Lo w9IjtwpUAIVqdUee2/uqmZskYQFaT2us6p6P1j8sNO17quErkkTrhl5/2itLUJRcPeOGTLa/se/z 105utSJSDuhpdXyrm/fnuwsz+/p3P1v1DSlPiGVyRqwn+kI5sstu3b7/yR6QHSW5485s5/OVm7ni uXcveEIq1b1X+XoLCsVwqbqRzqaSr99eUcIEIgdKEHjySdOZgCK5FKE+/ZbXfIkh/zg/dtnV8x64 Uh4qq31x2+hACOGhPvOeqJn3zN+4iGd8tvyN6mDARH72zPF6MT93deL0rq63Phk+qYh7SM3niNmB XQfv+hSTqBVXPDRnTnXLm3VOF5vDGveAtem/e7x0ndhV/0Llq61mL0cIe4JoWvJv783Lr2p8/a2h XpkwGaV0I/bm5pLUd1YsmGQdP6TZeuCBIwBLAWK6kJnPzbCjodK8e9SCdZqhHa9Wb/dwVWzK2e0+ YJj/2O8L0poHvnik8ktAEBMLWE5aeG9Ez0wVCgba/rbxxKeYfGUCNN5qY1y7IGFGjMJvbny1fNMg wIvl4A2akY45n724IKNvdO9T5a/2+QIcWIijbjfuvWHx19NEwc+rntnc28CWxHsDPhZ/7qOlt8+X +j+q/vuro6YlSWqPsbGTKi3Om8IAU96T1c+/3LmrDeWKQZTBTLqh5N7rchfo+7a91PKNKxwY1L7x F4dwTclrv8uNm7SzLKN7/lb5+mGdMYoPYAQ5LftPt2VnVdW+tGVcoxCnBQnNuKtvdbH6nRXzwq6e 3bWvfDY+RjC5AY9xv3L+AwsfWxitOveNmK2y6a13hlrYDETr7xHwF2CkHuXUJ0e/mxTQfFO9aY+h Kzf1sefEcSImg/D3vb7nziYkPkkgtwa7IVb+I4tf+k2cf1/Ni5vHRh+6Zv8l7r03H9q6Km3T1jVF Vd1fHhxvs2DjW5t8R1i85TMfuTIphYHqPq18dsdAC1sc5w36BaLuP8y/cXF83L+0ZweKF+Wsk3Tv S4hfKzB9XjW0Z3xBUQr74jL0LxEXfAmakRBbujiudFS34y/HH3x+6AQA+J0+d2fvlld6a/2s+Wti ViUz/bs7nt892h2iZCvm/kaO6RoMg5mZN/9j+T/umn79svwlhVGiEA7KxNFRiHYwLPrNvFWUo+HV mneHUP6y6DWLBYIx3aevt9VbgmR63oaFLMOgc6+PXfzAin88u+D3c6PPreALggyZYkZJtAqlPT9P 9ctHthkgmZ8TysoozZaK1JlXP11Y2I+aPafy+EPMKElcnEDIZEgTlKlpcZmJ4h9OJ8dKpt075/kH 0hbodHVdbtsU68sUxODG8FLT2LlpDCYQLjsyZJiCV+T4yMFaAmBCCYXCOctVM0uUCgZLkatMZrHN 5pBHELPwN2z7SDCMYd6Wvq1HPb4NJS9sKr21UEJZ4cR8VYxnbOdzvXuLC555ddlTd2YleyhQIMlA TXs/bn2nBlCXqNasluXXat97vnK/KeTsMzQOkVwFM3uWeN46dW4MhwPCgsTYdAUDZDBjUuMyUlRq KQfx2zu2NH/whRUqlK+8JHYZECh79eTj1XpDQ8eHXxmHCnOuvqFoaa5QwiSnjicBeYV512xITd6a E40AACAASURBVLGBA7RJmLiCyCRpmTLIh8Cr8++5L6nYaGjo87lhXnRmTBIAQmJxckZsRqJMxYNB r7WJJuAbJ/97Al6vfabRA2WoZ89KUo74TYLo0oeXPvvysltzootunbl4GBvD+AkxIp4fImMSaMda CQKImJedxc5M56QCgGHnYPc5a3DU1LR/Dzk/Y23x7x6dv9ox+s5LVZ836k6+0bRDT0hWRK8t5TNb R959ra0tBPCT4zPlDJjFjp1gYHyUNHFmfDbM5KbIkcPVzzx8rC0zY5oJsE5X52qGtr09MojwF62N XamCtFsbnzqoG6mpeOCVwYNu8bK1qmUq0L+9/ZPDRneqUk1CY5R4xnNLX7iWCxwaOGycNME/O2Fe fIwW41yx4LG5LCFPtHR1YrQjPKTTVr3X9P4ej6JEsfrSmKVh7963619utjoGnF0tfqOcGV8smrsk ZmEMmwcC5OjQ3hYC5kCJ00VzV0QX50sljEjSToaMn5fNzkzjptHmZ/dIrzdgrO/9tB0X3jTnhU0L r80UhC2MvBnRSsvAp4/VfzIIzV4ds6ZQIGoZfe/zvqPjds1RR5cTDyWzCxfKFi6InjVViY+wveHh yk214PwXV256pfT+dM7YKw3ba0xWWXTu/LQ8NoLkpSxelL8kSzpFxmPSsevgI5+ZAteXbtq04oXr kjMqWt/drzdlKBNoBoKSOTQD1zFxmoFmNDioK3+zZacTUK2MXruQS1UPvvGPtu5J3onIMpTxPoA5 d9Yfrhewu4iSh6atQolGYyDMFydeXbA8TcbWh32nogshfvrCOIWFGMpMvu4vRTdLvCMNpv4AM7Y4 Wh2GNdZgQKpedRXTNB5GAZglkyYohFImWxqvSMuMS1NxaZMI0gx8svnLCANjV9MMrBl6i2agNfzP bKWdAUo7VhcKebJVlyxkAH7/nrJR67/2wov4d+FCe8BkQO8eFwhLn112E4CN7Tv5/NeGhukJ6zOs IzaIlc4SsRFeXswSBBmPpfUf5OflLE37BrFJrrhn1gYxTFGnEvN6B6pcXx5v/0br9c9Jf/CBwunG 4ZZBlCdixPGYbJa8dDUjBhZHMyE4Wr14OQsoZyy6ff49M0WsiVQV5y0q0eO7LLs0bc63LVXHRnfX mqxzopV2POb63EWpQi5HPGtteNEfujqBieP2tP0tTV8PavYfs4mvzr99jlwGfbevBkNArFi9IHM5 RBwTQEYUmNz+kgHtQVPtEX9wRVRsrLAgXldHe15TMIuRmnZ9qbFSgGnrteYxKsRxHLWR96pFiWIm l543sGUphSD0BYzAJBHw2oVsxYz4+fPltvK+7Ux3RrJEHtZH9Co/etncZAkzUMztNMm46TDaGgg6 xCIuG2KIZNNupxvAk3DYinz1huIhTcjZUYmaAmxjv3t+VlLenTPvQGv/1s5edE/JLTyKgEDQNmY1 BNxBJIGLwAgiX5fzO5sbZJCoz21SCbOWZ/92eZTZaDjREICnTKcAspMSimFbIbuvjAFNLH2BDDFf nSWN7aJSS7NX4sFvxcMjIYoQxy65J9jzTFfFDPUtD5ZkEGSknLvdY6IJCCNpNAEMREkT4A3wOAx2 rDIrN1qdA+fdNuOGEjkfiOQ+ALLmPHRTx5ZyV9nBXodKOvemaVdkShkVdZW91qG46HmJUlY2A6hH WN+tv4ETdQug76txTAp4IqdCjGz1VXmrYzjTjlds2u/p1/pBDSaKZ8SyETZPuXw9ksgTRTFFOX8o iQ3VvabnL7un5FoeRUIgFILmx/SUmW011boDvbhNnmrhs4pWpWZ1177pgnksJo+FiGap10q5JglC 6YytIMCRcOmLzGkxpSwxGM+PzuCmiljcOelL5qYXj7OAnYQ7OCmhiHxGdAaiwZZkzLLX8+3SPDVv 3OSHA26TIeTFEBkPgWCG6tKsmzBCzkb4GdKiy6NMZMBwyGXxgNDB0aVzZLMyMm+Z52gShMdq9SYj SCQ4G+yorHW0fMCuSY8vTZZAGQxwiMECMDTgd0Txcori580Xx+/r2gEHitOkUutAjx4E45kyLoIk RhVdBoiz+DIOL3551FwBYNboGjuDvSKR75jm0ptTJkmGg3lGGgFELVq+PqcU8sU368u+6HIa/MHV OZfewiSf79i3JPu+u5Inzew9AcrRbhnmCWdeVrhqBs/PDg3sbv8giIMpsjSagQuyVs5NT+9jkXsJ d4hEnSGHDpdmIioWgx0TvfZKVoZYIJ6s+4XJ0mQhK3t2yrxQNwMgCgvjjGA3SAsjmysvSl6QOrTf hkKnKn5ArNgSVRrHal+au7Y4fGgXHMKoIIFEpUkSuQwmPRHkyDMKAKAXYnDYsuLU1fMNNRpL0pW5 dy2OkeIkLS2A1dhjBKEJBjIjDKRENANPSWfYq+/W63jynAzZ/7HiAmk/PlrlwmQd3a+No1nCsGFP Z/3vsi6ZLJn1RfyHcaE9YDLYa2r5anCrJcieG7d0fmTnxkkwOKr4IoAKg1RYzJMnMiCzH2AwWYC/ //MjX1ZQhN9b/ln19rK+nnBkfEQystZdImcf7HrrsGfG40svFcOQkBc/A/aFSCOESBR8ZShodoe8 JOWtr9v8ghcIhnsO1m//qqF8PEBOOrBCMCtenhbl7elHGcvjEyyuqjE0LUUogf19W499uLl2tx91 He7bsbVmf4fZHrGXFASgu79o/mzHoWeWbl/+drfG7equHW/Xu811A+XHzeN6vKtisN07WZEfPGRr MjVrw3BqVLyAYDoBoGbkwKBv0nJA4e6BvQMhyaV5t9w4fRnP09BmaXZiFJMlYjA47SOVu8pfesMX wny7j4+7o2Km6ZxNLxy75YpvH9msafZObEEp40vo31vqN/z2mwfvOPmeAaQokKGQZoj4CmEYFfOU Kp6Y5Wnq9UFk2NI13sLgFl5XfPNyldRgOdLnseCR7E8IQIa9nvfeP/HJ83vuu7nsxQ76OYESIJwg IogRyJKwQJcPkYsEfFH0sK3z8+YPt1a9Xq5rCoS+aDKNThoi5LR076nZtrVrrw8LHmzcvrni825X wOrqrNG0a2zamt5Dh606moFHulu8KCpSZGeTaNXA9k8qX3vky6VPVL/l46dMEOCgCYgTRgjoCyBC JNzRd7B8uMvqGjra+Pmujg5nOBL2BHJS75/9e43t021jfVnq65dGSwDC12NsrLU5o2QZ8TAUJgHM vbt8ROtwdH9dvuWLgdbx0EBV++dbaistgUntWqh3rNbmMoyY/vFx47efH33nGxJisNKTRbHZsCNI WtjsKAVP4fWNuUOBifxdNAM9Nuf7H1Z8/PTuu2878mYXKi1mIy2afby4O+6Nqt483IFwlmXKpVGq XID0AyAl48kSQXLUBwm40szEubTEynBAKoyRQkGHR+cM2lo0tVa/s2awoX2w7Csv4Ecrj3QPThI1 hhuODRzHiIqKnhY/4LJZawdt9n7TiBkWwtwogLCDiDhBKIvHAkNBRMQizb5RFyxZVXjzLRkl/lB3 g8GAU8GOvm9NZNxlBbdck1WEuOs67L20ZrXr6+oc3lh5VhxEhQks6NzXZEGlyrw+c9kzR29d980j nxu7Q1CEoviU0okoLheHLVez2EQQD4AshHT1+IakktJbFt5+ozK23XayY5Kwowg48oKVVMhlefWN yt3fNu44OngyWx6TLhbrhk9sbzjoDQcr27Z/XL6lzRaY9HEAil2UmOII1j555J19jTu3t33bhSQI GTTzq2kGnuiroRm424fTDKwYMkRxo9NhW4Bw8LhyOVfh9g550cmikwhnl77BESiv6atxgATgPlY7 rvMEvdX9Va1Dxz8q39ahH+izVu+o3vxVZw8WHNzVUxHEQuXdR2u0ze0hXY+hfsTmZHJkEIzU9x/8 5tjf3w1hbtfBaq2NyRYn8FVBe9Pe9s/f2ffbK3csPWxxRxhIETQDeZwIA0NBgmYgK7JPEj566I7f H7rllj1vjk9eY3MKUP621m2f6tsceN7ti/967/RVdsLVrn15R1f3FEy8iP8kLng5Qoqgp3X+kdfq H/q0nRPwBkqTX70uN0mO3fC+Rb+5672HnDwS86XIbkwTSnFv/ZMdH1oAHPYfeKpuYGHqAzPTczgw gHCTLs9e97Gxa0XqbYujIvNfpXz2o2teevbkRy80PcQEUBZQcO/MDCHi21//fB8OQMTQa82PF8Qt j06Zo540nRbElPHUuUxsTJ5yY/q89xsG9GBqHItLeRo2Nj6B426cwNq1rz3rLb2Pk5KvlKanrM/t P/l1x3O7KDReeF2WlKe39e4NuAKooWrgSDCosVGuPWO9T2ColHXuZg3Ci14klDXo9vzlZIWaV7pC mFbmfLfPe08a//wwCMLt7jOgfc80trHBIMbKuS7mNzEciK/IXixWvqN5Z6OWMGMoTFaUjTtemnn/ Nijx+OAgBCIjLDmtk/R3Jeorqq9iflt/2BEU5fKzW71OEITUGdduDGAP1m1+quEIQqFOLPXx4jyE sNq9TVXo6FCtEAtZoqNuKpGnTSSD4s4telBWsenFhseFUNSa/MfVMUVPzNkoL392R/sTn8KgP2hb mvGRWiRX5N+xwfj4jp7nDjGELhTDifF6g+F3WdPOD2NxWuo/aH251jnsJYiTmpcGLdKXkpeqXUPN AZcO1Z0cKnf4TDQDvxrtf3jucplg+h3qmfdp33ncBkmYKbelFiiVhTQBwiN/pgnYDoO+oO3S3G0K 0LN3bO9uc3sYgF93NhQFnsyKT5FxmLTDkpJz613V7x3hZV8/bb4ABgFKXBQzJ3b0g7ebHmRThUvk pdW2iq8HBxPTTB83PleF+wMksWdYc8yO5aXnys/LOQyQvm59i8Vn85LmTfUPs0m/S/C7d1feVKSg Ni5+7JWmL59u+ANMhrnQnIcTUpFIjDdv9rQ7Pjj53vONg2I4dv30NQpJ4jSegEn51uZfc5nb8caJ z6ZF5ys58qW5v3/Zbvl8+LUHjGwMdeeqHknhCtXLP3qNfPLxoefrTCwMZ6WqNmTxwAq31o6jBm1j nWCsHAfCgPHL0aHbCtLOLWkU0lc4TBhB7O3rVUNMm/eoHRd7HRYNGPPk3Mdijz7+XutG2tkPhQNX FF6vQoiqsLXGemikoQ0h/Eaw5L60XCZEuZzdg37j0w1VDMoLcormKlcoebLZcfPl+q2v1N/DJKfP k5U0uyrLjHc+NuOht6HEWo2ehSiHkAF6qkuzTqC+smyZ8aUTm/5UewAig1JO8RpJApfS6kKmTvPr TTYh6jfxhb+9LGXyHVyYX7Dpivf+eviF52vvYQNQnGjl47NvL1EKWk58/Hr/bjce3N/3lxom/4+q lYVRk+WpBTmr1n32x71/fb77qY4hmAnF3jb3gQ1Jig8GIww0amrruMJKnEIB465x49WL1mxcoHml dfdf6qohMsSDSp9ITJ7knZiz221wYuYjA+3r4EQA/aLZcIk07GkYPSFA/Zu6P/HgviBoe7frRLZH skQqOuKxhEBh5VA5JBoZJAOj1tEutzM3dsYqnnDb0LOtYFhP4iJ/dcW4cWlcxgxFSTrz8LbOZ+g5 Sq7q/kQ+SyC9clfp6Os17/yx5gBIBhW8hZfTDIwoJsxl8Po8AwyOdPI86lOB9LXrakf9dpyq4Ihe jxp+OwDgYX//nv62tVmnMtJexC8IFzwTFhXwO9wYNlFoGgURoZwv5iK0laJwPOgNebwhFEY4AraA x2RBFO5BA9Tp/TiIAbHoi6cGRJIIWj0uHk/GZ56OPiFJzB/yekI+AkJ4LIGAxUUig4s3/B39MIRw EC5jinVRkgz5AnYUEopZbI/fgTG4Mg6fQeEu9Idi55FVXwaHBcMUiQcxtzsUAkEWn83nIKyIm4jR 82UIgRgUReD0pBVkC5isySKBKQwLOP0uuvECNm11CYwiuUzhJPGWABX0Ge0kk0H78BjFZovELD6T QdsQMox5XT4PxeaxJ0q9MmEeByLcLpMdjZQVeLXi8WZo3bb196aJeJhHN+IOshCsofPDF3r7byx9 8778JJJA/ajTFQwRIEvMEXCZHAaAe/12PwWRRJike4Ut4rM4p3hFX/GiTl+YZCFcPt0DDISeRKGY z+FzoyTI5giETD4bYQAUGQ573CEfCbPZEx2KwLyJnj2P1UQ4gIfw7/qFHqg5TCHtSgWwEAnACAST 1MRRlu8YiKE+V8iF0SMOS8BlcJg0/ymC5oDT5wmTEIfDF7H4LBhC8UCQwL/raw4XYZ5mPkUGAlY3 yVXwBaeiRwki7As43ATAYfH5EScYp0llw2QQDfzgS9A9y2RPJi0UigVCBEb7d2jYE8AgiSCKvhMG I+fKIhIY9pMQU8AS8CMSCE58LugNu/10DzK4vAgDaQNtt4QwCV/BAjCDy8KlvdsJBmJ4wBP0+FGc weQK2QK6CRDdfCzgCdm9kWIMPCEtbDCM4SGaZgpAODAYJNBI9BjM5Z/Pagr3h/20ptGKA1Eo3TSY notSFBPhMEFggoH0W2lOCURMHgsG/CEPrZgwQHcuyeUI6W/Rnw/49A6SBVMhlAA5LKGYzaP5TzOQ lhYPCXHZfB4E0sQwGTw2gDmcZg9BK233c+VPDAge2HnZb6K5LFrYfGGXOxAEYBafI+DTwkaFzX4f BJEojuER5z6Kh0wZ2BvRNdTvCjoJgMnnSGiRYEAgjgcCOEZ+Jz9sRDD1gWwKRf3eoNOH0/QLRBy6 UUAIC6CRVNxMejZ/ioEMmMeL7OSgvsgYEqBJpYegCKnnayUt5zgtADit+0wQD5EEAjEJEoMgJgOk QsQPx81giMtngD7UH8njDCIMkERJel6McCf4T/u9Dq8X5glZE2neIypMC0ZkEHP5sDA9BnIZfC4z UjeE1hdf2H2KgQKOkMdkIxPbYTgWcIeCDBatgOdXePkRkCgWPCXA9LADEQFfRGtABi0IzP/e/Ku/ WlxMRfnrgMda8d7eRY9qT/9576JPnyr5jZQJ138FlvScvjgvZcMrqz6cKfsna1pcxEX8CJz6XX/b t36T6fSff1174sGCeXzGxSH9Ii7in8dFA/zrAO0nmCy9rVpNEGAnxuRlq2K4E7kAwu7BysEeN0oJ xInTk3LkU1d+vYiL+FdAYr4xQ1ePyRAC+Slx+TlKJfNfPK56ERfxP4+LBvh/Cqd7+1+onHYR/32I rK4TFIQw/mMpCydqbQL/yTKFE2U+L/TnKZIE/pXKpZEaib/A2o0XceHwq1pBihTtjKR7+yVPGgjM b3ZoR61G/z+fQR53u41a69ioxRA4OxsigQdsLv2YZVTrdGDnJ0r8AdT5+Q4j7w05enXNA07Lfyi3 /alMohf+tVjYNW4ZHbNqLV7vLyZt/68GJB4aHztSPtrm/w+xjiJQg6mlyTAU/ikCTqWc/OfJPJ0K 99yroZClbbS22+G9sAwIOLoPDTX5zkkHiwcdLv2omRZXc/BHSzqQYXP58HFd6IwzwZPTfy5w1KO3 a0Zt5vAveJy8iFO4sFHQVMCr7zJ0m3Dh9MT8GB4vYO86bhhhIXFFKdNk/1JyFzLgNzRq6geCDghi AJRkTsqCNKH0F5hk3GNpeb9mc4Nb8ui6R2fL/6lKrKSrrO6NA+O9TjLlqWufmSH4IfrVZ+/+om7L EbOWI1z1t1XXpUxRUSDkHtg/2pCasCJPojhz/u21t755+DlO+u1/nnP1VNkx/22gvO6h2pEeoWr2 zGjFhZz3kbhZf/jhI5+ikHRO1tW3lKyO+p8pf+uztn9j0iihUxXbST+FxERlZbLDDaZBFCUpEI9E OFJMFsJKVmT6bB0GDKBVBgMAATsuJzZNxo5E9+CYq7712XfRBR+ri/g/Wjjj3wQMdR6uemwLPm3b Vc/H/8gWChkcMbZ0e6BpCdPjef9EkXrSYWuv0xnUCXOzZOIzJJA0WSru+/wp9cyPPlo6+wIyQNv5 yuqKgZaN1dO+02CK8NUM7d/Vtr/f6YSZ0X9c/4+SqXKMAEDYfOTynb//+9Wmu1KEP0r/uXDqK1+u +WwopH7+2r/kcM6Nnb+IXxQusAG26CreOvL00YD8j2vfuCkzp+HkX+/srIkSlrx305cyBJqoT0DC DIQBn7V9RFF4GCeZyJRBemjIVNvyt431x8fpOSNps6LJ727YqhacNsAkgeIkiEwakYsHwxSTg/y4 tSFRDIdg5iQBJRQWREkWi/Uj4k6RaBinEAYCUDgAMRlMNh7urTMSusBd4bAYZJ1ZOyniAuIUxPix ZMQ0GCJ5NNd49Bud90HirJw4MIMrjxK7tGVHx1R3h69MBiY3wG5j9YsnHl9TmpElVpwZQMnmRc9L X46oEs+JqgyjYRaCkGSEi9/HhRI0VymIxfhpCaHISJlGCEJ+NCKHHj5aPj7+fkpJbNHPMcCRSOxI EnwWiw2dfR3DCQhmwNB3l0GQwZHIVaIuTWure/bPKYpAdxlK0E1lfLe8R+E4RoEM5IxQW/r7OC1T EBkM4xzW6eE+UjOAtmuR7vvpqR9B0HIB/xwGEliINpcwwmJC0NnXg3jkVOiU3NL3vn9z1e4U+FTY He4iVZeXbLxb7nrxxOuDLjcBhCaOGHDFvOgrCu51dT6+xw/QOhYGgCh+9tVzn3qgoCAShw0y2Jxk JpYoOEtLqDAWpuWZCeJhAmb/hAZNPEAROI6DMC0GpwimMAylJYj5w6NUpBQECTIYZ0UfwwxORvLS tXgi/8yGUlgIIxGEBRJBAuZEwu4xW2XflvfHxU8LMiY1wARBKxeJwKcPHGCRmpL07IPz3bhAGXRH 3jtWtWZlaqbszBQcII+XvDL/iugY+TmMxmipiKj02W2PSAbBoL/yU2vLkui5t05LjTpT/8PGr3q2 fm5yLk+aHsVGmOCPeagwP+WmvN9lCr+fkkxF/7lAmJywv7HCpLOFMRQC4TOHIFpXcYzWVgRhftdN kQVFnEApIDIo0wTB8C/Qr/mvxYU1wKBIpAAELIOz5pvBzjUxzE8HDhkIb1F8sRL01LV/e0DXbCEI Biv/qoIrZysV1pH9X2l6BSw1EKhsCnFSFEs25C2O5Z4/B6b8fm1F2/tG5oLb8u+NR6ve6uqK5MsD IjVT2jv2fGSoxUl2omzB5dlLU4VAz1B55XiPUDG/gOXYMlwWpLgbCh6BLYer7XalODFNJB+195j9 7qT4tUuTU736k5/37uzHCDFPvTbjt0WxSoe+7vhooxXOXaaWNXZvqQ6GCpMfvj03ZdJR0Kqt/Kjr izGMYiIMMTdlTfats+T5ixTJe8Yrtzc8W8liM7ilj867Mp4NhoLW+r5dR40dDgrKkC1an7c8GjB+ 1rDXSAgvm/Ubwnhwu8GzIH7R4pREBiReNf2eVMy819T1/UdJPKAztlaM9GFgjIolA8JTJaKi/F5z v3nYh4b79b29QibMVGbGRjMA3GLtON55QocJsnFmpMwLRA507dxvtsPgwHAATBGmOXzdQvn89Vnr Exiuht4v9pr6XSTEElzyyMylMeypbACuGT60feCgnqSiuKkr066aoUCaB07Um2xFOesyib6XB1pT hEtvLMojApZR85iLDFhcI11jTB43Wi2TMSc/W0I5LO17e79t8ZhDFMgWrH98/jIBaj7Z/nVnGGYR NkPQyBctv6ZwSZKADxKuho6DzU7TbMkCptlgAaYaO3C7s+dg68EALzVPIm81l3e4LCuz71+TlIp5 une1fFgdRClGbEni5cujkNqRCqMfGwsO+eD46dBwcxBemP7gVenRNkv7gf6DLT4zAEUvTl6/LCmN Fex7r/YAwJII+VnpQn+7tg9jx89JnZ8nxGq7t++xjPooWCRef/+M0uipGEg6T9Rv22nvoU2FUlSw NuOqGVKyvu94oz0YJ+JVm6qCAPzb6U/NiZZM+rQ0ftZy+IM61uV356e5nYZO+zhB2t3+wTAhXppd 2DzwVTtQ+nC+8nh3pS3MTFHFMnXOkvS1CZR2a//eTQ3lN+XkKJnIhP1btdqWLPpunCYCuhOd2/da R0MQkwVCXN61f10wc3LXlLTsOfHJKCzOUs0MeU4eNvXkx61bl7GE6ek50Luz3mulbfeqtHuWpqWw cP/YePnX/WUjhDiBKUIYgFC46Lpp05mE+WD1jh6cpxTwQxhBD//0W93Wjq+6Pm/zOkGETU9sF+Y8 dUksx2zs7TANWoJqjamnA5fJFYkqLidoa/i4uQrixRUoo4e0R+oD/BVZ6xcr2DU9nx2yjvlwksfN vmn6bQUypt9v0tgNbsqrtw11jYV5gvhEiZieCPidHV80HeewE5RnFMQMe0bLOz8tc5noOXV21FWX 58/hhsaq+w4NoAwEM2mClijp2puKlshZUxwQojy1TV/Ve0JpsNQXxAG6tQDl85r6B6vG7EYFd8YS +cps9YwC8ZTur3m8/O3hnmRY7vX5ADkncuRsCvrPf1YcO2eVVLnPon37xMYvQUoiWXP3zNXRLNDv 1Vb2fnvCQus1hXDn3z1rfbqAQ09rjjZ9ttfeS4H0kCJemHbZypQZ/F/VzuSvGhfYAEvkedPl2QfH u5o1rbXdjmMTCZbVsktkhHlX+4FWjJckBKpGt9qpKPW8S/3mtn/UvwHCci6iksPOnf0ng1T4jhmX yM9zZWnHMRACgqBD7zIUSqfdnF9YLFUxwWBd+f1/6qziR61IQgyHRh4f840+POs3RmPt5sZPHNxd aqYwGNI1+7Ui8XUJhr1/7y0vUF92XXxOWd+HlXb0Jqgwi+p6tOoFbyg9J5rfq9vbYPXcN/uuTHf/ zrYPqoPsfX0CyIP2uGrqfGtuzk2ZZCmH0H9S/udXtcCGGYv95oqj3p70mN/MkksYIAgBuv2jQyu4 rkPOY2LprD9ncU82vfJY86EQKVYy9FUDR486Qi/kS8saXzkYhlPS1oj0la/Utzrw1AW0AZ7g5JlL BBQZ7tbse6xik9VFUTBzINDnR4qm6AJieOCrjzu/Gg95HX2vmvRigLFy+40bVSDp8WhrQPx6EQAA IABJREFUunYe9enmkBvz1LlChNSPHX2l4yDAiksk9ftBQRQI4Tp3rCCn2/7lmy2V0qi8KNhxqOOP Bsef3rrkqqjJXCBt5/t317zbYmMXyQX1ni+P6PX3zljtHv727Y4T14qzYhld7zS8rJIqr5mWPjy2 +8mWLX0hU9/gS8MGQUzs759beFk8b9L1MVyrqTrY3cZVpfN9ba93/TFZmX1ztK+mZ8eb5rEkbqyI sI2SlWJZ3M2ZSeWH//D3/kZtSJXOMA9jeEnsFFyhSL9vrKzt/RMkM4GfgKD2Vm+Pl71quQJ/8cBD u01YsTrP6655e2TUkja9Uft5lTGs5lKtfuM+ZqoarOtyq3MEs3Yf+eMXdqeArQj4j1SPllsXvLJB pj9Q93wLokhW3Ht9su7vtR/LZWuVoujB3m/eba+PVU2XAuZ93Y+bXRtfXnnZpNUIMG/359WfaeUF aUK8uv1dGwbEzFjUMvDV6wPNTG5WMh/oNBzShZZ9ecXaSfMIyhPXLGNBzVRCFMA0AYzVKVfEKJIw ewVKpf92+gZYU9YOrr53dlZ/dyVPFJsnnRtnbpmmXJKHNe2CDtsYp11TCOYmJ63aEPO9q04M97// et2bJuGGNdFQRfsHQ/KZT0xlgClfW9e2t3zOWEmuBPeN+Ie6/FFJDPho3zstJignLt6jr/+z/vHh 8F8vFfS/evSJCh8Qy4k96ekx4N6ixNirCqbBhKul5/Bub79YtTgzfVE0GwZI26HWd19qap2ft0zh 79/bX8aNum+FBDrStWWPrt1EDL/VMLIDYV05/x+3peeGPSNlTZ+0wmG1NIXwGXXBEFOQlYnj77eV E/yUXAH+bf1L2mDutlWFrcM7/969tz/kNnU+UzXISUj60yvzSmVsJOwbLW/fM0RRc8H/x951wEdV Zf03vfdkJpPeO0kIJCH00HuRonTEAoKCoCIiKAIiFgQFAem99xASQgghCaSS3nudySSTyfSZ1783 wVWBgLus6367m7/+fsY377533rnnnltO84/pHn2wofbr9K+uFp/n80dJkMor5QVFXW+/4+d2v+Tk 0Y4Wb44LE2poAB56usROc3HuecWHW6vrs+Ma75ZYYcc+8wP4POJSlzrz0qOdDzsaYXLH91m5Q43f hMhkz9ttatXV9/J3NVo14+gzpnrY47DuefT31JpEsy3P6y9U1U3nNJ2qKpWI+64OcujqrLxffL+O IXWgqK9W7aKyfb6K6mdsS1r3YK+WPWCWIyWtroTOj4rxBP7B1Je9eHn82eYyMpVPpoYIoi3W5K+z unzlc/ybjnTZjp25jmIve2VHl6YJtJbUdbYYQcQz+LUleV9/Zwj7Yd7nLvqi/Snr4msTo8ROGmV2 tbbrlxkIMfsFrZjs6jVlwCc5ORculW5NY4rYTC+BS39fhmpn3uUUk/QjVy8HgFNtOnej6t5A91mT Q6bH1N050AgvmvjBVLm9yqpxk3iSZPNf7SoqoVOcxW5kGtbXf/7sIJ+SpJlXW7PljhOmMJgWalls TayP3cCoqDGv1F3LLb4hEX+3etQ4MtwKsvs+xzJlblDmqzHhw3Z9DCU8xsktSMz7208B60dtXiDV vXl4WnWHRutUdyHzNGA/48thK/wZLRfvfb6r4EhJ4I6F/hFn868ZcVak59jJ+alapOck7AhEqLlT eQZozaBtA0WGn9K/vKZ+Xj0BipvnqOmaygf5p4K85iwLCCZTPQQk25B0chry5nCt+uGWLlTXXXmU 1jfq1Yjis6jf3rnoiW0q7vthIRcy4rPK41Wd15L1khWO7p5M+5PQmcbyz+dEjhlIq7qeEdcBPLaR QQAzbN6A0Cup38WphftnHxsjwQsqD351/0qaY9hrzpF2dXe7IIvAZ9pa7sZvIRgn092dhi8Nq9// MFHutWi+n7eQ6y9hPNfcx+U7+3ClDV3mLnM1ADeWtmk5vs7RQcMvtt+MDFk3n1f/4YPvqnVt+jbl uqIrtez3Ls6djatif0za/1yxJNFk9v0m9x2bm3rT0Wf88tChFEwn5Ae1V/64szqFzF0wj+VZZ2m7 1nxeYicewBLlMcXLo0LXpm8ZFfX1dMPG1bVFDxv0u1o1w0M++ixiINiW8FbK9k1piZPmL9w2aUX/ hIPh9v7eIj2LThD5aii1+eOKa2kmjw8Z7o5U4XHLBVXF9ln9xkxw6CE+m0IRBTiGWExYu0avMlYB XSUa0twh7v0PNKZ4es76KmrQ5TMB+1rutcCTfHrWtAwmGerSnfg6F7GX9J8Z+cVAKR8zib/3YAZJ kfOEEiZThPy+n0/9mWnv2llHMxsyf8x4j40ZGswDv504Ukh7vNgjM5hi2e/WQma9qh60KjT1Kmaf EOn0GL+A5xoSyY5zJq6JP7lKg7ltHLfUmQ4CNH5XyU83a+KaeYvH0T3lnMYT9QknMkO4AdpjXZS5 UZs/CPBIvL9ie5VmZkR/NoVCpbjPn/g5Nf39c2A7+Ev1YlClqVTD1entIbPZ7kPkS4bK7WgsygD/ acO0DYk6h9nhr4VJBF5SZwqJxHMcuWpozisPzgW4zlkcFExDQRHfW2ypihAHV3SplQjUimuMxH+p Q/zcRr3uX3SwsDQi8K2xLo5iQTC3ewXClw75eAL4c+Ln2r+V/VW3pMZV3bLzWP/d4NeEJP2hGwuO VB4Y7XtogN+Ay135w8M/mkjKWJH1c4W2C3V26jnzD0k0bsRaWbZuXM550y+DmmQvi5o7dHV5xk8m 7tClIZP8RCG058dxufpO3UPpGBy3xYjY9jAkKu959D8fYTumfjeDXb7g5Pv1nXoAcGAwhW5Cl7Yu ixZqhMGiUpUKxXCrSVFgrpOThFbTwAjZsH4SjxfZ23rxZ+NPT0VJIiTSyX5QGClxZyN5Vf9ZmU1H MByqbby6viYtQP7a627RjDJDPYlC3MnmO/jSyBSyS7jcm08zuVGZxRhoNrTeqkuq6OwSUWwqRwdl DbOfM0jQklJTtGD4ie/EpntZ3x6oSrpZUTyaK2+1+bz6ykVSe0AyMfSLIWSpL58nEJIdWDw6O3ia d1SQkB/cHV+AsaOmBk9JSb+9TV2lAP1XDZwabCeoNNnSCoSI5VIeO5Ix3V4GBspchVwHN7aQTRow KWxyP2dfChD43PgEinxSyML2VgsHUqRrkuspoTTZoOCBobbsPYB9qMzDUwa52W6jQKhOZTZJuI6B cl8vpp0PR8aCFSCJ5820rTWpFCaDwWVhJIxC+XVIUSi2YimPdyU4jsGgWcCWhbgMGmCvuVcsT+ii UHqmiiQQ+feVBQupjADHwTFeUXSguy46lcJiit3sPSUMjorcvUUHSEKxi5RMxnguUoTF1np4SZy4 JNxoNughC0y3t+eJxQzZp1FftKhRFzbZoKlMqzrdQPG0bcVQk5HPmdDXvdlILATc+7oEenAhiyZQ il6BMTKHxmeSCfJoNA6fi5BsxXBJFKbAe5A8NJaS4SrqO8onmgZDpOdoH0RXeqDs5CmtcHXYSD+S fWbyF8SqjuCGhC/147tFuESHi6XiYinBNgxUN2I4jR8x0jVMTVa50w4ayU9ZUX9jC6F9HEVyHt2z v/PwwW6hVMDWq+WF7ToS2Y7l4sC3EzFjxCxfuWOUtLOVx7B3EsqItw72CnWttCfhCIJo1BShg8g/ QOYDA/VcBrvAoINowpCQZWse7DhTs3O/wuQoH7ogeAi3/bIOAhG6TMYXSiiS9ZGfdejpPRlWbCh4 8OluZcF4ny+G21lx0yMVQAbIXCnHjkWlB7gEeUq9nW3FiRD8uTqRSnyZvcPak8O9auvrH5Yfy1UG vdd/YrSYkPia7rUSsc/l9/UeApCsD0gUlOwzwn18g/p6mR4U26oh9dgFFFePqeObKSoI6up8cMdY 7Yy0TQpJDOvxXJLEdHL0k1D4VPtx4z3DGWRiPFruF2oRBPQT2MnYIoA5brPAB2P6kZG7epwtYDs5 y9ycmGxCLKUCka3uI4nt4uDnzBaRIZvM2J5JFkd5Tn7F6o5gSE7L0TyU15Q1ZuiMCe6yPr4ix2zY PcJ5xAgnMQjDxACgMu297ORCtmR6n1cG2+TXZsE4n3HgUn3j+LA3BkupBsX1bAqDTqbzhH7RUt9Y SkuAfcRo7yAqAj4eQFSGnbfM255CagUojzsJggwoBrvY9fOTuTEp5D5cLmrusmIMN55dkDign0tk fxaFX3qRRHq+wxiJJrXz8hbIiT9pFMYvnGI7BjlGuXLP6QQBA11jnm/WsYHFlQVJ/SiEnqR0qwAy 3f459PcEcrcKkkc6eboxyE4km1kXs7al1F7c3lIzzmvGeHGgOqeDUNXErSL7gasdp3WQmGXqrGJr fSWL7WXnEmXPfwFtvfgT8Sc7YalaihJbSi+omsPGfpcwwquzbN9yAJCWnY6ikDqsxuE0PmpSNhi6 UlV30pSjfYSuRBsDuGfQfvU4WsOpts4poRF9A8eP7jMSI2bNx0/EESqV3dZanNycAGH0DyNWe3GF IirMYtOpIv9pdPIDMElhXhQs41Q3F2ZYqAFuA5Kq7x1rrm23KPbdYcvYEe9OfEXcXeYozGX8MO7l n9uLpvXbOdLZl0GmB3mPBBRHydoutrsb2PYovS7fKIgMKqv4qiq/Cim/nPJDDcMtZsSqodLnuFzC ylul55NFH1weNqa6mvJ2XpEKNGk7iuOU9fVwVnxxqqCm7hIAsEtOLXGfPcxVtK7m1Ec3qWMZjcdq UluYc+UsnkjkRTzmcvoPlei9c+aGsJYbj9qCnExF8ZWPKpvSDXDaibhtqQyXcUNm8UUuVZUJO+5u ymMrLtYkaaDk5KbXgkXRnB48dAilRugmLDb3MLflZnzVXq1kb8q8ccV55xJqkh+2l6o1id92QeMi Z9kpz1xCIKzoVqizUaW9fqccMSHFMD3QzHYGtK0WgO7AYTXWPzzdIXuTyfVwn73/vSnoL3WEiB00 neiBqT5BO4vTXj37ydYAz7uF3ydSHVexvWR8FY3OTS+7fqjl9BajBbIcOls29PVAR6JLMTjjbul2 eotnouq2e8COvcPGPLsPRmF9q1FBB5xkDGprfXWdrTzC2Qzv+emFd2K1dZzyWBqztamzrSo/ed7U CaNJ5NjWpRtvapm6q8fMCu+mhIy64VO9XZ7STDhqaqy7vffhnXyoUpi/y6wYNmPgpECJnVfQRCD9 KA7W45R+IqDtuqKgBQNEppaWzoZbxaAJBM8/OEOjIjr4UXXH/MFg1p38LTtN07Qtp6ra62b162dP oZKojnOHfPjtjW33sIi3gxf0F7EASh8uoXlbmywAR84hV9RmXjJ6LOl5uw/WN9xssjDZDDZgqVcZ m1Kbq+Jq79k33m7Vt8c+uj2aXL5XC+jp185mvbFhYMiz+x1V5eXDWtRKLyisYTMRY1FznoOfOwKg 1WU3rpbEnTHpAPT81otNkWFLh9vpkiru50ONQQz5Ku9JHV3737i4zDh2z5shHs9SlV90JK5JvXDw Z1PcycxTMbGGGh3c83kLosnYEbs/Ee2SNx/48mZrf+/hYwKD3OQRXHYiWadl+Mu5prLYulN1dmH7 +4VMQg/uSl545z6uBqta0Chy9yNL845cqCp91HKvEfH8MXZbbVDM2ACP7IbbN01eO2Pe8DM4hN/e 2WTS2Ty3WWIvvpO+8O7hNMYdc9xFTcOXc2pjDAnfp8bqTR0XUr5vsPcZEjYhTGRu0DU1Wmh2XAmk flQFgYaOYzcro2f4OWCEBEL3Lj76tr2Uf15xo3/YyVPD/c7HHii0tmXqOnTVB7+yFkYHjw2x82Mw Bacz1nrg6wOsGUvqChzE4xxJ6qTS+/HtBsfyWyakQKXtvPAwdoa3pz+rB79pRX3y5eLs0sbTxN+H 4rdq3bxHRc+VWysTs45mNlZZmAnfa9qiQ+ZM8fPuKUMtgBorL2QmltZdtsJgbOkPXxr9QgJmTPZz 7oH+kcOeba5TZF1QqdRo3aXcBxiQdAUyepRfWuA2pdOksMKYjM7Wa8rqQHNd5bmHAwYEah9e0BYs 7f/jO+KuQ5nf5Og7TdA/WQyxF/8A/twJGOnU5bRrC4gebENxmdgxv/ogRCyJwXMg++sxpO+PFL8e xx0QxfR1xtNqDI0Q5kK0oQHWCLzhXHvlzMBtX8TMc2NRbdeeAKH2ARRHM1uuzmy5Svx/X8dV74XF yNiSD5fn0k8vXZXz2ncAwKcFzA/bHi4GvilOKDQ1ErftLdsOAIvnjH5FbBsjJKkscJD/mCva+pEe o71sKVqB0Jh9qaBgaNa6+BZiiraL9vhgto9HZeGxGnUxBgBXG/YSL3OIemco8JwJGAUbEVDT8knM 6U8AgNtHPneObx/cmFJubusCkNKWR5nkbOLzyeafy+CViyZfbLrx4Q+lHxLPDLBfFDtl7WB7OwZ7 0ttJXxyo+vhq9/Oa9MWVmg6y9uLPRXvzQNuVAxXb2HSBT9T8Mf3XfdXVubZ8x22KDMC5AN71qK3D GoT2NAEDzn7T3y44uaH+yIZ2AKBPPTpwEBPUpFfu/6a5uPv3pH01SSyvgOCqo1YUxM2NagtTbe5K U3SQiM06lfP14K/uPlz1deaCrd0qclX/JA9bTmo6m/G0rhn2Svx18sdTC7fPVwB27LC1Q7d/EBUp QhqniR23Vu1Z02K7hwrk3mlofj3QxUEaPcz/lfuFF7a2AX2Ec+b4hnFpPUxLDIHPNLFDWuOehQl7 gqTvvCEKuWw+Wtw5pFkRByNAg+pSHGJpNberzflKykf755wyH5v2zaM3Hrct7VJnd3ZO9H46mAVH wfLO7HMdqbaPbz2W1NrgFTDQT2zHcJjSOPvg+1cXL0g8TvzUx37aRC7/ZmdrO16b2y5yR7Hbtckx Hqx2CH5EDfl6/Defp3y3NiMOAFyWhB3bPGwMu5v5nl4zPuV/d9cucl7fMJtFTxB6cszOnXFvb0uf bSTWKRTOmsh1bj1LEGPosEM+51//OnO2jOk8SDjSo6NJ1ZbXaNLocLy1ozinVpGD26wwlxUNa4GQ Z83AnW2peTgMgCc/yDnZfcF/qR/D5pvQcmxfzU217fDy9jeVD1c4zYxkN7UqkgjNWtXZYj/yjQ9V SR9X3rrarOxpAiZ2TyCC3197b+RaYiiSOQu99oWLej7ttOgqP2uwvbrJkLA1v24hVTrUL9gj9N2j IHXG/S2z434ifpIIl+wfMLKfJ2///OBr2YkKEhvRnD/TDjzOy11bdWxzZVr3n1UXGjeZhWCU1xIV YjWqf5pz0dacRYv+JGq4zbRDlUQ6DOvHu3mu6kvi/yZ67hom43VUxu9ts3XrqZrPU3WT7T2Hh0kd JnpNOqf89v07EwFgwjuOYw+3595sbJri5+zpNmGod/pXZSfvA0CEZPl8/2AAVSQUfn7s8cdoThZo CtbaB/SPHntxzM5Pbq7YnP4qQaRU9PHhaes8wPgzbUkwDNQopR2GunarRtuWoQJX9DgBdyrv/VC+ q9ZqJP7OUG1rgfv4hM1k6x/G1e7KIa4ZG0vUV+dJIib4etF6OoTATK37a/emtlUQf1u1BzcbpfPZ 0ZP93HugvycYtOUloNYMwHn1Dx3RBAjXaw2nysyzI+39/eCNWzIS3IWTB7ADFV1nS3VbAzC41VT1 2f1xnwE2q9TqYeP62L/IxboXfy7+ukxYCGIrz0BnsP7m+wq3q0uPnBm6DV6f9eYbrhw7zvO933EM tVrMOJWGImYYYHCZ7N+nwbNYDBCGMxgcJvUPgiUwW7gTTnkyNTyOGnVWjEpj/lr44e8GajJZKEwq DBEbBBKL1UPBoydfD4OQBcRoLAbzd+YfxGgy0zn8P343QT1kRcl01t+XnB0CzRBO5jJfLhAQNZtN cHcxBsYfRaBgkMEA4wwah/mbUQq1WMwkokeePhFGIQREUQqDRn9xFIfFYiS+lPM8L9PfAcetejMh V3zWyy4mbSnyzbYE/US/vDi3MYqAFtBCorFZtjoKv5GAIhAhQZwnbHKEbJhg3FZM4sUMxFGrAcSY hEj/v7G9obZqEETPEeIKUxlcDu2lOIuZdYQAUllCZvfqAwM79QqFAWSQdDeTV+9qFh1Yeny0XY++ fZjVagUoZMQW1oSwuMLfr14wFAQRmEJj0cgvyoSJQkYTRmH9FoP0KxArDOEYlUmn/VHmK6IHjTBO EXL/X/kk/f309wAIsgW8MenMX92nibWpAQGYFMwKoTSCrYyXCLDuxcvj35eKEqlfcuy1VH0Hsdfk sR0/n3L7FcfnV97uRS968Z8M1NJ8MW/XhqwrCA5Qqcxwr437Rs2UMP8diT960Yv/N/g35oI219QU KqyYLfybRPfxCJf2ut/1ohf/rcARvV5R1VqvgzGxyN1P7szuyQDRi178T6G3GIMNKIqRKf9E0vT/ l8BQDKA8xyn4PxZ4t3teb4L6lwaGYbb6tC/NQFs+duCfaN+LXvTiN1A2bdr076UAsmW86zGjy18E U1f+0bI7An6w5KWscIRG0nZW5DfXtuk1AJnL/2tP1SBDY25DZatWqYcYEi77Vy6iprpTxRdhhp8T +zejDo5aFO01lYraJo2GyuRx6P9Ueu6/Hjjc9aAuoUBncODJn1vh/fGdGAyjwB9k/PzfAwap79Xc qjAicp6M8TfeYCgI45Tf1p+osb61vLKtAaaLBTZD4+/a45aapvvXahs5HOnjPNL/EGy5KjEUAH6X yBPuyK8pbNJ20tn2PboT/jWAYQj4uxbgtlSaTyw//n/Q34v/XPy7J2CwYfedLyvx0L52vD+++V8D dePp+Sn7w9wXBwleZu7EUWte1ldrMo7caSgHGIH9nGR/ZZkDZflPb97dfbshqwH0Gu3t8au3DKS+ /8btT1j2c4dKBb/ejFkV53P3fp158FZtuYtTuI9Q8vQshltqG1Ku5F0u0pHcRTImFX6Uc/x0xflm i5uftMdUTn8fcFjZln05++KDxrychpychtJ2K0UuEDMo/9gjUXPjwaztiZ3YYJcB4hdlIYArig/+ WKQMcnLnvZwD0X8pEGP1rgdbs4z8Ic59BbTHEwaYmPzpxXZJtIvjY4aixsodqd/szz/LkY0Ok9hC dX9rj2lv5+3dkFkU4h4RKBL8gxMw1tH28HTmLS3N0UPI/yXLjjpl3rVPUlrzfNynev6RC+O/CKCx bG/qfiUlKFD0Bz4ooKH+esHhPAPoJvR4vP77/0B/L/6j8S9ctSGgyfxkSBmKoVYIRLDfCnRhuqLv 8g+nKrX/wHNx2AqaYey3JyOI1QKCTxXngyCzGbLl6bB5VP76Ogy2QtbfE0BA4DBiy6B1fcV/PPsS S3gQskJP1hkkkWnuXuOm+PorO0uqTIYX1QjEENBqMFgJ4l9w14vaw7DFaDb+ngCew9AFfaO7NEWl xieKqVGFfdYN2jzG8YkcwiSaqL/fxJk+QXpQ2QlbgWeBmwsaE37I2P7F/WPFBi1qqliTunl7xp4D haXgcwjoboUjkNny/PBBol1t2/1NGdu2Zmzt/veL9cnvx7XWWn+prIYTnWVFkCfbQCarGX3SPkJm yib1WfZW0Gj736eXx1GT1Wi1ecyCIPyYBry1MeFUcZ4Wgp+ipFsAQKQn/tt6BzQTvz3vK4Du7PzE vwAGWm0J7X9risBWKwQ90ZKg32KGMByFjb+JJo6AkMUKE/soC/hbWTniqtFgNlifyIOGWawm6zO1 FfFuT3gYfWEdu+eDwnKaFfbeIv/Bot8Oe9DC4mMXq5t+pZHEkPURcNqsJTrIgsJm8++7hczr6zN7 c8yccIn4qdkXxWALZH1hACmu6ypPKL5dqNb+SjyJ4xfNBwv0eRZbiQDwSQ4CCGwxPdODz3k2BtkY +8T7QdCkNRqsT/YKjFhNMIRikIl4W7d0mbtydxedy2nX/+FLQKMiteJcfGOB7m/98mL6/0Ya0ZGW X39BUcgCgU8JNo5jtviI5yTC68V/Mf7k/QFubbvz6NytZpWLRJymSumEjCsGn33N1xGDTaUVZw8V nMpHMHtm9OKIZSPd3UmmhvT822042qbMTq/QMhkSHxdvQU8nOWZjU+LDPbcNggHu0XTd7csND2my 5V8NnerOsd5P3f9ZfQKGs/yk096NmhtmL0DNLfFZXx9tKmhHyX055Eoocv+rX7uTjdW1V37KPZwP 4STWsBWRb051d2WQSeXZO96rbhzAZAmFo3y8pKil5VrOuQctDQC73xQ/2f2iFB2pU+Tw9rqh/XQd Baezjl5uLwZILtP7LFsYHCVh0o3qR6ceXC20AFwypCa9wLaGdKrzD97ffUtbhwGkEPn8DwbN8xRw n72Z2ORdy734oLURYIXPDHC4U3BPRzaIZItXhTun5R04XJvcjuFk5vBVg5ZOdnOhk4jVw5CFTORG 6kXT745bFXUJmwruMSzt7aRBEY+zY+JIR3tB3KMbNSBNglDoOLH96TGPFj/Mqa9cdOWO+vLDtqWu eFKqsYlJC5nbLwI3tl7J3nOqMf0xAZ8Mf2+kA/nKrU139FYRxzFHk8Kie08KXLEorD/vmQ4kkRku kpBhfNojZtiSsAVA88/7Ku8VdXZMdPEl6wp+Slx91YwCFKfBvu+u7jvQnkHuVGTtzdyZ0tWKcEcN Iem0ZPKkiE8G8bsuPTpzV9UaJI8JkAQKBLawWEjz6Pv4NXEgSiJRSBSvKcGrV4Z5tSlLyrrUINqY W5PZxaALHPoF2XFxxFhaefpgwZk8CCezhn008J3RznIG0Lr/4ueFJP5A76m47vah+vQo93nvRi5x e7Isn8nQlJC+L0mr0KENAM1PgOprQeXk/juWBvWjA5rrybu+b76PA8I+8mkrB8z2E3I7WtL2Z/90 t6sVp1BoZPqU/idXBsoshpabuT+dqk/vIqQEwKL8v17fL0pIVV+69eXu9jxCIzsJBy7pu2qUpzNu ar6R9sVRRYWW5BNBJxsZvBCXxcsiA9VtufuzDiVrakhkr1dDly/uE85+Ju4OMtRG/sG4AAAgAElE QVScyzhb0NkAiKetHzbGjt559NJnBbiILwh5JSDkYeXV7A5FgNPEPna+XC4DQDRF1Zm1MGIylz0o k3LpQje5r4wjHSDxs6OzD6W/cSuXQafxPxx6fJybHQZrUoou3yjLxfhRQS59cMAmvaqqE5/mpkmo dmT8YbrJaZTfm+9FxoiftWzgiF5XX9JSoUY669ryHpRqeEKfIAcZnes9yd5nR2vchriJ39FIoU6T 3um/PEDMRYx1l9I2nlA1GXAyT/LO/lGzXdk9bRUw5YlrG9JBGochfKR9wGUEzQtfNc0vgGqoOP/w m9PKKmI5zGGGbRixbZgjH4O6couPHiy5VoHZssmgtAUnp82TQa1385PaEHNzK6GC2nlcubfcjdOD dQO3WjTlzQUNus4OoDqrLEXBlwd7+PB6pp9ZXXL2UNkDkDd+ZYjwwJ0NORTHMYFffNDHvqj85N6i K5UIQOFM/GzIG8Md7AhKOhV396duuW1BCdGa1ufdJYGhwv8w01AvXh5/9gQMwM2dmXHV8V31wTEy l87WpA8Sb070WlBbfWZ24kY6IOnH9y9VXF1+s+7byV+FdRxdVXwBw6zpDZ8ubKP7yEd8LtwzUNRD 3CqGws3qghN1udfq+W4MOWRqqTeUvh81pOz2zBW1VSP9Pgmit96u3PQFVLt50Dulpbu25Rxl8sYN 5FJO1VyFKA4mFKxqvPxBwi6QP2SSXJZXF7f5Rofktc3DZFKzSdfVdPQ43ZPm/NYrXlLbRKXOiq2J b6PTop3CDtYf18GG2ey52q7CAzdeuwE5j3KbhGhun0hfZAIOrXChTry2orFT6c8bmmdI0uNewHO2 TzhiUSjzilr0Ud4zhJbc6xXfXXMJeitgEP+Z0GdiKU8QcLUmXk2jjnGnEgSYMPQV1iyDSVFWW8pn jxjMR89Xxx4scI+yn+/cXcyARCY/pYaJ3YBZeeN6V+Mg/pJV4b7EtN6pyfz68uLTeqoIZ1Pw+hok oGdCSTQXsb+U7wCoG9IqUgXIUeIalRwW5S63avPKGmr4nBFDeNZzNbH784P7DI1qU1w6qzLwGJIB khhDW+pmdRdI2fJuaJ+nYwlJFDHHLVTsUWjhiAA7M0onNgC2dJjGwuVnZt0291kWOsLUlXkrbRMG rX8/kPttxtaj5WXD3UZTGvfvAY1slkP/0LUoCps0RRkN8dWweFTQeE/bBAw9SH1zV0PV8OAfR7IL Thel1xkNsLHux+ztp1sKNEj5Jyn36SRS/7AbF4Z7VdVf/uDOAUwwaLLcPq8u/uOretarn8bYo53q 7BOahutNt2UUIYS23qOVvWK2PjUBo6ilXvXwhELhwZQCcByD6Y6Yq8+VVbzu751wcdjHStNw7+Vu eFly+fqvga6Po2al5O4+WqZaOPRtV0vhgdwD9d46AOdVKRJ+yo7nuUyZJ2cnFx9q6FASG3Goq+h6 SbaX17S+YjCx+PRxBs/X/s1HGV9uyT/Dlrw6kNx4oDaTRpey+bPbWhP3x69MA/rEOE/UKS/suz8H Z9x4yz+A/qTpkthNN7WnXapPD/bq19RSpGSRm5rOHLHaBTpLx3kFmDsf3W9IrsXcp4SMdAIYUPu9 GQlrOq0GE7T7jYQjQmHMh8O+nOflYFtIAqTaDnC4d2BB7YXP4VuDlizkYLDVpK5UPChS4YOCR4ZL ba+zGpRnak5TqVJHXrgUyT9XfjHKLWycs/gZ+Tc8qDzxfsEJNWgpL1mfUElz99hybtxsGYvoHwqM 4modNUhIvfsowYE/3CvM7mDy+l0V6mlBM52B+lMF65ZZwCMzFjk8q6twWNly9pSOJGI4RArD1Z13 PtKARmDdBHLeyQaNu8PUQSLrntRd6/ARdxdMM3ZknsvdloMPnus/Rl2//1BHkxlFm4t2rC67boUt cVVrMxrp/b3mbhy+sU8PMfl4e9vD0w+3pRg6EOPFDzpv08jDTr++M0oo7oH+Af0gS3tc4/VGJC6h mupE8q3TZ91hl0VQ6rbeuyCSjpjiwEytPPPupc4LS7YEY4XvXX63AA9f4Bfe1p52PGkzCft0aWi/ Htcbvfjvw588AZOZTuN8x15vyeJ7rdwaPfbemYQlqsRK/fTa8osIM+CTmCOvecuq8vcvTfs6vrF4 9IB119j8oBtbxoQe3zM0mAIwxM+ps83hu00b9F5O65Q6+8lfj/omREyDSUw+XDa2trTB6iZCYYuR DFja01sq4/ISqxT39MJVP016N1IqXFM3+u3EFipiyC29kKDvjGJRcRBvQE1luiPxjQsiJHZhQ9Zf cRCE3jzw+EiRwnJdNGx1mkXxEPIKcg0YCFguuhzePTqqpfn8sdZ2uiCQCuKoGdYa6k+VV0e355R0 VL41JGNThOvDou/fvpvwnAIJti2gVBzU174guyFDZS6qs9Q2GbQQigHP7GCoHC+CgJu6mlKAIMCf ICDR/cjusUMwa4ufU1Bxddmd1qpWcwlg1MNPHkPiwG+zv6vvpP08YODllY+z22OIpbopabeWPSV8 +0/Dw7LTPvkou+K5XWiLCiP1E/TLqNmejIg29V/9XXEtgpJYbDs/uW9VXVliS2mrpZJmMMCA9O2x 21Yff3NQ4ImzY/tVVB9ff21Hpbr0UUl1XHGSyoo+/jYazpo64cuBdDKFQi9pu7GiPQHAQC/Pr+Z5 hXZUbDmurqWyBpMsFh1CLjGnCBSBQ+mBtariCRHbt0ZPksEzxu4Z0yj+bKaXPYdk9+bYz1tp1ptd MPbLCR6ZDDNVCHi77ARDGjzIfe5oNw8WT/rFhB/7Y4tX1wcdn7PSj83gcuSgWUEIwF2DLopNCABA CEC5dl984+zB9gOWz92Z8eO0FuHMwzM/8qQjOInKYz6deIHHdxkzcE5OcvwA/1fya+O8Q+YE1H+3 trW0U+u4taZUSY3kIwhkxRGz6nZ95WhPLWrVWNGH3+YJ5gu8Brl9+oqXS/dJuRWyliQ2A7Ax2pc/ Z7hfPy6NSmd5jfYblND66Iays0Zf625SdqjrbnaUFfNXpU59P0IEuOxz+AaPeWtgUG3VnjPKLpkd m2wFKBZQY6g9UFSz0MeP/uTqiyH0X9x35j2tZagX92jca8eRNTdHrD2YfuXDkcuinNjhdpvqE02Z 1l/Oz+kOk3PeDtq+b+B1ydYbMybxyHQh+zebxYqYvVsjQ47vP/O1PqMVWujPkI4ZuFJM0a7JUiF/ O0F1CVu2JW3jPvrEkws/U5bu2p3XBMNPmhIeyz9NOCp8zQUae0NycsTA9W8H+XIZIvHfEqsJWPaf TzoVQ0nbcG1jg7GhurYktjmzFgnGLWaExilAGmWq3WltM2Y5P5MQg+L87qTvNp7bHBVy7NSIwPyS nz+6dbqqs2aCd8Cr8sC7TakXlXAhYHFEiN0liYRTQYRWonl0DWaGcoesCx/pzGByB+24zBKNuHdh TuSxz/r70iksYU+ZrQhJc3YbvWbSHs2dde1207cMWuYhEItYfHJP9OvRSP/wpRurjq2oK3k9unxF iAuGWsymthN3d903GcZBAA6Rq1Bdte6HGw3vMjp+vtjVYs8bAljhDgQtMcaltkRP8Qnx6rUo/2/g T3dRIdNshdkpMrGIx+IwbCeyLDqN0D4wjcrksUUsOpvHYNDJGIpgZCrbUSAlAWQJx1nOlSEocRGl 9uQ1Q7KV+WbTSV5eDqMDnWSP/bVQEAJtisDb3cFXRvJ1l/V5DeC4s6DSJpRE4xAvYtBYrn5vnnPQ MqhIBgSjFK5I6OUllX1ot7alQxfm7MWkkClkJofOsmXfe+wQRCKzJP3ec/TIz9y14gTnAeRxffws Ng1GbMXVuWK2j7vUi+ew0s/1FaZ8gEhdRjRwJa6wWA5iV4FtK9qzK6RJX38hafHPepf3+m0IsKZ/ mb+fSqZ3V0R49lNtBKx1dF6Wt+uNI5wUgoBR01gky53SPVNz42cEb9joLTydtbWaYqtm8UsTWw55 4lm/hVWSyTQWjUUmrlEfX8MxDIWoTDZbaseUihl8JolFJeb+Hg+6ECuAycaGjYKKdv0MvflWX8dv io7UqNo6VHtmF9ybEfThZ14LTmVvr6VQiX0t1v0J9hQGm8agkWjE9gvHDV1aY6KyglhdCLufnw3L p1FtNWOIFw73W7TcKfRQ7pflXe0ICkMgRGhrBsfXV+bpa+cWbjeUIfBxYFZjGA5aIUKQyLBZZ+tp CmY72ycxqCw68bHElPNLdBU1NHLdUk0Kn2MtaL99oqW2mNIil+70Y9nZM1g0lGTHsXMWCBCr0Wqz EcIolf+rADSqdP2cvQhBZbDYdDJLKB4YKuQ9z62L6CkalUEnUai26gHEowUE+3AKi4qAoC2thI+H g489ycfbaQhGd+wvdYcDF7SRIiGwK0+5946VckkvK1++0MV+yOtha6N0FkXXrbOqqt0KqGTFp5rE 6W9V1r4beXalHDmW1lZDIuQHR4h/QAgmU+l02MYgCo3gM4xCCM4X8WwSyJFvCtI0cj2Cmc8WVCZR ZPJADtd85eGeYqPCih3YkFzO4awIlvKIR5OpLNpjBj4WHmLG5TjZ0YhFEk3Ol3NQGMWIYWmrQE/8 7iiyY9NZ3fmWmHTboCRRqSwmlUkhUel/6wAb/0gE0SIJi2ugczjE5Z4D30g0Gk/CEnFJJB6N5yRw IoNmDMCIu4nhTqVQ5EI7hoVOPJlKfCyKEHTgLDcvqbs9hXZqxJE2HSNM3GM9RjJGso0EO5sEMm0S iFpwrPHk3Z0/1WhWjNw2xZHhdiHtFonBAEhMcdD4oE/o9fUWuDxOGd/ctFfsWvOmu5ejQEYl0yQc JzlPBiEoAUpPCfXIZCYx0fLpLJhjLxO6SZmIzWRLpz5LP9EnFBKLZUvUNX1qhH/3qoFDsXYQAohR RVKxp6dU/KXdlnqlfqhcYm2GEBKVwfPxkXn42LkPlU2yd4qQMHs9B/9X8Gf3NKJKrrpVoqrNz47v C9X80AkCwKl9aYtmewxprdr35a1l9S4BiY2XcyzSV53dWFQKUxY2DEAu5HzCVwoKm05y/VZ/Nepr f85TYxjXaosP3N192FTrW7ZznbI4us8rU/tEiASB83nCPDiuTD3VWUbPrr/8COS+N3i1ozxEVfjZ Z/EdM53dMoo2XkMG3F1+w9N/DLd2t8XcaMHEGmXywXr1hvAJiDbri1vn29TxOqvqeOYmQDlgZOi0 GHfHsJClTtW5ycqSvl5XJsgIFpHtxX3GsPTp1pxOsD8Na75WcZgJSje5+/LorHVXZhjDY3KKPy+G MZniSFFnn3DJ08oCQQ16YwsFkJtMTQWqzA5Lx86sW2M9wkfJ7HpSV4zI8PedGlckKUvDvS6PllJx xOamISGTJKihsqkyr0uZbYm9q5gw35N56vLOfHNDHNrpWLP7owtlMcGTxruRr2ffTCu/0qprLyz/ bk2Xu7//wrGSoGHwt1kF721UDc1QJhbAVSczE8c5eMjZTx74Q6o7BcdzG68pgeBt02+v5QHXLy6G EPhaZtxEF8yeQiYIKGsosRGguHA3dPDM7gOLq3kTxjVPQ3VnHvBGrJMMGtM3cOLg1U92IFhZlXqt /H4Bh1brNmeR+4jNRT/OOGPZFTNaQD+Im3M6IG8RXB9bdY/nPXdoZKSDNPBM8dKy+v1NpiIjsaGn ARTEWFx580TmtfvqhyVY47YbhkjPqe8OirwWu+iEbuSefmvG+PvQEteSATrefQ6AAXQyvHvDDVKI tWqXOuejUckx/mM4tfsIAYAwUYcyeV9d55b+E2DNg42Xd1zFdI61296/kDPQb+KU0PBnfWGNBkVi 9oVT6jZ1dQEAPrpXKsIRLWI4mQK/uoTH2wolVWlGSUVIdu2Famqw3MmtuPTEgXb59pHvTjfLkhJ2 MFlUDLM0qFJ+rkzyD1v9bkiQKmNHpoWKkaBOXQ3FlqK0s7q1vEpbfd/oEOeNTZP4FDTvn3A4Ixot eYgCEj4xx7M8RP4xLHWZqUgLB+KGyovlx+wo/Sb5uD+bzZ/Gcx3NEGzS3xsRenSGdtkbTdQQhwFy sjanMPZc9vWUzkdFgHbztba+njPWDB7KoJJwzKJo/2TlqYJOTWqraPhXgxaXF11r0qmOZ12LtEp2 ayEd4/yJ7AWLHQ2XH14v6sxs0HeeStmUkRv11oR5/MbjxA0dnHMHk4OQ9pTr7c2SytQQu8lunB42 cMRaBUBSLuVuVJVIYtuTI/qdOdKPuyvzgp4qOfrg5Ch2wT1zhaQ27hWHOfZ2XozGEqU1wp0P3S09 lgBEjaPO7WGgdMMKt53NmayoGWTQxxUJZ70qCLQqrsEkERkzFFWkPYRRXftP50v7DmFkn8zcaXJZ +sHAqd7ZG3Y05uGYjXUiWVgw2HEy41NTpTWzNa5PxI4Ng951ZfawOCWRMBoZe1h+bXNnXV1bXB7+ dvGSkc/Sn+8TwmyOW9XUqsYKPz+2xp0qmj5+bRRf5u45mNNyzWBuQzBuU9PN3Y1w/1GL+4XP5efH 42aiW12pxpLzVXkRApeRvVHW/zP4k8OQUFCT21ZQC0Ekmqsfi1yKdNlzpAh/zMroGUMYlOqO+ym6 MjMtbN3w7+b7hXJpxBZN4mjpyDbn11rb+OLRb4R+ECmXPLMowHWG8sTiCyDXgUbDW9FaqTQ0wsGf Q2X3D53pqTecUV5KbnugItmNC3xveuig0Y6h7lDnI01mcke+kh61btC2UW7ObsKAsTxWccula8q0 AkvbYM/XXgscyLfWflx8QEmjOnCEbGq7CqN62EWGScVUttRNW9gMu2ya9IG37VScxGHL+7pGGtRl F1tvPNAUcwVTlka/1t932EQWL7UrrVhbpeOGyzlsR2Hfvg6Rbrynzdg0KofJsM9vy8zUZGIc/2Ce Gx1nDvYd4sl71mPJBipHThBQA7ltnbza23aOQGYBsLU99b42pwZmRAqDhIxWT+cxYQJabNbXyZjW gSvhMA2NKCC1ixggxC7WXk0yNvE5dg4MbQPcQOeMf7XPoGCepF6V88BcY6XS5TwHK7Xv9IC+oidD gVFIk6QqKraYLbjnuNARPjz4Wt4JHUfGYftOCQjHVMnpupwGVNhf6M+hN3q7jAkmNX1TfNOO7REu Epl44zcMXrskJOhZ3YVjcGtHYYqmhcyQ+TpGzgkfg4LaRkt+mP/KPX3HWRUXzirvp2lKhOKQRcFz w5z9x7sO6UfzkrIC57iG325JkdrPWxrkXt6a/HNLCsbkObAAHd6iJ/tP8grQKZLyAFWW4ubt1gKG ZOTroWsGONoRexIJz0WlbS4hNDBunOrx2dsDRoZIg4azsHLF9SvKdEIAxngvnhUQwbJUbay87MCV chhQk1UnEoREOXs9Qz9uMTcXVpxqY7j58b34TEyHid15UgNFH+b2+lsj3+J3Nl9UXk1pz+qiuM4M XTba3aFM8UhhKkhpjI1VlLuJRmwZ/k4fIUOlq89pTavWpsc1Z1lJbh8NXD7K2cPFPqRCUZiry6yy mvo6jLLDET/nITOjFsUIQn1o8j4+r3iqr5eQI+ZHTPG38wqVhzepsq4p4jK0FSLRax8MneHGYfYQ vUphouqCStC6cPAn4yUOd7rUowPfnOTAyW5JPK58SGIJHFioBms2UEKm+wbRKUwJT17ZXlIONtA4 /otDlg6V0WPbCzuJfTfFOYAFPYK6JBxnNj+iL7ftWvnpIjLC5tJ0eFsDKBgROJiuSrxqNEg5ziKq AwOtN1MhV4l/P4cQ+x4KxZM5TAmKwmVdJeVoR6hs3sroaXK0dntLsZQt51HlQpq+BUcoTL9I70mr AobZ61Ovt96OV2a0UKjv9F03zLUHE7BtZafO+Kbkjozt5iuU4qIp22PWzA7o4wyQ6y159xS3Hxoc Zrv3awfUEsHQ/hK0WpX2yFwSXx9fCEEjvLctCYsS0GhkqohnbM4159fDWheH2W+EvREkEfR4FsJk iyWopU2TVwg2g5yBnwxbMoCp/qa15Cn6I5z9NK3xNaBBxHXoRBtagebBPvO9+Hx/SVA0A8xsuXpD mV4Maab4vzPLvw+H5zdX5t6puHxBmZqhq/KSD5sfPMVL2LNa6MV/H/7KTFg4gtgOHWl0Bp1KfeI6 bEEACp32krkoQVtUEk6jsxi/nchhIGiLSmCyWL+rmP0LAWQag0H9o9QfGGJGABb9CS8pDEVAGMRI VCad/mt8JA6bTQiJzWL9AfE4DiO22vQM2gvqcD9BgO2xvys6gRJvRxAajdFjCbO/54kwAkLdhRBe LmcAgsAQihLd9Jh3KKi4mPrZnIeHY/x2bhgYFeEc/XJqA8cRi8WK23qF8Zjd5s7c1NY6C4VmVGV+ kfbNhJHlPw7277GtLZ4HoFNwW/wRjcZkPHEkC1sghEKm0387UfxNAJjUniupvxT9OARZYByg05jd hUYI2YMACgnDMARBGGxet1ERR20nq7a6XgiMUOkEqb+IFo5ChPgy6L/VgcBAZXJNTheK0+CW07ff LbX/KuH1da7dI4aYwEAYwm0mBtqLslFhICG9TFvFCJLZYqT9QZkQHMMhEMZpFIJV/2rNj8IIMViJ N1H/qJYAZrGYEWK8PL9MBWptOn1v/Vt5t0b6fbFh4JBQeRjnb4/EYLMZs9XZ/lXR2MxgKIIBJAwh GEj/PQNxnOgpKzGuadQ/zsWD2kYB9ofVRJ4DHIZtwXJUQln9TgNhGGyxgiQKoRnpf5dy6MV/C3pT UfbiJWFtT3g1bpcRhQm14igO3jrlR7c/yaChqt69OedGqZFQlEx7gWzdyJ/792wC/O8ErC/cmLIz u60BxUk8nnRSyPZlwT0UDeyFRXF5UtweoNsRIdgl5qORG5x7jae9+I9C7wTci5cEBmkqFS2oTf3h VLqdh1z+Z1UyQyF9S2erxmzBqFw3qafdSxca/A8FDnWom5UGPYyT7STubkLBHzf5nwQGdpQpFACZ QqgwNlvmYm/fW1ypF/9Z+GsnYNyWCr43Re/L43+egRiK2Yox/O8yoBe96MV/D/7CXNC4paohYVfm XZDl5tVTEqg/aG0z4UDo77PG/7uhb8+PL82oVFtdHOR//tIb0ZXWPkivzK5QKmgcRzGTRjCwuPrq npxUCs/Tlcd+OQZifwkDMRS0ojiVTHlpOytky2v4dIJ8zNp2pejQ3XaNp9jrvyn3PYbCRMcQ34rj mC3V/7+bnhcAtnSW12akV+dVqrQ8oZRPoxIreBCyApSX9Uz41wBDrRYUoP4Tsg6CFpxMfXkJfnmg bc15D6qyGiG+q4DXW3fqvxt/4eEeBjWqC84XPeLLh49xkf2D6hPr7Mg5kHSU6bt8Zf/Qv/hEErS2 30zZdVRtjXboNyd6Ft4ce6rkQZMZiBTov6+5R2GM8g34OeBPnoEtD1M/Xlea3GSxUKniudRrm8M9 CAbWtueeL6pycR8zWN5j/NILgKkU947cvygJXvVGSOC/mIFwbsZnuxocv5z2ljv3H14o2AA1/5z4 eQ1n3vYhMazfTbQY3JXffKeEap3oM1bK+OtqXlhMypSMvZfUwKCA6a+FhEPKB3tyr9QbxMsmrI4Q sf+5Z0OPcn76oPQahttqLIa6Tn038j0f7v/TI3ccajuRv/fHnHM6ECSR2V/bx892c7fqsz+++YNv 2DfvBjn/uwn8FWDG/Q+2Kfofmz3fnv5SGS3Auh/iPm2VrvthcOifTdsfAqks+3l76R2h36EBLg7U p9Pc9eK/Cv+qoW42mxlMBgU16zE2/7GuJHP7+y48bf+Ko53XUzKFYbDZamWyeS+gBoH0dapSlryH EgIwZAJR8hN+yBhosEI0OoeG6kGa8J/M6wZDncXlPyUYMD3JOAaejSoz4ysPFiGAbOyx6XXn9xph 3Ja0Hqaz2dQnWpmsOJXHeNIwisNmEKJSGPQXV+nBNCkt+fmWsZdeW+jAYIq5jraLZO7goGWnnS0u UtdnB2V3LQELRmGxu5MmwDaKcD6LbTBqOTwRcT9k1RAMNLuDf+dXWyx6hMTiMWlEV7LZv0wzMLFX Q1AG9Sl3WRxFzBaYymX98rEGbXmeCgfRpzNzwjBosppJdA73d96exBbKbDGQaFy6zXEYo9PpmLn1 liLTKhmPPWkfobDd3hi43UwWOj3B6e5c9hYjTuOyaL+5wZtMRoDG5fwdJSYxxGqwWMlUBuc5ruyg RZlbtvusDlBQkUgPb3XZmQslJ2sQ6ljrOxEAm3i70ayDARqHxX3Sjx/SGkE2l/eCtZm+4eKr97d1 QGiUoF+NOgmm+WqtENA9AaOIrZgDm83pQQF3izeTyaG9sNwzBBmtOJ3P6OH9ZrMBt8nri1xuLRad iSCAJ/p1+OBQZ1NnEcQds3X0nGAxx0Ukt93WVXxRkfe6N/TMA1BCcnAar4eQ4L+P/sdArFozzuGz fnkKglhBFGfSGL+Wurb1PmhCSHQGmYTgKJPOIgEkfVdJtsoNfca+ZqsmYrFSmFwunfZ0tgEUskIQ mcpi0CiYsf6aIkNAN/4heY8pQBAYJ5MpPeXhwVGTwQpwOU8nN/g9MAw1W80UGocKoABACu87L6jh QQOO2ETIjAvZvy3ynke/LUADspJo7N8501u0ZpjH5T8lPwQDrSjOeoKBqBU0YyRbSCIxYhl0Ru+m +y/DnzsBow3V8T+mHCu1lFSAbV6CsbA2uRhDds6sWuzOSC848u39G7hw4MLBi6b7+RAvVpb9vOju OTbJw45y9ZJONsjjw/2TZylKz+7O2MXx+XhjmNummzsqjML1cw8NY7VklqfWg51MZdqt7A6B0Kev mxefQYir6nrsZ4srz+M4t4988Vej1wx2FHc0p2658/Hl9nITiUTC8UXDC3cNcPtnvorNdp02YuPF xPNCwfDK4issTv8Aub8RnbwocHBOAcWoPz3gh6tksmyQ14f7Jy5xYZJhQ+WZpFVbajLVKEASfZo2 Z7ULWnvy5kdXDTQOoqw1l3Ht3vphyscRUrseF7eWrqrYnDPHVc0mK/N+TkVck00AACAASURBVJKr w/jXBzEwWPOg8MS392NxYfSyEW+O9XC39RxWv3nvgmSMOTZ0tUB/YX3p9cFer38V84mp5szKzN1V 1s5uBgxOe/+aJ1SXWZVJMFDfknoru1Uo9g9zceczeu79X+ivzlRjpKFcIA8em7z8nCeuSc/+dlv2 /mwEd+ZM3jBm0xRv55Rri7cpTWIK1ahPbmSFL4va8V5/n7aWvGyVwgCRk4tv19Fodq7DIuUCFNTk FP70SeqOfFumQqel0d+sGzBWxKCC7anrz089bMIFFJIDTRoS8OGmqIl1RUmNOjUGZyUWscgIKzxs uAuDou0o3puy66qiMcp1+vJhiwLFXLTzwYdnP88ne/e3Rw7VXvKXxXwz5vBQJzFsqDmTsHJL3UM1 7jeUQdMymIN8vvhi9KCeJkIk8/7nqzJ/qiQUNdX31f7btw4eYf8MVwQCj+jB71lit+ar6gqbC6u1 dQ2wYXTfY2Pt+MbW+GXn596EiPb8AW6Lvx2zTth5e1va4XbMVWK+edWip9FnHn/1+9FO/B5Z3Vx1 p8FinhJy8eTIPjezt+2pM6ssILHTf/Bw7/LcnxutWhJp6MEZP8/0duhQZh6/u/22xWdW0CBl7e7j rXl2bvu+FOVtLq9wYJBHhS/HWy9fam3wdx63bNjbftTGfbELvlPU6TGAJ918d/YKT2pn/MM9ux/l hgRO9EMr99VcroNH3l72c5SgB/dya2fej/Hv/tBaZsQBNj1q//RzUz2EWk1dUsaZtLpqEgUoLU2l +E/1kVCN7YWXM27qYGNl/Z04qrtQ6NbHzZdPJbdUxm69+/ElvQIhkVZH31wzdKC1J/oTZ84SPrsS xVQX4r88Wp0XEPTRNHrW1Iy9DoLAbybET5BZ0x9991nWwUIIIPHmH5r46TQ3OQVr23N2+caWZMCW KEO2IOrzT6MnaZsyc9QdIFSckJ/gQKZIXYeEO/ARqyox48ttuSdKbDWHXNePPLwirB+HXPvZvtez qfJRAfOMHSd21SRPDt7wUehUZXm8wqQzttyPL9ADOC8kMNrpOScukKFsz/X3t7RmA4DdUPd3voh5 I0zKKcr6YXPuLatw/jfRkk0XF6XS3WeGH/5xWL8e52BVw6WNN966YMZlNBKT5DolesuH4UFyOvt0 6TejSudXk+hTgo//OGE0syf6GV33lp3e3MoOdOF1XWhKiHaf99XIr8Ls+S2Vl9cmfZpgaMO5r47B W01MwbJRP4yXo0kZX2zLP/OYgeembx4lF6Ng/a4LK7cp0mykkJyWD932QeTUf6LyaC/+MfzJhjQS ANdbCxItklB6UFF7LF80yQ3UXqhqIH5hkplUXJvTXlhD7Ay7b8ZQIMuQdV1z5hIydxKfnd12+kZ9 G4DUVBsrC7R6YvtINuY90J9pMhhKq09Mf/hlMlhxq/qjqfGTF6SfrjKYif3DmUN+0woPLA8/eGzg CpH6yw+SVmSpam8U/3ypmbFiyPnrw7ZEo5AFNP2TH0Wm0kT27uEMipc5+0zGa2ea7klg2ng3PynT lgYBJ5Ep3CUzhOzsltM3ahWAtf77hFUfllkXhh86NvCLvm1rB+7b2IgAZkyT3HGlGkfCeb6dyu/i GvP0cM/ubyZt2aGaU1VmJY6nflWyfl1JmW3OwgGCgSSsnWBgoxn8pSVOF1IN97vurk+ZtbmkNIjh WKvX1LVk7Kk+mwON3j/x+o8eY3WgEMDNBANfzd5JMPBi+fsEAxc9uNrNwJ7wmP6i2y7ixes958Z2 avUgBYa67hTsjLm3vY0WvFT+Ch1MmnNu0ZXGBgqF/KAz9l5XspNshovh3s3aneUtpTuyNq9veaSA rq+4O3NiwtQ1edWAbROpedTagtitPBBz6C2Z+Ej6tWJtF6Z/OH7fsN1acJLzB1OlQ7J1VjNCVrfE 7yg5WG7uqFTveOXm5GkJo261dW9ESHQ7oKvTcPd+V70B6k44TCO1G7Pudxw+VN3yqny0qqX6bHmB FVEeTVyzsSzeRbp0vZN9rP5BpibLAtCeo1KsFTU5DrIPj4w6vsJBdLfy8N0G5bM3kagsJ77nQEJX dtXfzrtxr73JQAiflVi/kFpqEm8Bk7YNPrUzdFpTze3T5cUIhV5lrb6i2HcQH/22yxSl4djCC6/m G3uuNMfkMFDMfKdk8euXDhjIY74fu3mMCyP97jtv3l/fx/Xd86P2LmbFLr0Wdbahi0yiaFB1kmLH 0juvXNZgYpxZqGq1kPF0/c1E4yMNAhksmXe78utgiGIp3xy79NMmx5VRJ05Er/doXjv11M4mmEQD 8C6wcEfuu2+XP2LjKABVqKw9H4d0thVc1rsu7Hvw1tgffQxpK+OvGwDMqM++UbntnrasvPP69rL1 p6vLLAhan/f521XXLXDrlcplk26OW5f7Q5URVlafnXF7eR558uHRZ752mbQtfeYbd3J6pN/Yc11O KpsCFpvydj6cNiwlbowgRGXuKlY3JuV9/9a9m06uWw8O/n4yEr/4+Ed5Bouh/sLK+hSZ/VfXxu2b IQiBMBaqL/ko7ePP28oN0KnXb0+dlDjn06I6W08b29NVJrb8w+Mjfp4vpm25c6nGTMgVnUPR3lZd +ihlwam6Fh+6tEKnKa04t7H0OLH6KVZ9OuH6hHl3591pf44OQZu/+D7ok4asfnaLXrP3yq34cM29 rYUakEqhFJoL4mreCDo5rYM/lm/qKursePaIwAZt8vTjsy6Y2LNcVkXww4oMkAUh4d2ZQhHrPVen pZPJytjyt9LboZ7pp5OU+tSEtlO3FeYpkqiimqL4hqpO5f+xd92BURTff/d2r/fLXXLpvUJCSCGE GlpEEaUJdrGjX7GhYu8iih0rioJioSO995AAKaS3S7ma6/1ub/tvL6BSgopf9ev3++ND/iCT2d03 b2bemzfz5r3t1+9/4ns7NTf72dm+ZWuc2+qC9TjlZBh4X0UFw8AvRr3JMHDa52EGWrvXLNTWpsUu WT/x3avEgzCKN3CE2sv4a/DnWsBQYtromWmlIm/O3FhCcyLmxRsXdy5f8ZSpxQ8XFxfc8yYffnzX jz/Xjs2d+8mxhfPcVx+89x1Q96Vt2xoeICzOuTmr53gbSUKi4ieGXf/53vdAFndYwfMGZf7CdW/y 8xe/MapECLE5MBvwnfjYxci1fNzb2UI6aUJg8KINjqAC4ouh4y9XLpouyUqKfWJ6WjwNnBlUFEWS NB2OAH1prg2wmB0jx4+/19aVzismNJs2oLYHcyWn93DE3JkH7nkd1q10bvuOBwB206njdo0dTLA5 2jq5+AlYwAa+agg8MnX0nZstcMmwd5+O6rp373MeDOvPSjuAXlAmT9t9V95z385+xzG1Zf6Tiac3 sTkKhoGvs/zPHDwE/DxFoNgH715V8WrRqcjHN899KY3LNI4mPdU/tvB56Ir39xmHSOMeyR8jgYS5 Bc93iVOe3/KpuuSdp4uHCmEOBxq460/TL4p5+dOZj2TKRfd0j7xnrx7C3IaeAzkxM1+e+Nm05Ii5 VW/ccHjxAb3uo6ueurn+u6rkVcuvyV+xu+9LP4GJhyydtWHy5jkPd6V9O/eFbCGPzw3HdoS50oLY wnbrge9OVtcHepy8XJDF6mpcewAARmbvXDVrDBGyTjqxoY2KS8i5YoU85qofHyAVz26fNpsLhKOI MW+QKTPvvupNI5feYP+p9ZIRL5beuKFi9avTv5slqeP+cIsN7TG5FIcRpz7i8Q3XPFUYAUs+ED+B XPOvsmEDK2CKTsoqj2qo+uLoIVvoCCideZF8Voy+IiLFQ2bwFFU976hj59wqRC3M2gugpHHj7u/a uK/2Yz1l6WRzATYck1r+TGKmyZ33xdwlpTLFqB96r9c1Ver0Im7dZ7u/6QNOW5wILZq8aMZNiYWP L+vjftr1za6+9zbrkcS2694Zc3+V22kg0oqD1gYjgKFCkoK2d/XdMKHojmG3t1qOw+kvvTlhQbKI RbKYVQV4BO+e0VqToEgIuXPGZox7fvzDMtvXlW6dH1BYbM0AO1gLQ5HE6hr3vFklt7VgXbhRtrj8 uUnxkSTO4gyc9o7mRwy+K7rjQPs3r2uIE4xdKeCAABSXdMPyuwbH7X9aJ7jy5ZF3p/TvLCsnb2qN erl4z6o7R6x9vSSLBUBcNnawaovba+iWOxv1zSwKhWmyo3c/OuGJAekf4PusiKvLn57be+h9a+6B R9cWiQAMxwh/1/s7jnYCYIbP2MMW1NIwCW3Yo3stWyzkA0G75aX3Kq+Mlw4eGZUqVORunrt/w9op dxsmVdy7IA6GeDxB+KYcP6IsJtfTUvXlyWO1PmMgnIiJaVbi/FuXHXlrqjnhiXU3LIznhNdJjHwo T08f++OCiPjlu68dRxCAgDvwDTu/du8iUJAQ98nmuTey/Z0J+xc83dxe2We8q+iBtztX3KnxvzRN d3+umqYwisUZcAS21XxVw1Zfm7/p8yuLMV/3+GPbKUEkDAIIw4aYTz+bfUfnAc3mxqogjsKyAeiH peNfHD67rrXl1alfl2IbiK2LbGifztKDhrz3jV29aPQ43rhhDe/PDKoWjZX4Pjt+tAcAc3zGbjaf YSAAfb9H9/xtXIaBDr3h5Y/8E+PkQ0YoE8Kpyi4r4b8Lf/IZMI4hXhxxYUFPOGM5syoPEWE5FULR IIa4bQFfiMRDQYfV7ZCLpGzSbSfCcYQCiJ+FYhiFe/AAQkE8AMLJgN1vdTiNzDttSIgExRAk4AH+ EGLyBJ0WxAbx4+NZrP5w/7JoVTgkrloeN47iF6miYXL0VSkyAZtvtq9eruv6bm204eF7ReEYPO6m rgNHDeZBmeXDYlMEl+AgyRi5bC5PxAXy5wyb57N+8UmTJoovB7DgafqRUAAKH8DiXjyIMxODxQbY ijhlUhqf92npKzUmOj+C69O6RQJBrEBA86QwTxxEUfQiCpgiQi7EGSRxGkTdbjNfqFSJBCSBePxu W9DPMBAJ2K3uCIVYxgNQq9vqBiFYEC9ALV5ALOULIEHcFZHjpfRwARTaYPihTfepX1mwbGR6WBAB /iBiZhhoDlphQUKKLOLCcFAgxGXox0hrn88WxUZ9opyHJmSp2CyYLcDJoBOx2r2EKeQMMXoRgoN+ hwsAClSqIElyJGrcHUBwnGSF40xBRJ8r6PKD7E5rszJiEGLe/tyO58DkeY+MGNPasGhpXzCIICAU TqsRJHQmr5MHEGmpw9I4SiEzYPgSMcxxU6gn6GUTllY7kKXOZRM+p9vsDQVCJGL1Wa0iKIIP24Ou 8BkWhHpDXi9JYQSK05QMgnhIb52tQ4wH2tDw5gF6kTSRIf3a8fueS4hZ9NXYvMbO2BUGv48IMV16 HlsoikBCfoqrzE0YqhKh8YkjzC3NJtwXQNueXXXtj4LZ7098WuDa/t7JPRgaYLRFf24qd5tNn0h6 OgIBmCWJFHBBCgH4QQhShuOUEoCPL2SB1P5NNy7wzKy8p1Psa1qy+/EPbZZTLhvzdRgQKeTJqQp1 YsRH8Zb2rORIHA/aA14PlTJIlkAQbjcml3BBRk4WjHi4tGnGfRvnJsLQlDGPDVHxvE4ByJi7XFWi KjmOA39U8orGJ8lTsH1BpzeEJCszpBDtCoRk/Iu4j1GW7w48/VqH96EJL5dH4IqNBw8QzDzGeDDl 8buY/sUwxOaxyiGllMtl5pCUaVw4yFrA7e9zIQ6eIIKxYFkseIQ0OkuVxlLGLZaleSVjpWRQNxD9 AxGAuv0OB0mQwvRIos/sFagkUhKEWRAfgPEIeUJqZOQz0odqjZ5xMUoBXPBAzAxCmOFC6lZr1+5F LULxy1MThHwYZmF6Z8AthfFOm0sdkWbu3fD8gfciM+59KLfw+Mnn33H6A0iIFrAsXpsX4rF50XDI 6gPEEl54hSQUKsQsmKYQd8CDIEYnyc6MGnRhnmAWh6MAKJK2mt12AWL3oAEhW8aDoWDQZcQYxT1q UCxtdlklYtXF3FAgWEbThB/Xm72pMA0X54wQiGIA3IZSRJEiIoSHXEE3I2ICiKvRvflC+gERMwXc AEhTIOJB/QGKQvEQydjFIKy11bfb4lDbCQtAi0gMB9n9DGQxDEzrZ+BJfZiBMrrwX7HXUYJkc6D6 u541B3CvTPLk+Gj5wORexp+NP/caEmXo3f9J7crNdjqFDde5d/qCKWLkwEFfX2ZEzu79i9f2VDS6 24yerlO9lqioDNi4+YmG7RZSQ+GD3Pr1X/Y1g5C6KKmA7ajZ2VOtt9dv79mnIwI1zrS7CgtZiPl4 xzcHbXVNmmPLqpe3U+mjk4YorRW1vlMElCyCnCe1e5oCeH78kHbNV0t7NKlJJcMjxDtNnekxs+/I G8RhBL2r9bMjTz1Vv4oWDiqOzpWf74TxKwABgtQYTunYcfNKbk30t5wwouVDp6ttuxcy9FMaHpVr 0a75vK+VBceOTBnmCRm0tk4RV8oFnCc61+xFlDOyMg8eXvSJRQMSQMByap/2SL2NNzKjNFkkvFAE +Wx1n+57/3P9SXeoo8/UVueOnpAeb++r/HzHG+t6jzV5Og3urpoec2LcYGWoYcGaResCnXiwp8uk dWCyQXFJoOfUkrqPmjDJyMzhuYRrjxuZmn1vWYwk4Nef7Fq911rf0Hnko+ovNFTG+Pg0/gWhB/lc Xqe7p0n7bYPFbrLULN/7r68N3muGTufQnm0dexoMdVrT8U87DyHc3HnDZzmqljxnabZ4ArEwvatu 1XE3Ei0tKIiNcxuO7jOuP2421zZ8/VLdapFiWg7XvKej0s1RCQlXo6W5zdeEsHKnDhpaqa8yGFe0 2Ynm7rUfVXxogmJLE4eKuZBRs3+rttJga9145N6V2p7hadfYeta/tveTo33V7QGrsa+p2yscpvC9 seOFGpywuVUCtHqF9qAF56ZFjh/NY+T3odWt1aea1hwI2VBW7t2lMy882WWAB9pXNWyS8zLkQF+d vqHK1cMTJpTG50rOdaYJ+Ho3HV70gVEjV0x8pnxRsvfE+5qdlXbz8JSxhu6tp4joNAmrw3iq3tPi IIWDogZT5m3bLTs3d5s07d9/7nQUx985b9gVKarc8vybpw+ZOpX5GTpzVk6elM1qOvXUt8Y97VYO DDiabR02OGVm3rQiyN5pr7CRMqWQpdHv32lqTEyYHkvUvntw6QZvo8ela9I0kIKMbGUkm8UsllRK 36nvjJXRcVc8MXJuIh8W8Pmtzi69tUPKl3MB29GODafohKvT0o+f/GhZ636Ny9SjresNKQer40QD egKSwVPd+47Yg7FymdnYdNLdpkd00dKyJEi3av+b63Q1Pa6+Tm1NkJ05SKXiMNYiTFZVf7fP0tLZ veHLE2/bOFnF0Vm9Lo3RQyikEp+3catmq41fNkJsWDoQ/Rd+n/C1fbH/s4/1lb5Qp8HSfkyLj8zJ l7BhN+FtMDZwAEjIxtv0u7bb0elFU2XWjXNOfJGknjAmPp7y2UOC3Clpo5PEbJP24DbTD3Vmx/G6 LxY3bVerpiSA+p2aWowXwSjaeltru/cUziosl+sfWf/21kA7GujuNBn9tCInOp6x92EOpGvfvbr3 mM3W8t3hB9ab+kZlXhfFuSDvhUBBaPY02nbVmtz13VsO6JpGZ826MaegvW7Z4617LESbUW8+0Xlc nTAhUTiwqSOTyrZ37tKZ1nfYA9WtKz888Q0hTueaDi3t3FNlCRSoInYdermKhGgiLVcJHek+n/6r op3PbHrmFMH2+0RB3/H1pqMWLKIkYRRC2U71bjzQ2bCqY3MXjkcpr/5XwZAA4TtlOMVllr1srFW/ a6uDnFk0hdO35s7a71NjJoyOUQd9DlBcNCWlJO4iaWEv40/Hn6yAg36tGwvEqoYOV2fLpMoIYXZu VBJfpsqPzHX4TvkkymR1WpRUBPFiChOGKMi+XkiUE5WXLM2O52MyeWxeVMbgqIJMkQyAvC4QHZNQ FqtMGyrLLkvNU3ClUmEURqM4n1cYd82teVemSJW5WZOzQVFzqM2E2njS7Ck5t5YlxnkRFw163KhO gyCD1JOeGnFThiS8qoUgdgiE2Lysq9KuGqKM4l7KFUEaIBGCjoosLU8pjOZwKU5CUdJQBWli6B8U mZchy4ziMfTH5EamDY4ZMSWhIJsT7Ax09aBOQBpz15B/FanYTleLMCIlT6mW8yQisSpOkTUquYAx iC8kAkcsdX6dVJqQr07mC9mwaPjkpBgUMbbYG/zSKIaBSomQYWBJUoES8G9zt+Wrh2SpYtg8Yaxi UL46gUMh1hCK0Ha9V2Ni8YqS/vVo8QhG1vM4CpkoOkgFCT5vePysm/OuSJKIL+QByJYOi8zN5glt hLWPDAgjr3yg+MGS6Jg4RU6RSBYiLGYQj1ZOeGzUE5PiYlzWI6R88BCVJFWaSsNknGrw0Jj8HGVc tCyJA3P9oJ8SKWZlPDI7t0AtkMs5LAtlctKCoTEjM6PUEtHgEWmlc1NKpWTAQLu9LMHQ1JtuzLk6 SSIEWcIYtpBkB/0gIogsnJv30ti4CJtXU4PaYlVZ+ZHxcjFHzDyulHYTeHxkbrI8M0MmZImjk1WF g2MKy3Mm5EuHZIuS81PGSY3r6+iCO0dMixxoB5DNV0QhFjfb52Wxs6LHlUbKkqJS81TZonMUMI0T bku4+1KL4nKL4wrBQLsfEqSp5IXJsycqo+0skwP3y6TFYxKzReLYbGVS0LR1pw26bdCViBCakjb/ mXG3Jg1sAUECGjdD0RKOvddngiV5tw69/bqM3PTYwmxhnAnr0QS0Pg6vLP3hG/IGUyG90WeOV+fH y6M4IjArtjRbFgUzChhkKSISQqiwNOPua1JiofBZecRIdV4SaOlEtMwI5MiT7si7a0gET+/RuHny VEUUXwRFKQqL1PHCgfLuASxeFFdGwh5TyOCCs65LHy2SCJIihmVKQl2eZlqWlqxQ8oVQYmRpnjKK w3welqkhwAcHQIEsP/H62Tkz8pIKSqRpDkrX4+8y01hi/E0PFU2UAtYB6b/w+yTmOeHtloljmPHP 4UFcXvr41FwhzEuWZ5RKxHakQxOyhQTSGTm3TUxK5RCeDgRlgeZuvwWWDLku9/rx8Qk8FqyUpbJo GmEhkCT6usz51+bkR/HkAhhzUH1OQFESNzJJJZdL8kequLs83fnq3Aylms2TJipzciNjw3oWEsWx RQHIFWKhkdGjbx68cGTcQEs4lmRYWpmKAo20EeHIR2Xec3/h7CwFp9fSQPMjctT5EhHEEcElSZNj LhLNjcWPnxo9iE/6jZQnyFGOzpg7K3M0F2lH2NI0VWKeKpXFgaKihmSqhpSlDFNxLqSf34riSZFD UuWpCVKRUBofrywallJ2Z2bZYF5GgmLIdHXKbsPx1Jgbbx00OE2eUSxiO9Huzn4GXj/4rvGJiRDh 7gqFaLqvO2Dny4pvzJs1MibmkmTjZfw7+IeGoiTD+Xf7I7afU0yRFEFSLBg65xAXx0MEBcBsTv+t BpogCBoEqHAOXArm8thn73MxheEDjr8hkBKFYRhJhzME/N0RI+hwvBJWmAMkSTIW7dmLWYZ9BEWz 2BD0m6HwT9PP5fLOIj+cUQAjSDbMhqHfdJQkMYIAQZj9U006nO6ZYD7OPj88AhlCMYAFc9nnnElS JBbOsXHpKTqIoOaHpp1dfg9E2vcef8+qfu/A7Q9FXZReGkXDd5DYfzQPAYkjOMhmxmr4edpfpdn+ 1f7n1tuVN5VcOT3vwbLIgf2fT4MigyjFNJsMp6uGOdxfcjoDBMGUkQxh3N8kjGb6BQMg7rlbpEwP MpOI1Z8845IbFb7UFn72Ys5r5xNAkBjN6GLorB6kMSQ8ENmCX79xd2kIX/jBSYrh1ZlRRBEIGU7H gRMUsxjgsM++80SgDFdZ7J+vzNFUOB9GOLf47xMAFIniFPCbI5ARoTiOUADE1PxjqRQY/qEYzvCP wx74WP5Mtd9Nv71n5areHj8LDtob12oq7rii4qn80zdBzmdg+PoiIzxBpgcpiMW8+h96B/1/Ff9Q dkPQgF7/LIjFuVAcMUrurGkHwvBPv13YuL9D9Z4Gi8M5Pynh3wQQ4pxpOHwBBxgR+TsjhgxIPwhB bD70OyMbQJxzDazwQfrAUQUgHneAyzAsiPOHg21gIZfWomFkckHRS2WZsy+ufcN0cQf6+u9HmCW/ /Eb4fC6OdPQ0Geiza50o/uvPsiBB/8MDyD0Y5vxeYQiCEHzhniHTg/w/HB6GUfyXwBRmnXUhASCH /+dvZILns4UFn767PdC4ZlZV53AwrOFYlyDxWBD394xAZi3L4fxb8VgY/vEucifwnGq/m36awlxe U48/BLCVd45+fnZa9M/vOI+BzDtPL7EH3A25jL8a/1AL+DIu44+DJnx+pzMYOJ1NSCX8N4NVXRJI v9/pDiJU+AY2IJXFyAb2fr2My/gLQREBu9cVCGeu5EfJIoW/byPjMv5+/HMVMI7jLPg/Eov1Mv6f IXx5K7zb+z8UXvqfCprECZIFwdDviIEFEDjGYv+OUGbhDiQIMrw1++9TeBmX8TfiL0nGQJFIEA9H /f/DkcQJ57EbN9/r5I4oVipOlzAyEsNDBA0N6LjxH0Q4qt/5x29/FU7nYwdB6NyddBpDQxQAscJR +Ujw4qKNxlx1rXu31+2v7OnlSdRKwUWvYqEo0p8L4dd57T145PstLUd8nOQUmfAPNeifAMrlrnr0 h0f2olmT4tWXJfhfCqd+96J975k5ceny6F877WRA6N76Yc4DHTF3Dkr52XzD8f5z8XOTfNBksLn9 8/nHvk2MmhD3K5krabRXW7Xr5LbDnZ20ICJSJD49Z93GI18f21mja/EQsvgI2X9kABCYt75l28a6 Qy1WG5+nUgr/Q6dXl/G34684A0YrDjz4SKP8o5sXDlNF/DHFhKOudntzmv/nWKyUxbT/pfWLhXmv vF424lLDqxOoe9Ohl55sqc+BRf0FgRYi7e1ZL5YL9Q+veLSPHdbxthyTHAAAIABJREFUOA3Ex425 b/jUxprPftQ04+EzLWFSxKgbJtxWGim66KsDJ+Z8PCNq2J4vxmZfahtJb+1j3zzRRZ/eIGVHKUpu GHFzkcD00YHPDpn1HAh186/+6pb5qZzw6RaJuWobPn324JvHCTpOMv3pCc/OSE/lsQDCU//69/Pe drcKWaCcFVWS+9iiCXdFXaRXCcz+Y/dXb9bvAMBB7ydmZiovEnIupHlr8/wq9l3LJ0+N/JVjRNy2 ouqJ1SHfbN74iYmRl9r8fwpoGkVdJ/qaY5QW8h/rE3ERaKvfLDqypZR9+tYmZqSkZUPvuUflWnj0 G6+XIEAfBVAALY8QSq8bfo+25q0DPkAAAQEASFKV3z/h5qHKv1vfEJhF76yTh9zEb1Ylg3X2lgaq GwOAM0MQt+048dbn3ZyHxz8yIVbxc0XG+vX6dW2Obhc6cLixn+qFTpm2vnj8/V4687XYpMHqmNMr gK6OZQ+dXAfAqXOI2NL0xP/IAMBDzsON7z3ZdRKEy1/ixj6skp0n4ryO1tV7X1lp5c4aPu/uohJ/ 98ZH932hDSQuueODUul/15i9jHPwV3QeBNJogGaB9Pn2L07iIQznsrmc3zrx50eXH7qtniuW/VQQ 9tfDKQylL9xlIlx+D8QVc2kcozhi3gDamaJCLsehLk9d1y9lfh8ZognHMm/Fz0WFMpElOPp4sGGD Z9+ZIscPSzv2NC7cNPgiS1LCrdmFeucOFNEzgAYoiiXmX9SXhUQtX3krPdhPISEdG9qAhpcHX93h P7rL3dZflOLFybD4obHW3nUPbHv6RH+px7bipnXw/rsWjYnCnn8v//XThQBgAiS54Th2FwVblP7S NRvuzlh+y+4tIHDGuqVp2uuzh2i2RCw77c9CBc0ngla/5II30SQaCvhRnC8Q8zkckJ363rRXVn43 j8sagDvBoNsbwgUSpeQXT3YaxYJBkhayWSEMEPD4ZzYzaDoY8pIsvnigtAHnfh9DSYrFhkPBIJ8r OO25dCH9PyPgdVI8xbnJEEg/EqQhrpDz09YmCEVGTj7w0HAWP+J8nyEyYPNRKpn4F/rRYIhkMZSf fYecojBP0M/mCmGKoECugHOJc4pZAQSdXpziCWTic1P3oH57EJLJL27VuR1H7d6jW34pSC1AbQwz fcG6Az79z6UiMp3bXsKxbdn3cyoTx5ZGULl/+nWii58OerweiVgC4B4vJZby+qvRZCgUCKCEQMjM s9+wYAdEZPKcD2+axuUKeef2FEXiCBIAuRLBz5zlZi27o/ZDXtTPi18a82h8+l4y/rz4HSxYPGzo C0eyCJH4nMP+QMDpDZFimUp0uoks6bQRi4qVeffuXgPQv+xYFZZ91Rg3fu6axQT4B/3gwwMACbA5 Aogi6LMGAIkHvCFKLD4vxwwVCPpAjoAP/8JAviTpoTmbc2vf/9eBamqAUzc6FNK3Gr6v8AMCXdTE jIzOU18cNG830YCN+KCfAGYJ4sJBnkQoPtdjG7W5gxKZ/PKt3n8s/mwFTPpau4/u03e6Udu2unUa Hk+ZOKU8SYEi9gNVi18/9v5xClLxyh4d98qtuUMjuAObst2NK+86soYIGAYPWfpx+RhmgHldzbtO 7WhHzDz9tm8Pd8gVg0emDVLw2H795vmrrv2eErFBEqUzZxe+++XksgulOIevnDziydtMr7AGv3pv WnTAWbf41A4IxCFluWt+X1vnh+P3fzcr/4u3y4bJ+fwkz7Wdxpb4wW8+mKT64Mebvgz8+OnJjqWj MwaImGGpWX1kPUXhzZr137FTRML4kuzhUWzAbj7+xa6H3jM0emgqVfL4R3MeGxUlv3CPmqMq35BS NKHt8LvTOmYqWl5dP62epARxV78fl6P68d4a1jXvTb1vkCCsv3HUU9e8oQbKuqP4rReLUzfsfWRJ 25e7em+ONVQw2lcZ+XrFLQuUyInFP75gBQe+HkRTQU33ri8PrmhCuEk81BQ8o/W9+i1zV83cSXFA gJsZOfODq5cUibwH67Zp7Ua/b9+Gk0E+LSwtviZDAPvcnV/uXPCuZr+dWV7B5UunvXVreircb51/ X/Wkv8ltgzOuH3bndXn5HE/Tu9vmfayvdzMCAE/85Lp9d+REUyFbVc1bjx16twHg0lQI5dx9ZO4r w1VSl2H7wtXXfY+yaShmfM7L742bnio+PxkLgbmPHHtl4YmjBItsQJ2ZLNJLGiJiX988e77Mufc8 +ktExre2LlrXfUohgKqDPQHCN3/UwScLk3fsXfix1qqGiM5AVTuZ8/i4tx4tHq3icRz6NXNWvEFI 0ofl3v/K+DFcgKg+tmRxzc4+UsALVB0l3OPTv/v2+uslmP1Q1eKXKj44QcWmsCRcDqWOfPDbG25n 922+49vZW2gBDBAoOPTxcUtfLC28BN9jovutL2971lrLrCtjRSMeG/vuLSnQil1vruix5aoj1+jX BXDf29dqHsxPHVDbDZn48ctNe5eJ3t1x7UiDrmmvfi/C8tq9FQFq/KYZ07/dfe9aYMGpWdkvrFmQ qh42MnqBqaHn9gmLhtEnb9zzTI2+1UGRovNjsRFNtV++fGSNHqtvDrlyFdf4nNtMvMh3Z9RMlZo/ 3fnYx70VTpAOsaeunP3OrITYEzvm3d/QnCCSlA+9D9F+vc6oHZpy4wNldwxRis+nlQ7UN/3wxu6V 3YR41tiFc4eOUnJZhG3fLV88quHnpEoDGw07i+JveG3i22VxStx98l/fPt8Z9JGR922/7SZReBPL 29i2t7Kr3h5y7alfY+xWDMoaN0SpZKbVj5vvur2lbaIy89pRr92UFXb3DdqqFm+e95FZgzFGAJD7 0cwfb86M6mcgi81inb+EB0E275yoYB31K5889L0l0DdhzEfjXCsfamuN5yrnXvHpdRnqC7vAqvn6 X2tu30oLIIZG1sjHy954qbQARI3b9y+5r+E7LxmEwFFLp384LZq95vArn7Ro4jn2drSzHZ24bM7S 2zJTYRpvaPn2w4PrugguABva6AF3ksDIyMKysc98sO21erO51VB9MOh20sD1JTuuiYDNnd/cvu6u wxSbpoUjk+9564qF4r71Txxc5gFT5YFNWzBUxJ+zfNabUxLVf88x2WVcEv7kLSgSMW/uWf+No81F VH/b+cHilrc+7zFRuL/y1LvTjn0OqGe8nv/sSInjuR33ftXegFADW2t8cdIVEVgL1qbxe8O/U6TO fGhJ96ZmwlRn/W5J85IPNRV9jA0FYAcP37sCA2bkLvtmzAvTZQqF4GKJtBiriVnM22pav5y/be4y o+HegidGKmJhEJIp1EkyJQfmJCiSVHwRDEBSgVzAFQgFipiEie9OfYl5eEvvKT+JOdz6XodWe/rH rnUgiE2//XN7DQVgLa6VbzS8vqL7e20QD9pr5+9e8LrVPGfQy+/m3htCPrh6xa0n3IzhYO21//x4 r9nnIyiWWpnFvL+2Z9fmpkOtuEguiBWzuRKpUs7jC/lRUfzwGS2B+R1+Q7NuZ3Z06s1Dx8crsmZm T8+UxR7UGjt6a5jHHyi9NUPEVkQUzCtffGdKkWCAVIWY3rT9odU3feZ1krxQrbdCh3lP/8Vhbqrj zXymaOmiIdf7LMe/bWlwuFu29x3uxjx9ge1Lm956u+Xlaleo33j1hlD51KxX3i1YUMI7tar+gMV/ xp7isNpAaaY09OPDex9cdKrB4TGdIrKuzHhl+ehFJXDvgt1bvADtcjdsPfWeRTrx6eGfvZpWXiyV cCEWZtt95ZfXfk/ftHTMilcyy1rqnnnu4GrLBTkqQBBm8SU9mIHmpo+SSw287HFRQ92WHQ0+n6Xv fPpRWBwtQF1ARwOQsmDoC/fJY5dWTX25Vs+TKjXBY0dA4dhBz05Vc94/eOeqrhacptmcyOGJQ3yB umYf0r+DCUol6iCgOx6ozx782IPyiMPa+yr6nM3dqxccWeaPmv16we2Z8lAr0iuSiNksfO/+W7aB ETcMWbas5KGpUoWUd2l2Iebuavay789Z8sGIl9LxxvWdn3ahXD43qEd3bbI6nyt4ugwC3q7Y7LjY tgYki4AJj33rs1v+9VjdJ7lJd8zLLFfw4lKU2SnqBDUEA2xlgjopXpkhl4mEAjEZMlRqtm5qPeBA 2GMzCpQDrNZAoVDiZ3W1c8bfoR5d6zxYmv1oLonv6un2h1w4ETNz0OvvDp2fBx/9ouaIB8VkqrQQ 1FBN9JAwB6M72ygnLFaJB774C4nFKVkRfC+9vz2k74/DCoB8uYCtq/Nt7SUSFmTeaDe2b+1uQmgA hMRFiSVCsvGI3X96sxoPWU8adx0NGFxo9ZqupW81vbrPqjudbZCZRGWi7qOBHgd6Jt+Bx9lbQw2Z m/vWijGvpRMNzx7Y+XvSCtL9PwwE4kiA11dDNPsgkZxtaUHqLMJE9cDBodDdh+5lBsBtQz9jBsAV Ull4AFCeLTvvvq/ms8kZz34//uPrebuf2Dn9u14fzQa7saoK7qCy1HmDhbXLG06GCNLds6Jg4z2H aEe0UtSNdsMMVwbOT8GL4amGQQLU273xxKpqj58Psh3BMG/Mlg6j+OYXh73/ZOb4jt6j23s1bHEM BlkPO7c2xD7xftHjImLzw1vvrvaEQiG3ydF7RgQx/3E5iX+qB+7/H/zJFjAkSl846d0iyn9fk/KT mU8PV8i4bC6OOsz6ynjF8PvGfnx9mlJTqzAcePGUtTdE5PMHuqQRnTT2MRH5vbUDAM8sWwdnz9sl jH1q7WJe/utvjh4RDjUbvo1KxyjLYnRHqzu+wIQqgTSnUEaFL84PsKjofw8YdID6GA4/VhzDl4t5 P3lzUae/Qp9zgASG184A1j8bBBQd8OtXb39+mxPvjz4NBHDoyrGP3zH02a1iRczaJ6cM+W75+Fya AjkwbOnsCvhM4zKfWzhxboyQk/l981U9h6u03UHf2jdqG2T9e+8k6U7JmL9gdPnpL5/oW3nC127n FDyaMi9bzAbIsCjAqDPLE5Nm3VoDo4n5NE3R/UTiJEHSlAiiA2g40ZDg9LU+Fj8xNj+Ooi/sUYpE DZb6HaysG4cs+nJCQeXBR+dXNIYDcdCIB5KUC9ndxqNe2uSCWCAbVsZf8ep4QLP9MZf48TVTZkSw OeHLlBSBUSgmEjucbVUerRd1yakw6SwwzOsRGR9+c01JU2u2Z92bDlejSR6dLxB2uZv2hWgjEA4F wgJALlsZIx+O63RbG76L5YsKohR8Fq1t3XOSWW+xuG6fwU7yORKYIrrsQVwtPceGhNjC3JQrb5Bs tSVeE8/CpXThPWq4o7KKAhHvBfSz+fHlaZNW6Y4Xljz24NBSMJ39wfdPHTKaHhp/9bT6/XTmPYsn T+s7wek9tJgxJoisPElU2ZPTYoivpjYB4OkLpek5k8qbVrXxrlk44W5Wi/ujfZ/7QgGTV1/PLXhg 0IL5pdl5uzuaXdrrioYLYG6saqLc3FjVvtwnVErkGZkimjgzAmkk6A2RNI8v4V/cORcJYQkxMb3O xsMetwH1yUmKYMeVp074uOvQ8OJH5w8vVXY89TTeYcEB5cBmNdMLFA732EBhmjhbJJVyBbysgheW F0BcuhMPKxSCwxn01g2rATZ14hQYDHZu03wexMz20LUfFZbwBzgJgpLTx5bXpUTwp9ysrP/KGvHQ lAf2fP75OkevF4jEBXyro9kHaIK49/QAyB322Opgx+y6QyiFolBMaWrhA6WzUiQD0QryUpLG3T/W 3bVX9/MeMiQqmJdbvrGh6sFJi0ZRe3u1FV7cGqAApTjrnqufVthXbHOccSnkS9NuGfuqlX5mlT3p nYkLx0VHsKEz/pglw+57RohMPXjgpxQCWJDFHSYU6mwnd/soc/iO7Vme1OFO7g9Cc/ZC6cym75mi uJQrPyjtNO55hSA9fkglFxY8e8Xro2MHvMwGxyrHy60tR1tX2IWKSEVqeAAEjYe8PheZziW8PQ6W kJejoqJ0Id7tiSWTGw9FD7n1qWGDFq861tFPRU/bThE36v4xa+dnwZtPyO+v6L5IgGxGulAx0qJ0 Lu+4cXVW2j2DQy5TeAoHEUhaytG1G46ZUYMX5oIwHJU09n51dL2zZM3MBXl8vsy5f761u81q5uEH lh1cYwHE/cMzQEhmfnL9LVGcS/WouYw/E3/BGTDIYbNgFtHcbm6J8EO17vb06Mk8odJv6m6x1LTx Ymvt7TaCXcgTDHjFiCYCerveYmwM4iGTv6u2u1YoTcmMkLBYPDZttbnrWvQCm7+bKyseFZsAC+My eJMnpw/yBytWtn9oZHtL0kqzLgj7R1OE02vRU3FjUx+5LU7hdjW+tP3VR6YumhGj7NJ3GawGjES6 7I2tZm6MXGH16b2oz+7qqevcebT2e+bxK9LyxBAnSp2XIwOi+99twDlJiggYBMTy2Eiasno7W/SY xdsGiLLSWSJGCeg9zQ3mToQT2ONnJIBcJRQJWUk5KWA0O7yORqm+yEgZB/BqnD3Mr9cNeXuY/5sn qvfWdG85qZoiBU0axG8FDE26BjOXXVfz2tvWu59NHdPX1bu7bZs0mFilqzIgoqujE/J5c9WdC36o XTZacp2C5W01Vwe4aePSx0fzzo2AAbIY5aak3S5fY6tW0OJxeGmX1mnG4lmf7nlqFVn+6eQHBa7d Zutqj9/oDKJKoULF5huCug5zhwBtaEFZk9OvbOpZ92rn8dk5j8xRY/5aS4vfYEbcuDV8qu4JHq/V K3pseheLmw6glS0rP2lru2HEgqkqMGRcsxHV6JzeRIgjFQ6aoJYNVrIrtKtXNaxJz5owVRgXJg8W xiiSkiUyHi3iKopUgvMlAtN9Pp/RjCOBoMkJBjHY6wkKCNLaZ2/4cfeTP9BXnEc/Y1wxK/sm/ZGT UtDffYIZZhkRkRwgCADuDkfN/laZua/NSciSpHIICHX1tvUFDVYM9fk0jb2xUbJoEWnSIj4Fh7D6 7VyQR1GUzmlX82QJhKnJsGtdfVOjReOm2MxSj6GMLUoYIo4vS0rpc+9Zo1kdkolz43JT+SyAsH1V 9XmPzztr1MslFxwu/wTy+MH7Fvc6HyxeNVluR92HGgI+g9ccchsCGOII2iwuTQsGEGCfzuHIiR7A nxHx6NpwtkJ8xxujCgy65m1V7+xRj3tt3I2QV9vuaNQTjEWoa+ipjYnIjgaDRo/FDiVNy7mPH9jz eUvj5tZ9ydxrciLO2yumfV6zNuTrxsxmIaMKLb02GwYSaLB5X9v+JT0tt+XNn6EoZKxRrV9nRtBI Pid76LzSup2v7l+QIoi9YfTM9AG1bzhNi9/i0LaZmu0hD+TUNfQ20PE5Mbxgm62XpAmLV68nTRYi gPnNXsRDBC2WoLcnyDRe19pbJ+JEpkXHcjjCCIGcRm29to6GkL3N7xqZdXMq7KnXdbT0dQcJf6et scFIxElZW6s//KQz+OiE50eL3Pbe76tC3SaPP5FLGuy6XovBi9v6HE2negTJ0RlqHt6pbW219pho lO3uaNSqEyPiVCJhXOb02fVrnzn08D78VHHu9kkDa18GFFeUNEScVJaU1Ofe90PH6qCElx95axQM cwCCJ1SnqNRy/r2wVZMrZVu9VqaBHL/ZYJXZ8ZDB36MPoEKRmiCxbmdjs5nX7erBKaMLMSBEjvjc RRuOBa2uPgvAGxtTHK9OTVbm7DFvtnl7LQHNB7ufrpDcsqTspqBxtcld4/D0+UMJ/Q91b2o9Soih /W4nF0qIFYvEmDIzeXA0SxmeYCQSFCZdDjn5H8dfcg3J7+o8pNtQ0dd+omPTmq7W7OTZxZGSRv3x 4z376k0n1uuaJRHj7ymcliFTXHgsQQV6l1d+/GntD+2BPqNf122o1OJ5k1PiCNTdpN22t6+yprdy W+dRSlQ0PDrq6M5b3nP5YpRqLhtxOq3pCbMmp5VKLngpifmOnvrkw56TVr9R79E02eqaPfTk3KmZ LMOLG59cqz/WHTQbnR0hHEiSxexv+WqTvlbvNZ3SHDziB8akXfP4yBvjxIrByaMmp48alRb+uSqz NEMmYyQ7zOFpGzduslR3GA5sb1mH8geVppQCuKtGs6PG3FLdtekTCzYj5667iyYPih06OXPs6cfH pk8uik7koC0v7XqticT8+JA7x86CTHvXa/f5Av5GXcU6Q1WX36AzVx/q3n/Y2oQobnh85Gid6djx 7p2VusrNpp6YmBsWjpg6KCYZ9mhrur84bDZX92za1LopyM8pSShUnLsJwChgNsjyGg/VGvdXG07t NJ3oxrQWJGtGxmBD76H9Pr8Acrf16ftCeiMGZKiKc6IivMbaTd17Wq0120+9VeXklQ+aCvkaK7or MABz+Ex6j7nJ1Z4Zl9dcuWRv0GH1VLZb9Ae0J53SUXPzpkQSxkOmDgT091gMdtTV4W/i8sbli4yr D71wmBYoZRIs0IUCCVOH3FwUm25z9fjs9R4A6XXVVdu0UeoRY5PSeedFqsR99Q2fv6c5iuIBAnG1 OT1ygNPgqWhFsnMBfUUweB79MUTnpt7DLfY+s/7QN90thanTHh95aySl39/06RG3uU1Xc8CmT42b c1fh5ASe67O1Dy7vOXzKozEFe5qNWooTDdv2fdWx46SzN1EQcbh6WRXiQonsmfljY4LdHZaOFkYj eNq1mHxq/ozBUu72TdM/C4BRCiUMujy+YH7qnLEJeSIIRGxHbti98ISHc3vRjdEXDWVI2XS7N/V1 UyyOzdPc57W2erEocaTWuHOfuaXbq8wCde9oDrhoF8YquzYt8UJz1dj8xaPNe92oxeTq7PC01Nss CdEjJiRndNd/uLjiy51eRgUbes31gGhsJsf4fcWSnV5tZMSIm9JG4I5t33ccgoVXlCdEnTdXNC0/ fNyyudIjzOfDB+07CDSHGzpajwZSZMkmay1GB63uPoOvr8HZlpcypTBCDsEyYbBlo746LWnOg8On xfAGXtP7nB2bjr3zQfOmJp++12VuMZxUqMuyYc1zO19toyAkIKOQuo19lRZcXqjO1jWvXFrz7WFH pwXX91rqmu380qx8KQyFvLoD7dtPWGoOty7fZzCPzJkT6z9215bX9uuP9YTsBmdbrxONlaeAvtZD NiMJ+dqMWjtq0wQ1Ksn4DLb2mwMvfdV5rMXfpHNoqntPKmPGDRa7P1jzyIqeijrE6PP1NJidSnlW plLBgqQJgHdd+w+d4LAPr30mW3SxJRSycdN1XwaA6AgVBLg8fjw/5bqylJJoytvnqGsJ+INUX53+ cEcQzost0Gq/W2WqDlBynku301LZ6NSkxUwbFRtxSnd8c9dejaV2T+9RPa6VCtNHxpVGnMNG2uNq Xn/sjVUWbaz6ikdGLxCZNi7tPdLi1o/KuM6n31sZwiDKqbEajKEeMyHNjx6MGTdstVW0mv0nO7+t xNQzc++7LqcoTpFZkl4+pl8EjcooG5eUzPs9t7Ev46/EXxKIA/UbDnbvbvbaKRBOlowck1msYGHd hoqjploLTsKchBGJZUMj1QNuzVGobU/PwVa38eeSGPm02ZlJJB7oMBw53NfopcBIfubwlDEpMoGm /qPNAYoF4ARJS/kJJXEThkQPcAeHIpDW3p177NqzyuKuzLkile1aXb/B9lNRtCxrZExBp7mi3nm6 pjxWkFKYNCxF8itehGRn+5Yt9nYCYMn5CSPiJ2aqIjCfobr3YK3LgNAgX1A0LXNU0kBvIBHd+qYt JhIXcQtm5JX4Lcf36GojmBUxRRqCtl/qgWyJuPzmjDiL5eS+3koTRrL56WNTy4ZGqBg9iwW0B5vX VwcQgAWrxKnD48dkKSMvPIekSdRgPn5AW2UiWexweBMA4BTfMrgwZKxYbTiBgYIIXkoUO9BHCYbH jc5TSW2m6q36SmadDsPcIappo1PiEE/7/vadHRgpEyTHwrAZNeUkjA/pDzSQ4ex7OB6iWaqs6LET ElNwV/uunoO9oQDMTh0qYjcFdAkRV4+PIk+0rq/FQTrsKQolSIeXZwyL4HJD7s4DHVsaEZRmwZGi 1BHxZRmM+Lug+3p0u7dYe8SwTAqyHSQrVaQyIL1uTsEUvmNLX/W59A/n6b+5+/Da4uzb80WYg5M0 IWnU4AhBb8/m5zcscETfeE1GBsRSjkganaGQsQHX7hNft/zyKWVe7PAkSlNlbbOSwBBlsdN+Ug9A ckHhtTnFpKurSd8bAonmlnff7abfuO3LOQmxrTXvbAuxWTROUoBckDI6aQIjviGAbK26f8KBHTeO 3/5myeBfEXKIq2Vd63YjQUn5EfEchR3xJatzyFBvq9uAQ+mj5Lyj9kaAxVfKJ12fnnLhwHYa932t bzyrQJEbM2JkfJJNt323pdvXf5oIsTh5cXOKJb5j7ZuacCBGVjI6YZDbsOOoqy8ycs61ydHnvpI0 Gw/vN9Vb6ZThUmG1pyWCXxQLdPbQcJ48Q2M82I3TckFqLAwYUFNByg3FCpEP8VbVvjn32I5bRq94 eUTRxRzQEL+ppndvtd/5c8nItFuG8Nyrm7Y4QI6MmxnH9TZ5tAA7dULSUNJ+/LhLj5ypCCkEJdcO HiZl0V5318GeA+0BJwvipMnKJmYO4fnblrbs/vmdQl7m6IThSqxnh67CiIY47Ix8EdActGRFTSmW +6s0O9qwX0ganXFLoZTefnJVx89FcMKoxDEFSimKhZy9G0evnyeM/+b4LTMvHkoNr6t+Zzd6ZgBE iDJHJowJDwDS395Tscfa7MNRmC3MVIwvjYvpMe495jKJuCnJHFCH6DwEXpB08xi1oqtn72ZjHQbw GRMfpHwxsuJxicNU/LP3gehgQMsYM6dQIFU1bHRCic+wbbct3L8Tcu4VWg5sNDcQLImaFy9kedys qJExGc37b3i4i/PShHkuypwsGTU6dWgk73IwrH8i/rpIWBRBkiAInR3yhgqH4yeh3xkHZwDQFE1S VH8civ7ta5rCCQBm0Yz+ZQQNfH6Q/78LFIVTjFaBzk4dEc4fc/tkAAAgAElEQVQJQdHAudHh/02E cyGEY6bD4WjsZ38fxTAAhGCY/auOjuH0FASzJoLO4RNFYgQAhdMznF+b4SoNnRVenwqnt6CgczNh nK5LEHiYgF/yLhAE0yPQWSssmiaZf+HMpWQ4pDTrbBooHCf6Q/n/kSAr59JP6TTrlx55fWWfLT1m aIL8zq+uvZYHUH2Oyhe3Prnb0MqWF9xRMv/G7CsTBJd2+ELhjr0t33zeegwCcYP5pJN741ezFg5T RoQz4Ybv3ZFUf3t/OlUJ7dtc/qhl1JrrX8gU/9YdkP7kGX+s7X8zmP5n2nn2AAiZt8899KXJWnfC 55lT8OwrZQ8l8P7aZoSDllFU2Jf5V4P80CSOA/1ZWy79E7inYdHx5TXaozv76qOVV225ZVOe+KKv YeY+OcAACIOZrf3Sij1g1sWziaWZed1P7R/jHTMFSAA+I/4o59qTny079s6xQOSkzPzbRi6bHvPf GyTnfx9/3SVuFnzB4GcxC9eBw/H/ToCscF7us38/rd/+w6FOWawLHb/OygnxpyGcC2Gga0Ys7u9K /ACywsHcL3gY4gxotTAK8bzBwerHgHXDZ17nPnt+45m1GHjaWezCBjC9+IezBpxHP8jjxQ6Kn/Vg FEXRlFAee5oMLiwtVE2KU17JiMcEbsQfiFsGsvgJ0uxSqdeFkcX5U4pTJ+bJ+h3yzozA89jCGVr6 /go6Lk30O9r1S/KMfzpYrPNXziy2PJeXnZ2cOx6AkyKzfyUO1Z8F8Kx13q9Vg/74kAIhQQonCVTL C6OvIQCJ5II0wGfjp7k/wLyAfhelQH+b/q11elis/vIyOJafNCnj4TIQZIxy5X/L2Pr/in9uLOjL uIw/AMYaCGIhxh6hARqCheL+u+YUhQVDCNk/0mE2j/dH0sYxVj6GYEg48SXMFXB5l6OUA+GtDtQb DPZH3AFPs+V/4VCRwgNoEO+/hUADsEQo+q/avaUwDAmFt5TCroh8vuSyp9U/Gf9cBYyhGIvDhi+L uf9SUFgAowVc7uUOvIzLuIzLGBB/iRf0vw/csqv460k23hVl6t8IMkxgLh/O+duz3v/3gabwEIaE z4r+lhVx98kXCr5/syh3RhLvj28v/z0g8UBN3TefHt5crdPCvJg46cXPzAhvU9uObw99vaWu0s+J SVPI/3C6kf91YN4AEk4vf5k/v4D0uLTHG/YfbG8IQPJIkfj0TKSIkLZr/7qT+zQeQqVQCy+Lsv9P +JNPCChEt3LvGz+0ViOs074n6imlDz9YWsr/SegzBvcFczJshJ9XSAKAkC0Ez7fOT9cEzqrvX75U sYi/ovX+2y7wVBzgtb/jT7/U6K9wPr0DPflzGX3W9f7+nQUwnBX27Bec3m847wUXoWaA4p8eB2jg NwUb/RMFZ8KNaLvXv7jxvZjS918cVfJ7VOKApF6c2vPBgigxBx0oqMBF2nWxd57/twFG0JldnHOL f3pugB48f7ARwRbt2ve7DwepksckWUPjIy/CH7S+/sNHdr1YBfC5EKtRkTspLfkclwSgn+PnjoFL aOlvtfxPeu2/i9/zLVP90ol7X39kRvPdyVG/WvFXPxT+9/smxqVw4BJ4dfGql85wQtP2+QvbHtwQ 4sEAjlRgr1x7bEFuCYdFHzzy2KQjn3AhPk3xJ+meXDT+X4Oll7Mh/X/Bn6yAaYDSAdZKtIbNj1ML BH73sSf3rk1O8s2OESCIzeDR2TAc5qiSZfERPB6jlNGgrdvVYQ2BMnGMCMAhtkglimSTHgOU/GH5 SmlEwk/vJUMhe4+zx4aTPDZMkPKsyCQFlxVAAgQE0BDgD3oIEOJyBIxkpCnU6dUZfDYvBYkECVkK NR8CMMxrdpsJWCRhc10BrRlBk5S5MT+lJPuZfAz1Wn0OhEKcAY9UEAniZgvJH6QeEsGFcNxvdhuM ARcAi2KliWqhhM0CT9NvCdFCHo8NsqMVg6J4MM58y9Oj9XphrpBpi0gxMlPMZh43OXtNfnsIgCMl ySnyaD4M0UTA5Gjr9gW4vCg5JxzNSimKkvHgYMCu9RqcCMoTqFJkSQoemyIxj9/Y4zYGaTYPInn8 5DS5mjfwSSbp99u0bq0j6CM54hT5oASpkCZRBEMoCMRJzB/wcGAen8O52CkmhrrNHr3R50QpUCzN HKSM4gKEL2AxIwgbJLyIIwjK01QpEVzeRWxpwu3pI2NuWHntjRm8flFCU6GQs8/nBiAOirkcKBIt S0uQRDAWAE34Dc5Ond8Hs0VCiOlBVXJEpN9nsYf8XF6kDEQ6nO0hQJ6jzpXCpNtv0nvNAYqlFCXE SVUCGKJwr87ZZfC7MZqrlCWkyWIEMIsZLA6vtstjQSG+BMJ9RMrIBDVTGghaDB6DAyfYnKgURbyc w2HoxzGPLeAfOertVTFrFhyqYLHhAdtEU2QQMda6jZ3AFS9OfPLm7FyVUMQMAJ+7x4SRPE6EFPLr XVoEikxVJilg0uHVaX02prNkwuR0uYrpKYpEGaq0HivBjlByeTSFiQXRLMTqphGZKF3M8hk8bh5P ESlmxjXF9GCvV+8K4QJBZIo8Uc5hBRGH2e9lQZwg6nBhWKw8PV4iZ3qQxD0GhgOBAIcj5IKQiK+O 4rHtQQ/T0UJhjJhyG0MohwVJRXGKgfKUDAAqZPGYPRipkicICUer3yvjRMWKeR5fnwunYAC1B5wY LE+NSFbx+AMOAAJHnEEXQZFmj9sX5DKjWsTjgsy0RD0M/50YAsLiaFFstEh8sf0Digha3b3aoIek IZUwKV6u4oK4y8+MCowDoq6gE4Uj0xk+c8P+UQG/We/VO1FCKIhMlMVJuReLR8sQ4DV5DH1BL8yW xsuSogQCxGcwICgHYon4ShpzuXGMz5EpRRE8ELV5erU+OwJwI8TJqTIlF8C9Abs1GOTzpDw6qGX4 CkfnqWQWlxWA2BxYIoIJN+KjWIJIsUpyYVoRGrWiIQc85ZUrnhiJ75p39P2N7b3zc4rZaPNbhz+N UYxeMvoZbfs7L7fv/TFxfMbQob/q+HUZ/zv4s0NR8hNvjB1ZqTmsynzh6fyCPdtGP2TyIQQRDPRs Ovb2l007+mC+j4yfMWT+Q8PGx0LujRVvPFP5FSGMhSm1grLHxl/1+Linox07HjqywuLVDsn7bPmV 44BwNgJb5fEXnz6+1i6IhzCDgbx67Y2LJikCqyq+2RUEvMTWDw8apPy4YZnXjFbz9cZDn+5/dbfb gQK4iRzx9pXPzclMtJj3v7L22RZBZmlURmPfjiPO1rvGbHutdLz0nFiYlLF3/6t73jse1PtJh5g/ WIDqWkKGJ6f1LswW1TSt+LB640nEReFQYfLsh0feUaySHK547b7KNQJVDI70AdycZ6747uZUaWvb mhcOftQBAhwg0OvsnD1B89nIWKNx7/ObX6+kEUaPyITjXpny6tjoiPaWVS9tnXcYzpDTAjbl40qG PTL2+atikc3HPvmouzoEhNw+7s2jn3uw6GpOsHXZrudXGFu4Ap7Tq81Kf+OLyXckDhQfgCZsByrf eaVxJ8JlIb6elLgXV153P+Q6+V3D1saQUdv1/Yf+g8qoCTNyCtWCAW/IkNqOHxcd+biaDAGEqwmf tP229yeIAwerXl9YfVTFhQOUrj2U/Oik9x8ZWiwfKJIoQHn2HV7yRUetBQUevn7DrSmRjOjr7Pjh ie3LfOIUFsvR4qorSXv+o6seSBQQ1Y3LF+15rBJIlIFehOCOynv23UmzjlW+uaRuhzzhurE889vt G1BY/MaUY+P5LV8f+2y3pdULhqKkk+4Y9dB1qVkB3fa71j6o5as5NMrhFL00+e2rU6I8ffvf3/3E ty5CLuBYHY0++ZfG+2+lvB1rK5asaj9kgTgeMuXmokfmF42Ohnxbaj5bfWK3mZITUK8GUAIX8Ygg Qo4j1as+a9hnwP2bTi7pNFy/cMLVqVJ21b7H7u/UJMdcO1am29S4US+a8uqEZ0bz2z478MbeIELT iAMsf2vyY9NTYi19FUv2v7zN1IpxMlJh0onYZ4x6R1rz/BehrpvHHb1KsP9fm79IzZ777KQHotH6 NUc//khbT7NQp4d317iX5uWN6m1d+ezeb3FJCgb0tbnqx2a/9elVd0axQ8dOffTmgReqgTiGgT5c dPWwV+dG0O8cW9nu0ZeP/Ohq3zd3tjQl8BLuLP/kdKKC3wQV7Fq+/dnVWuPDc9aNc68q3P1teeIr X16Zu3HP059oDREQ4CS0Gizq1mGPPzVyeoLwwmRfhK5n3w9thxxocHvdp9w+GV8yZu6IMsivPVz3 +eLa9W1oAMcl5dm3PV12z6DwHv4FBODeas2WT/Y8fjDEBikvX3D9c5MfLI8SrDv0wnvNjVE8wk32 tSFZL1z94aNDcglf18qDb/zQftjJBflw7PSip2/NGxXHv3Bg0yhiPFy7/MPGXR2YFwvBZTl3LRh5 q6vy9dtOVcaJIv6Pve+Oj6pK+79z753eJzOTTEnvvQOhdxBQUFGWtZfVXdeydsW197ZiFxXFSpXe CYGEQHrvyWQyyfTe622/O4G1QHB1F33f37v5/sGHubn33Oc+53nOOc85T1lZ8regZsPXOt20tJvv n/0Hqqvq3aqXqxEKBff5aVe8tuhvS+PAk/Xvv9hQJU8qT8Qslcaj/eEFh9eseXXbEw6mPF32h0Uy 86eN38GCWY8vefyylITz95EprGzFsucXT5UlFAHaHhqNyaVTyeVHyNR8BBJOi33w8sIZfZSOvYMb nX5dAC+eULEm8X8Pl/y8gcJhiRl0brf+8KeNn+5zReIkK9OZaG//pkcb9vt5a+/PvWce2/vZqSe/ U/dpBz6/s2mDNOnuN+a8cL0sOBwxEiyxhE3nxeSsTVYaAIM26D/baDBgqBv4Vk1NWZhw883KxQti SZuAhofdHaERM6nxhHEw1D8Q0loQNOzq+fzM6+/poJlJ9zyUc3tCcNs9ex5pdmN8TkJ2QtKQpeqA qX9a6rV/Kf5TqkB0gfKTBl8slxsJscvXxC9xhqwLyx5dSQP2D/borWdePfp4W4R1Z879t8lim/qf fK212h0a2dL6mQ7KXJpx9+0JV0/npEej3Qnn6eF9Tc5QUdLNf0m7aQGnNI1LI+2ncCjIp+dcnXDT VbFTnPadxwy9Tmfngwcf2kGb+/SsN58onoHgBozOknPBmpZ3XmjbnChe+nD+A1ezB/9Rc8uHfVqT q+XAUC1TuHBt+h1XSxcUcsUXMX8BPBLwImCxYPENGbcvYUmPDT9wyuL3hSx9EbMHCNrR0f7woCrk DOITJn0HoglCIiERs/iKpNuuiy0Agp993TkMwkw+X4HhKh0nY2Xxwwsl/ip1lyMUmbgBCiMtZfH8 OKoabzCGxssugTCHKxUyrYMRc3HitbcrSzuHz/R5XS7d/pv2PtDAWPHczPVPTHkwVVjIh/ggyEqP L+AxAseGvqxEJM9Ne2x19io6otla8+g7htGilHv/lrrW7jjw0LFNI/6A32f3sRevTrh+lWKqzdF9 SKOKAPioZl+lfZAnWPanrDtXC3OmyGLBiKu559O/t9QAwusfyL17BsP4btW6fWMjxqFvrq18dpSr XJxTxmZiLBy42AQMUACCCXHYMBeCCTYlwobGyzlSE9MWCojO0/p3m4OcVWUPXZs2VRjpe6P6hQ0W wTWZDz2ccyvX+ckDB55uNY9Wdnyw3e5dUfj3F3NLqdjwEM5OksgKlGw1QthDhJAlkzEtuogqFLYd qX/1+a6deXFXPZb/wCpm25u1d32ucvC4Yi7DOIA4Z6Vef0tczpn+alUw4NLu+tOhp3s4Vz4/a/1D pfemCPJ5EFcozkgX0zTEKELjStmoJtzLks/KFF08mcR5H0oVpfKZXkq33u/lSkqnUjQ9/hBM58sk Sf7IoEVQdHPFizclCL9tfHS7RjNRA0QwqLWgbhQAAvhIT3BI5TOFsED70Na/V3+KxVz27KyXH8nN O6N68eFT1V50ggq+bkPNUzUv1sA59097ff30x+LQvY8ffabVSxVyBWF8yCKauab4/nKe5tBQbwQL NZ7469+6voNkf34o+44M0Pfq6Xf2qFTIBESFVKMHXql51QIm3J17/w1icG/bva+2dcqSZqVzbQO4 ic7kUSCbnQ4nyLJY/vbnq575zJFwc/ajj+TcAlk2PHbk5YEwIyUuO1YYrDEeH2Tnri266ZbCEiEv bWFqbEeo30UVs1j4IOHhSVISeRdUghrnq1CcWZ5VCnpOfdHyiQ+PvzItgwaCKIDQIVphXBqbQhPQ OFL6RQVwEv8ncemjxCjjh2Ag1T9iqqoOImXJ95VwgYO6Nh2FqqDACIbxBfnFyBCAIU67hsDxZbl/ vaZYlExTbx3brBTOSuIxaLzitdQb3hiqOpceHwBotJg02XL5kHZo7LiGEqbyWT7EDYjLPli+/iPV 1y+xbn7/ipu4RDRHhH2kdtit90KpAB4M4owkxXxBIOIK4UJZ1ry8xVsHrDNy73l05gImBQMp4AWH OKA4NqNMmmZn5CxUhPdZwKsq1gz03PO4y2jzI+1hHp8bh2MIjZFdLolQASYBCkvjSpucwdqBQ7GY HeMVu4M+jCJMFWYXiYwDYzUhwmWny21uWxBhWl2DXmoIiPggJEKO82EUD3oNDQQOcG67uWKZ38qt 6dhpFhVkxsBft3ssWAIbpHrDqES8eDbdG4lgPKayLDb1ZGC4akgH4WhsKBzEUAKYYKfK59HbMUuQ wnQHPJFxdQ4R9JSkVW+ggaf3vCfNWffktHJmNEhx4g1JPGzvC1vUWDg+5IZA0iQkBy8QpnEzFaWz 6ZJA/OI/z174ledUdYRy0bUbhV2Yu0IY7nxb1wyB4wJGocYK82fIM3VYzpqpt+Ftzcf0KhcWMYw1 9QHADOXDd0yfiSPz8mKnGXARE2LnZi+Z1bihIVjw2mXPFPIYt2IRt73+ycPtOLUshEdwKqdUWjoc poYJp8Y6EgdiYcSD4SgNBkEYppCdGDMlSzDQ5e052qtyEJJEsFnvzRkzdBlBWhYARjBCJCoqxTUI gpj1bVSIubrk9QdzGRUdyK3HzlAucrBHZUovK/sLjrrvP6W5acrzf8rJPGuiZBTetubEfR/Asx9b +NpUEYNkt2nw2w/99gCUTKCeIMxKi5+H4RGb1+NxaVPExauLbprL1w5YmxotiypkmWmM24C+ewGQ LhXklUqSjpML4oizy+9zYkkcEHSFsDjp8ulBEEHB+JiC8rg0P23amqm3utCjB80WJ4bqNXUqCmNR /AO3V0zDIrPzYls9VHmCMvuBKbfUG9tHrB3NiItBn/fg3L+WiRlne9fhdXpDqEAg4dInzpBJocum KUrEQ8cJAOIoZ15FBd4BIRYrpiSxbGrzcWnKqj/NWjJKUR8zNA07XBOyKrfwjgcCpmrnO9eUvbEu Lx4HYCLiGPWMtFDT12XeeOuUEsTA229qPaLqdePL+OfXQwQ8LnU45JqZ8+YNUxcJ6TCoO3C7pUcT pM6Ny51Ki5OnL/tTea5D+91AdP86MDB8lKAIwzAexsAEUW6pB6YBZA8D5yeDw0Imn7k/IkoHRREE YXNLZ0g4IEZJyVn7D3/XlSe3dJu70BC3ImXZTUUL6JrPhoLuEMwFUFeAwklXzoThSADglqTMKBnZ 7QtkvTT/wUIRG8dAGAIyFj9z7Ms1EVSltY1mS+dcX3Zjnlg4sV5gQa2+ekP1U7U++IrCR5YqkmBy DAIhjMAsPgdKkohF/ChIDnrE5P7zfw0utQWM+9S2PrPfFsNZ8LeKh5fCjKHR1z5qa4rwMsi/UalU KU8xVZAcS81RcEXi2FwKCB3ofPLlmvdfb99pjPqw4Dji7FLVHug47g75BuwNB1oOnNGaUCzo8geT BbPX5K1I5/ibRjbWWTXRaoYgnRzgA749B7qOb6l778Uzn6kQDpMtAQCEyRQlCJSLBWkgJSeRB9st PSeHurSA32htreo5o/X5iIncW9xOXbdT3+wYU3lcEXyodWTIDwFopMOOC1PBEE4JctlxSdIiJV0s p9MhgiDX2nT+sjsLliYJfPu0R05oNQhBoACBM0vW5qxaFB9Tbd+3ob3RFdCdbl9/xm9OlZWUCEjV B07pVFaqZCEMAq5Nj1a+/XHt26cjwHjsKkdJYwsoDhRkKETKpNhZcgoQy6TjOI7CsUXxl69JL3AR XV/0VusC/okWy7h+7NDewc02unRmYnHKeIaSQ+oeH0EOV1QIHx00HD7Wvuf1E89+1N3km8j+wAK6 /eqDNV6iOGlKkaiAvNJtahz1evTW/oGI0+Tu61J3DXntvfaObocDm4gCr2vkdPfRIyNngmi4eeD4 ofYqjS/s8qm7zcNWn61f19LkstqwsbZRFUNISgUwZt6wt6ehWVV1auywCTUjYXvXYGOd1xkErJ2D hw50dUQgUnAEYmEiDwDjmSK5MCWfxeHSJTzc+l3Lx8fcRGnawimCOCHmMNq7dW6PN+SIoLGXpV59 Tf5MwFX9Xf9b6gidH5NGfhyVRo/jKSoEyTFwTjxPQJr1KIbUqHZVDZysHa5yY4NmT4cjhE7AFsSv 0jSe0vbb0dFudeWRvi5ntPidv7tr/15yWYX4utUnTw11OxCAy1PQGHxSAtksKSmBC/npMJiVFCPi CRM19vrdHR9vPPPFaftIGMcwsre58kwCbTfUHh2oqrVqVC5bry+ioDE5FDsCsRNiSAGYI6dQJAzQ 5hkesIyY3GaSgY1upwtXN42ouJJcnAiPmD7d39vQOFR5WldpRq1kp8TEL7xRUXyq+/V13Ycuy318 uvicU0/QM7S54dW/Hfmkw2m/2AYIEA2VZlNAuF/bcqr1i61kLwYbei3u8Tp5umrN3i9qN21U19vQ +Fyx5CINQFH/AgrQrT1d2XXo9WPrXm/uFrJlaZimc+xwVW/tvq7DFp99qiKZPVFeFxYnlkpjt4zu PjrY1NK1baNthA7FyujIiH1kOGIftfd3q7uHgr4ea0u3E0+Iy6MClBSIJRMlZ3DJ23gMmDNBSUiQ JmCI4kE/RsFEPHmStExB5ciZUbakZN90GQv6rOWlxgB1acaqeDbM4SdQ6RwAiLBJZRcq5/LS6VCG GA4MjDb2W/VoxNY5WH16ZAwbL5XGFpY/lDuzYfit9X1t6UmXLZFfJGoDD6lHD715dN0GdZOIl8v2 V2/q6wpjOENUMItwN2k+2NG678DgsW5qgpAjZ01OwP81uMRhSHjIuLfzq326DrVXuKLipuUcfOfg 121u+5KiPyejoxpTTZu7p8F0xgsmL8udlyvPUtD5LkOv1o15I5beIDolcfkiMbah/u0PuneNhez2 gLrLUKvHpi6KC+899eS+kMuJmbUeNZVWurroj9kCMUyhIJ6x3Zo9Z4wdTboOnJo9P3tRJpfrN9d2 OTvaHa21xlqBaOUfCvJVqu3r6r/UIUaLt7dB70yRFWaKxBdWbdCNHPyy46s6LyuTzunynLH4E2VE /ym/aVHufVPYwUFrV4Ojq81a3++mFKcvr5Dg7x9/4WTIFsJNIx4zTk2/sXB1sQg41L5p+1i9BbMa g7p+N3Rjyd0rkiRmS/cxY5faO2QlDdOwr8tOWViwapU8hRW0DJlsKBKw+A088cwVObNTWBzcqz5j 7epyttcbTpmQtBXFK9nBxvcbPu3FXM6IXuUJFMYvvy5n2lknlPOABq3N+tY2l7rH3hQhYiJ+9VAo aU3RbD4eGrU0HRg7cVp3usviTlHMq5ApaRfuwhOh0dHKbmvXsKd72A1xcXuXp29m8nLz8KaPda1B gsn0Olus9R2uPrlkwTxF/IVBTcaRw2/UvbVNV2dGQ1pHX6e5KSPpKtB59L2274bDbAaCdzubO32q kUjhjeXL0slFgfqLw8aeas3xVqsnUz67kIt+3PDRVl1zANX2WlpPjoFXls0VUVkcGkdnHThta+lx NJ+2GiWSeVdm5PkNzXsd/ZbAYJ+FXI44h0NohqQUNG79Rn1sEHWZIrpRx1CK7O5by5cncMWAe0Bt Od3m6m4wnQ5Ss1fmz02TJoatvd+q9naa206ZVBbUyGUmz4ifLWOd70SDBEwHWt5b33/Mghj1ru56 u2hean4s3fnx9tu/8JnDiKnH0GaMIIUJs5V8sRCEAuZTTc7uDntTnalJKll5bVFFHEvksfbWjrSr bNqhgM5NnfbX0hmxPL5j8NhWY82wtc0SdA/7wWz53MtTskH30ClrV4+rrc5Q4ySyL8tbELId+rjr wHCYw0EijfamgYB6OFz254plMsw7PPz1YWN39UhVtyOcFz+7MDaeNOvj6djhwV19xGUfX3VP8rnE wrhx7MCH9a+bmSVXZc+LY140aSQNRPrUlUd1Zxq0VU0hJwV3yoWXFbAslX1fDfj9g6bWDh+4suj+ G/Onii5SzA6Gwurhowd09Y36EyeM3mzFZVdmZAmChlpN5TFddeVYT7xk+RNzbswW8i/0w6IxRVwC aB/YfsJYd3LkwMlA+oPTH1gi453s/myLuSuIixjusRpr05BnIFm+ZmVuudeqrjQ3DHk66i39IXr2 ovSZaQLOBWINc2hcVsTWZe1sdna1mM+ovNw5eVdNkYogiMvGDHtH2rPT7rivfJ4IBkkChBSKz3Si wdnbYW9stHQqYq9YpGBXtn3w+UiDwTfWaawz4mnzkzJZ0fSPVBaLd6p1Yyim4K5pj5SJ2BM78SGu yt4vXu7cYycNhrCl0XA6QJ21NjOXzpQk4Y521eYD+o4up7ck585b82fEM/+3R+5N4lLhEifiILCg 1qHS+u0IIMqRZYgBb6uxJwwxsiTFUEg35Bi2hBEQpsu4aWkxSg4VjrhH2w16gAr1DH39am/bbfM/ eyBfPmgfMgfd37fJZxXkCUC1vn4EgwgsggOwmJ2cLU3m0qIr3Yjf0GYhLQ+cRRUo+WlKclbGfHp7 /7A7WliURmel8AuTRTy3d7TTMfbPJgXpkjQZm3PB8l/UYCIAACAASURBVJsI+LQqh9pBCBQMli1s hWG5lGLXodFhnUM41dbhsYADp8ACZny6JEVMjzQP1buoAIqgBACLuEk5MSl8GqoydI8F7eFo5lyM xozLk+TLmJDLM9ptVXkJUMKSMAjEjdEz4jIkcKBHNRiAqH5Xw1vHXiayntiw8s9yMGJ3jvU7R52R IAgz49gZmbEKLKjr0PcGIAqKohCVlyjMTBNIJswxi0W8mujn2wgqXcmOR0P6AKwslKcxiJDFpR5w jYVwUMhQJomTxUzmBAYIEbE6BvvtWh8FFrHihYDPjIUyxCVEQNXvc1Ahvhim+1CnF0NkgoJ0/oXn 6EDQp+93adzouZM4CIQzpFMZiL7PrglR2CIaH8VdHiQAUJPL45S0iGPQ0jkaCAIgQ8xNSBHGC2F0 0KH6kQDIpyZmMKPuyl6dY2jIY4zgIIMuSRamJfG5Psdws30wBDAFjFg+FHETtCRBMjOk6iN7n5QV hOQVM5FfmCkRgzjicI+oHCO2CArBDDkvIy0m6jLtdAy124eDOJXB4IBEiMtQpIuSeRck8MPRoN45 NOz/Zy0BKKE4LoEPI4OjDYbvBZUZmxaTyYVBNOLR2fuG3LYwQWEwuCmC/CShAMDCdrd2xGOPBMY2 1r601TG78ranp0v4ZktPh0sLk3YXlebF4ARhWgKX7XRq+pyjHiRM0i/nZKWJY8OBsQHHWJjCldC5 QdThQ0MANZVcQgEh86ClWxsMUSCmhJuYIlQK6WAgFDAObl52ZJ00ZVvV6kXnhnPcXd346t+q665d 9PJ9RVNZPxMOjge11u5+p4VgkCsRCgjS4tipqHH3EwffF2Tdc11eDgsWpIlTxcyLucFHV+J6c2e/ 1x4BIB4rgWSplAl5faYBm8oS9oGwIFGQniYiBXjiHbhIyKG29Y1FndtBPic9n1R2KKxzDIwE3HRY HAMBTsQZxLF4UXkqj2m1DXa51YEIANN4Cl5qikDKnjA1LYH5/OYhm9oYcgMgVcRMyoxNEUY7mggE 9G16FU9UmBsjPEsQGnaN2XuH3A4EgFhMfoogV84GjU4VScC5vmZn5sXEUkHC63VpjYfu2PwwI2Pd 19fcHTexE33UNcPoGRlwGb+/EMPOyRFLIAoFDVv7DS1D/iCTHpcTl6fgcicdsP578LtmwiIIHI9G YYLfL3t7jldc0+ch1dAfsIoEpW+u2Do3jnexZ4moJ0z0XxA8T/FxHB+PeP1RwC0+XtCeQrmUBRqi obU/ISD6PQDlXMzv91SNU3PufhD8wcyOPhv9+h+oDBi2ln33LAhBGOIJYrIbp3/w5NQS6rlnf8Kr 8Vefe9ePGXgxSvGzZE4QxBtt5V+mjzjL0N8ry0S0wkY0Be+/LtFBcjDKFfBHpBE4hlPAn5znE2c7 gLiQVxdK4LkmCOACofoPcVYCf0IqCevItudOv75N22dDmCkx61r+ej9vvMgBcEGfTkzqRd4VTfo/ LoHkj7C97sHq1ys19WqfhcVM3X1b71xRdEjHQ9oPap876lY8Pe/hkosYaufRD4Dj+dwJpEe7+56d D7R4nXSW7I9TX/hbydVJv6CaxYVSOK4CxIUfezECiF8kFdFqBtFbf0Gz4wp8obD9Uy0mIuDnBAMZ vumTlfURt9ZtgWNWPLHkvUfTf5Gr+QVURcuckPT/u1VqJvH/K/6HU1EG7K0H+7pcEZwrSC5LKUri 8/+rUuwSiLWmvXLI46fRBHmpU3NjFfR/p3zLJP6/QcA9XK9qMQYQkJx0OYWrSwsveckOLKir7W0Y 9XrJ2RsBhJfPuOJchU4CD2MhlICY8K9ND4y73KoznQ0OAiYXNkpleYkyhXdh/ZH/RjiO1O4zYVHn eSZLVpQ5K4N/YVzWJCZxUfzvzQU9iUlMYhKTmMT/YfxfmIAJHI2g6PhuHUSFLnYI81u8Fwlj5OoX olMv9LvEQ36Hh8KRsv6NrHKEy6YaC9JTYuBBvVWZVCCdwK3zXwFH7D43gy1i/5xJjUeiMVHROja/ D9cILOQJ+iEah027WLqif975n+ZWnCjnKUCgEb8HIZgMNvPX7zQE/Va9w87kCIIBF5WrUHC5vynT 8IjbGEDj+DG/oHATgWEIgkX3MGFSA37GvCUwbzRbE51DZ/7qelAEgeIIGj0sAKnRytM/PI9jYX/Q h9ME/H+VP4JAg65QgEbjsmg/9h8kfkFq1e9vxRAMHd+cJ6X2Z7bBJxSAXwdyYCHfNX48AdPg8d4+ y0CIwaFdLA7/0gGPWLwuDlfyc6f1F8fvmZ10Ev82/pcWY/hVsIwdfGrfWwd66zReIEOZNpFn0X8G Ag+GLGqHxu532/02u99p9xudYdyn2f300Y+PjjhLs4vPd7tERp/YNP/6Zvj+qVN+/R5juPrQbbfW jk2T2Bbvujk55S8l/H9V1P3CJkwHZm6+IsC7dqaEf/GbRt7f+cxXXdVc2Zxk9u9RN9SuPfj3fY92 AnFFcek/V7gOD6tNXcYwLYbJ/LfOoXGXo6/LHhSyuT9x88Fdhxteumb3Nk5McbFY+CvbRdUDXz+5 e/0oQdvS80ovnjhFmsz6Lc8LVA2PFmx9e+mUW+T/SoDQiO9M4/uvVm+u1qhhhjJFxL/Yp6Ge7kcO 3brDhExTFP/aPeRIQH+k4bP3T31zdNgcK0qQcb8/RcZG9bvXfnJTLV5+ebLy52dgq3rH/Xue0DHT 8yUJ9HNuFBGDoWkkxJaymb+kR1zGM59Xb/y6eUetAZ6ekkKb+NAUd9q62u1ILJf3bx9pEZi/rnfH xsr3v2471m1xZiQWkm2hrtZHDv/pgINVFpfzW2/Ch3RbEjcuECvvKxf+avUH8OCQocOCciUTJAWb xP8i/EYyRGA4Gl0sR5erPwQcjvsajJdq/Smw6F3jDk7fp2eKulVg2AWxitEWMAz/aQNBzN2GdVca dx6zdAbP/olcu44vk0kjdcJY1V/5MYH+gU+Wb5i5fOOVyzcuH/935tXbPhixD582fPnV0AFLmDRB znsPLUZaNFUs+PHFceKjVE3IhB8/K4/jMNl0IJrFIr9U8n1iHZI/KHbRDFY/BZVfFFsWe17637ME 4OP9QBKAePv8p7/UbhwNXiSn1UVAfgFKfu8PX0Bc0CnkFfT8fiKJovNSpMmK81JwR4UkSg+On+tw Ijj0yqGb7zlRGa2+OxHOaxzFkAgpbj9cQBprH1u9eYPGH/gp3RCLE58rTZTSz19tRHvkAmqjhP0Q Kg3xuRyJmEmafwCQlC2UsuB/6axKGoznf8BZFZhw2wmPCu0PUsTiyqcqUljnKei4DxHx03RJZHd4 QiMt/spP+/eeMBknyAP1PSBmkignlS/98dxBAFFlwaLKd4Fq/QgYGjCGuk849m5U1w76fT+6j0Kl CpPk+ensn4z1UVmL3kRq4A9x1VSGID02WcZifc87BLF+tfXyeyprLhRB/OwY8lOgEY8R7T5k2Lq+ q9aOTRDIPo7I6RP3XL55kxW5oNWJGDghcE/j8gN//sjWpYUHhsI13kj0XQTMIhmYxI35JZPvOTX5 1zdG7xwfAMdl4/uLVOFUeYX4gkhD8q4JVOu8e/w9T+39w721bRO9C0dxjDhPW8cHlrP4BfRO4pLh 0ts9OOIe1tfXWYd9FBoLxLzEjL+U5kE44nD2NuuaNBEMoidXxE/JEAioFAALmRtVhzr8fjrMEsA0 Hq9gemIe6tV0GJoHfA6EQiuULiyNV4Tdw83aIYzGQzGbxmdOl06fpsiJBhvgfvVYpyogfG7qU8ea 1ncB0eQ+IZ+xRVfb67ISVCaM+5Pjb54Xx/lPvohU1yCGethxRSKp2jpI5UiEEVa3zx9T9OA93e/c 7bIf6PysjqAqpFPmJmRyIAr5re1jQ1kJV6WxC/45AeLBgKVFU9ftM0EQjcBY09MXZgkkF9nDBMXC 6dNkUhGTM0OacjZfEYr4R03NdaZePxybwBRQsIAkpiwJtO4zj8SziiqUrD51nQPmZMZVJHAZXqfq pDW4MvlaKeP7/sX9fmPHWGOXxwTSpDDhj42ZNl+Z/8r8v36x5WEKHhgcaer3oWJeQo48SzDBjjfm 9enaNR1hemwih6d2dAz73GWJV5TGyny2vlrdGW0E4bMTSuUVqSIhBfGqtDUN1lE/FJdIgxEIEnOL pyXEej2jnVZPsvyKJF4CTJyrHOW2dp/Q1uojAJ1G5dLlRfHz05io2djbGfQAdJveoWVQqOIYOQuI GKy9HWajgB8vAgOdlm4HEL8id46UsJ1RHesLeBGCoRDlz0ksE9MJj9fiCAcxStDk0HPDTAZHJmHR CDyss6n9mPyGotJ8keAHR3TPSJPmZF84woBjcmOn5UplAUdPt90YJGAwohkMIDmyZbOTE6gAhc1M zpNNZ/GllFC8hD5xHQISPrem3dgfJDh0dJgUEhYnb2HKNCWb7PSQydrebOrSIziVkTk/aUoih4X6 VFXqXgpdnCQU683NAyG4JGFWsVSoHW0cInJuz8nnjJ9xjEsh6vGMNupaNCE3BZQUxJUVxcpJ+z7o 1Xbph+DYy/9M0J9r7qLAF90ZDQUsXWZtvHB2sSCDQTk3AGMBfe3Q4Z5QCIp6ZsXkxc2YKpdOOLkw +Rm3z3uJB0CPdqI/dgwO+8c6jb4rCm5UyBVg9Keh09jniuDm4JgfkqdDusEgtUC5okIucDrVXU40 R7kynSODzpYOw4Nmu94d9Q5z66xjLJjJ54hIvcYjzt7REy1us5+A+byKFSm5fCoFRwMmu7rfz1iS eZPaPLQ3ROr/hIWKEJfH7IiEcTBgtOlwGpXJjhOzaCQDna7hFkPHWQYWy6blS6UXiYMi3I4xzWgb uaycnvj318rSBKIUBQcmGdhqNpIMlIgSzzIQC45VDrYDMJvDUsTSwxqHHqPG5MhzlRyq0dh90tzh Ckc4rLQ5yTMSuRM5Z0WsdQN1HogeDmpcAJdHpZpCcHHC9JLY2IC954gd+Ev2rTLa+IyIh20OVZtJ R6VzHIExS9hXpFxaEqeghvVVqjacHlegzLLZOnp9YKk8L54NGXUdnWG/JGjR2rXkTC4SxrIhCoEF 9eaWZnOvCQVozJzFKeUKFp3AvJ2qUw1uDUGhwhRWtmxKiTz9F+1FTOJS4JJPwLhVd/jjqqePBGWZ Ir5m7GAz/d1bS7IQZ+cnJ147ahxjcvgmH3pcuebROdcUcIJ76t5Y3/COmTElBjBqAv55hc8lcuBT 7R982FGN0xjBQCc/5obVMx5YDp15de8LWmZyDIOq97ZJxTe+v3JdsZje2vL22637W1zUdBaoDVoU 0ZAOf/vg9qdOfkUI42MozmZt7eK5S+bFpf/H3wVlxS58dupln5/8kJW+Zn5w8+O9OEhQGBAQQk49 e8KTBnsowhXvLnt2bhwPC2oPN355eLTOwr9zQXYWf9yGHhrb//CRD52M2Eyap9kCPiXISyEn4Iu8 TKhc9YCYlSSgvDwnRQFHt+mGtUefP/lmg83MpElomNcdca+asekGWsstletLZG/uXZm47ehfTjDK 7p+blZApsxmaPzjx9qhPV160faZcHM2EG9Qdq3/x9a56A8DgE5jKN1Sc9Y8yaRILJNcApGKqttTc u8HJWpjz57+L0wXUC+giUIej/eMjj7RSY/OFSRZ3d4Ord+30xOex4XdPv9VocLEFdI/fm5C09r4p V9Ltx9+qerouxBOBdItfH6QylmR/Uh4vsljavzr+Rn3Qu2Tak/eK5PFMGMDtO06se3ZgpCQtL+Tq sVPS7ltYGsce2tKxXeOxEqHtL1e3UjDqLUvWz2AH+wf2vHhqJy5JUNCYamt1fyhXJi8scx16+OBr bGkOC7MZA2Lvon9clwzv7di0WT/gDtveO+OIAcH07KcfKUoiUF+f6vA7p7YbmdMeXXp/Ap9LfiTi GXqj+vlDXdtCrHwCDQgly++ecYPMcvi1pm8Hw2g6janxNdOld225/p0sFsTk511emkBj8vzydAYv 7mLn8i5z21tVL/UGQDaA0aiBFi/rrukPPj5jFWKv++Dk+nqni8Gkj3kodRm3PTF3pcDS8O6+14YY rCJFltXY0BXAbpz9j1TRlMa2LZvU9Zow8qRs9vUJ5PIRc9o7d53+x0fqdh8FDgZD6Yo5D897erYw +EbNy9UDrRFQ4cD7dUTiz5h2Ptfo/vp3N4+1ZSff+5oomR8NgcUG259/tPprRLI0ARxrs8F/nE2u oi5WjRGggBANhmHgJ5nC/I6WD4+8YYTZs8qeyY+TBJ09H9e+UmtGqLC9NxTJppITjz4+GfrmyqsN xsbPK99rCflXznr1HsGSWAaEuTteqX6zPhjQW79+oeqUiF+2smANuao60/PV+tPfeFhxDMLZ4z5o mLXuzqI8tfbox/Wf9ZkCOIx1+nTBi+yt4kHt9tbPdpg1gfDRN2rMPIiel73u3nw5ycAtNa9+PtoT oED+YDg7YeH9s9ctipdP1AY62PPJ+q7DQQwZ0r77jDtuafnLt+UpSQbuPP3WXkN3Xtq6lwVKkoGo p/vN3XdpGLHZstuWKQ1v13/DFS56esljuLXhg9OfVgdoSiagMY81Fd1137Tb07gXUBxSf7rnL2fo IhEQMkZcHGaKOYxcUf7I88JrXaPVr1ZvCEfsc6cVT5XmkAPIsGb/c0c3ellJHGpE62lPS0Q2rbpF 5u9cv+cuc8zU5y97ua/jo2eHIi8vfvYqkemT1u2mgMup2/jciSN0WPLHOU9N5xMa/Yn3q99r9wUZ dEjthppy7npq3nKm8/S6w+taCPFMEdhjci2f/vfMuHTmZCTy74VLf15qt3W3u7RuIiaNVTo7Zva1 aakQ4u/q++LNvjo/fdZy+WUpNP+ezlf2jPToVDv/XveBQXT3+iVvvTDvuSuSlsZCzCHVnk9aD4uT 1r6w6K31i/9OM3z6bNVnfk56gYTuhpH5uXc+kD7bbW7tcdt8ro7HT7z0lSf+lvn3Ls/OhlDn+Pv9 KnPTkNcUpiaX8GfNEa2YIpk4sPiXgwLSEhVz/1K8Kp7NpEEwjSYoyr/t4ZmXxY4XPqNTSx9a+MYj JUuZ3vZBu4e8H2IolpdfN0cQMgb85/ZUsZDe2VPv0wng2DLe9PmyOfEswc8IOYOXkCEV02gxhWk5 PBDAIr6Wnq8q3b61015+a/bN2WzUSEkqiJMrkueupRuGg0EmQ5yRmGVG8MD4lmmMfMoDxbOCsN8W Do+/HrFYG99t3OUXLHppyfr18++6SZ6TwmCfPR6LoMGvW17b53bnpVy5pnB23IQZgilwjDCrIqPI 6xw0gdLrpz32xsI3ViQrW2sff7lvp4W/aIVsSRKMb+vatLPr6Le927cFkv5Y8fxbSx6cynLYUfG8 nEyYQpVKS64sWpTAcRgRG3J2Cw23nezbZ6KAbEbRDOH8WeIpyRwGTBcoJYksOoPJkmfIM7OUaUKY AsKszMSKqcmxar+JK5v70MIX31h0eyaXDQA0BX9aHj1NQZfofJoGswEB6RJxgoLNgeGYpLiMNGVW wnhkCAVi56YuXp1TBCE29z83lvX9Xz3fvj028+m3lq7/e/kfUNuuL7sPUiSFSRyKEUxaO+f5v6dV DNm/6XWGyJthhkAhSZBwBEmy1Dg2+2LdJ5TmlwsZjmB4xvQnX1/y1s0x7i9bX60aUZ3u/vwD9RCV M2+FYmkcqP2y6ZnDOgNLMuXm0gptZMhBUfxh7tP/WPzw8qQMJsQpL77hjykKLd7niER3lMnFQevw npe7T8uSbn5jyVuvTLtszPrdYzXH+7o/f671G1b8qr/OvHaWPIFPXLyYBACQhK/MX5oew9CGvef4 D+Ajqn2tGMQEk0r4M5bIygtEwl+yJP/xe9jCoptnXJNAaE2h6H47U5BewGc6wIRbC1YzAF187vN3 JqYP21rtGE0uq7i6YI6EZTWjTvTsHijES1GmS2CIyVSmKTNTYhUCJtVjqtvQ/PFej3SadNkV8oVh 774PGt6o02uOd3y6z2qaW7z2+uJ5GUw29WJ7pSAzVpKoYLEgWJIiz0hXZCh5DBxxkwx8ra+NZOCb S9eTDOzWf0UyMDxxE5RYReGs9HzSPs5PnT83b062iHOWgdcWLiYZqA/7zjIQ5uXdXD5TjegAXkIc l+aCOKlJs3J5kd0tn3460pUrmnW54vJioPebzve2qMwTvIeZNCdRbgFEq6ffX0ITSWIWz4/n24Ij fgSLS5j3TEmFBrM6w1EBoECsWFGaghcK0NnXlT/01/i8rpGTqkAA5OYtjpcakSE/hZ8vTUsDnE4U gxiixNhEOpXG4iZkKjIzZEkCGAz7tFWdn38yqudy569QLIkBBj+tf+Ko0eFz9hxyq1ggt5A7bV7s nEy+crIS4u+JS24Bg1JpxZS4VVR3eFh/uj9s5kAf9Hs/tFjVNpCeQeczqOx8+QIqdUzBYDstQzoC L5Csvix7Co7lp0mKTJGwVt3kDFGXp86emTGDA8ZX7nuy1TeK0xPzyFHVL52XexmztzqGog0TaNhn aMQIQHTF3eVX+qyxTW17zSAVhDkZ0vJ5cpfVb6y396lRyD/QfX1WbHTxGd2D0umcPrE0Scrh/PJF HgWky2OnXyMBfObaKMcIgC9beZ0MgKGobtCgvLWFMymjmqSunrNx9CBNXJg2e7SJRwvAZ40JCsRU CkuuFncjqLPSoHJQMMnonDJxnPSXlWjFCdTvswiYcRXJCxeI7adVO2je9BShRChJmE8HDgIonS5K UhQD+kFgnACeMGV++nx+61bgbLl4AvOHbGpUPEU85/LsCg5RrOQkuBhpXBpMgFQUR06o99Fg5TKq NE+awoUnXJNBHK4yPz4/tku/IH3N2pJyOoBTQN+mA13k30RsNh1i5MrmrOGF4mGsEQ144dyixLIS Oa3iBHV3OCVfKSOVms9LmpY6/eDIbjcFOle1HpIuzFihc1I85ubaYL+LVZFmNkwtzF2eufSdnr0U 8eV3T7maCUE4TlAgWBGbnSdLzIXy/1R64zQJJ/p+wLKpZ7c5DJaIUhhoSGkchSAqTI9dknUNRbX9 sCvr+pK78nkcyvjRMkgui+KKZiTk7BhuPlvJiITbOQxBtGlpN83Nktu4QHXfVx0hK12QnMEWFTJX L8ycx2J2ESO9KPEr1qlsQcIUrkAExq3OmlUhEjlbZFt9Ixa3k+LQuiA2ncamU/lTE1eIWCYhlUbn KedlFAgGTl1fdu8NaRIwOqpHXVfTkitgayHcdxQGaeMdGLYEjSpYsUa5YHF2cYTvfa9/f61Ra+Jr YIi2IOvP12bTYkHNEU0NeH42iR/AYEmKkmelDe40BsB/7t3CmVm3znQ0c8OaOr3JSMESnI12JFly Mes+umKjRJOb/chpmc5JnZs1u7H1Y924zwKNoyzmiESslEJlJtwMrsxblDuwjeIk+Q+LhKkVKdN2 qPdC/xQAiJdzT/mfkOYNPv7Su6ddzSGijtxGvd4Q8iLUGDaVfCjuiuybEUwCoaGA16oUFi7J/cMU zlj74M4eFzShCoMM2RW5a8H+L/Z6ym4rvzeBRqVET01tJAM11MTrlAsWZBVHeN4Xu7a3GrXkwmoi QxpOSLnmVib1seZtC3LuvSuF/T0Dy1Jmp6kO2CLnGAgxE1ZOv3/t4MEey4HjfkuWfPGNRZfHM3Uj oVCQSBYxOTjAzEn7CxCE5BNqOjV2ijyL6eDPSy/TtvLhmFwF0DcazR1EEUiyl2UupNZ9dU6FQbqY m5TCj3Wzs+dkLTJZPmFqPAEABxmJJTEJgHsEovJk3Lh4CslZkC/OX5O19O3eA7K4tfdPm4Vj5ABC RJxek9vggTgMGotG5c1MvjLOauVCEFdQsEY81QfiZ3R1OswdMmRXxGfmC9gXEaJJXGJc8gkYM1ha +2z2gtQ/LlBSvzh6+zfabgPyWVx8GdDTSSHCArYEDo9V+wGYRlcmVYB1nwxoHn7vzJOp0Mjx4f2c xDXz+ElxHMfG5i/jCQ9s3rOF1HjmFGqop1rdrKcV1/YepZhHNGj/yYHWxSXx0yjgEefLH9dy2O6j B8I2sa2uSzfX79H0o5LVBasyw8f/WPeRdkwVBhaQauZ3DXxd88ynY4NLy568mzRnGb/i2zEk0Kc6 cWLgcK+zBhribkLAZYUzRL6mXR4UxaqPd7fyLQ3VfiNP27Y0ge0ea2g3j9abHaFA7TcnRXQ4/fLy AqdvxEphrsq5KSbc9E7XF40Grb8AA37ZBAzBDElc/phm20c1D9XTKftGm7142rgNQpCmXMT37sZT 4eGRrWZvTJOh83IFMahu6lLtsvtdOu2uT4/3KxPm57PjC8GxFs2mT2uJVNC0Q3MQlt3xuojd0H6C DrPvmf0JS/fhW0P/eAIM3zf12lKZ5LwBmMCCRkPd9s6GAUzfofruy7BpfsGsFD43I2EaYD8SE8GF fAUWHvB4Rl1JS2ZzpZX+7x475D4Ijx13+aObLAQQDti7hqpqVIc6HGpX+NRXEXhB0eXlkkCvuVPL u+PNoryekQ1P9HeU2i0YkMXkybNprAP6A5sbMZ9hYzUhfWLBBob28InhbismrWzaYlJOmZOeHQPa Tg5XduIr74nNDOq6kIhh2Fg7YM3Kl9ABcsqMbPuqMa0Y039pa/7D1E+vlviqO091GRr1AVVdzxbQ Wjy/ZE6MrABBd2xpfD45stxk3LfL6Z2hjAuYumqchqFIU8NYFt7XhmLo8d6GRfK5wl86C581Dqvv Pfj67UL4I30vA55blpA0GswDho8DFCKGHYP78KM+kMui20cOf95UFY54m3v3MGzx+WkzcsVcu6n9 pKqjR3UAwZH9dZ9x9PLyvAWJ/NSiyLaavs+/xUbtY5vGXPpl2fnxknAEDX/d+KbUm3S6Z5MJcWrs J0yBPCXrfLkil3CqsYbqnqOd+sEhnPbt6c+LEudcmZva2b/LhFfcUHgl6D/6fsPbnfbFboSYYAIm IhZbX01n5U5NjyEUOd7ybdA8e1VJuZDqPVqzbN7wdAAAEbBJREFUs8+v7fI5ndrdm06aMkX8RpvR 4XadVkUQHK/prWQGw95gQ11PqwVX1ap297vH0IHjXwQC84qvLI8VAhQqgHv0tk8+Pem2OuusnMI7 kzKZbDHgt1OoggQuaDIFjoapYj6fxZX0DTVtbfmyF2itc6hD4S9qDXdekzxR5ikKNC4AX316JjU1 NLDDPXhd2aup/NTcyA6SgdtwjXn0C7PXtiw3/yLzDKoePFnddziCoTXt37B1nMKcVYUCVDXWfLLr AMnAfoD37WmoOGnBqpwsJjf3zrI/zK/62sjMuaXi/llSAQVACulsDqXJiUAJSgUeHLKZmoITOmOh uqP9x4IRSe1AYYCwGi2NKOzsDQ0OGJp7HKNjmh1hFKkZ2frZyfa0xIrYcEe7YUDFT2sgRyGb2YWr Dna2L52/iMWR+ULtla1f13v3VwdVHEPLWGpykjAxF2ac0Gz7pt40Orqhi5a8bsaTIkkmoGkhF58S thjxoAe9kIjNCDlGBxH35dl35rMMX3Z81GwasPojwOQE/HvhkochoZrhHbvUe447m08aTvX4LOXx r/21Ym4CPzEZMbaNfPudoarKeEbIn7E6f0FaXM4sboyqf+MWXc2RsTO6iHx51rXzMiviKWDNyP69 6t1H9Y1y2SMfrPoTz13zdvvuUZRJRcAxX1eHb1SN5F5VsHSZVNbX8+UOU+1JU5MRDThRQUpMUdhz eq96f5PtdI25wxKSPDzrkUXxUb8SAvVUqQ9t0YyVJ14xW5nB+TVRnEjQfrjptaf6do2EnVrvcL0x UJQynWva9YyqNoD7GXiy37q/yqViMoSlsnxV73tvtn1yMmDx4dpGc229RXB18RST/vCbfbu6bPVn LC2jaNot5TfNkSt+YSwhCFIlvOR4JHByuGPY63WgNgece1vRfCWby0VCb6v2NFua23xGf8QZw5VO j1F+2fH2+4OHrKjfH+xtNNW4ocU3FJQmcbgDY8e/1ew6MlbpRNKuyr+yNCbwyeEnW3HsjhmvxbpP fas9rfJBCvHU6Re44RCor3l4x7rWbzy4U+vprtU7S1JmpQti4hRTU32OD9XfVBsqq8wqkDfr+qJV C1LLs6h81BVkctKF/sZ+PPsW0rjxj+w688wr6uOjYZ8loGmznpLLl5UJiHdOvNIa7Gs2n2qw6eJF s+4ouSpHyAVhFt02dFB7oFJXWWPuLoh7cEWasqbtrXdH6iyB0XbLaSOQOishT8LmEpbeb81Hm421 PQ6GlIn0BkLp0ulF0mj1n7qRQ0f0J6uMdQLqkmtLFsKe2tePPrrN0WdETSp32ylDqCJrTmHClAIA qe39bKeh6qTFkBn/50crrgHGvtyuPqEK9Cvpsuqez/pQBMFTriiYLfqleybYyOC2g+Z2CcHerd3L Yq95eflTc5XxSl5CrH+gTrN9F6kC5oYkycq1BTP9/e/d3vGdC3EN2Ov7/P5k6eyCGK5uaPvTDW/s sQ76cFznbu5ydZdk3DY9LjEBxE+p9uwY219ttU9PufeFeaszlEUKr2bj8JYzptZmb9iPWdnMrFnx sxXs8+06IuI60rPxsZbP1EFbIKLtsdepghl/zM1qPfXQFz5Nm6221tIWhjNX5909Mz5hohjtkGrs 0CtVz1V6RgOYSeVqrnHJr8krE0PG9Ttu+tBUr0KcxkDvGaOWFvG0uds6PR00jA/4B5tcnHwWctDW H0DkQePnb2mqteGA2a9qsZxKTrymTBwDUWCStt1Du6pMdaMetFixYmHO3JlCeVC7fafuyAHtsTrH 4Lz0u1fmFioZAqO5YdvIrmqrYTTsRnGbRHTd8sQJUz9CDICoUe89oq85ZW6RMC5bXbK8UJIYh/nr 1Ae2jx44abUvzHj02bmrZKwJE1dFWhsffb53vz4S1DgbW+ydStm1Zbzgkd5Nj7V+TjLQH9H02M6o QwVrc3LpMI3NEuq7vwzGLHpw5m3JbCoFZKZIM5iu0S1jew9pD54wNQsF11xfvkhx4cmqv+eFqncG CASLpEBo12DAwkJRtd2RJRJ9Q46KY6c8WMQb7G6xdFDgUjmlY2P/8bEIJwZHGp3tmqB+ACm7r3Qq j4rUtX1+yFLf4hhwYi6cklihLE+JiWNY+r4d/e6UoarFoS+S372yoCKDFy/0dJwa/W6P/niVpTEr bu31RVMJa9W69q39zubT5vqBIG9R9g1XpefxJ9Oc/V649Ik4kLDLFQmjBIYgCEhlCxl8VrRqAoGi QW/I4w1FICqTy+CyaXSIQiFwJBBxO3x+AKJzWTw2lUEFKRiGBEMuZygIgCwhm3ycRmBhPxLEARAG YdIcIxsHKAwO2QKBBiIOmz9MpfHGF/0wA6ZFQt4AHsGiUfQonS0U0Ti0s/GaBB5CfD4EY9K4LOqv TKJA4GE0EPwhoAJm0VgQHvahYYJcw4N0ChGJEDgE0pgwA8eCIQz5/oiKQqFzabRw2OOIRGAKHkYw Bo3DZ/JovypNNUGgWDgQCfh96vePPfrRaNwXN7y+RCkH8bDbb/URIJcerbgOQ3QmRA2joQj+o9gP iMOmwjiO+ENed8iHg1Qug8ehMakgEQj7EAJg0bgAFvRjCEAhGchkTLC3RyBo2I+Gfvz5Z0MwyW71 hGyeMEGlsvgMLpNKg4igwWoOETANHXtv69IP0LVnHvg4F8bCSCCE/xA3wqBy6CButlsAJoxESCpA LlvEJd8/zhUMDXlCTj+KMRgcNsQhr0Z+xH8IZLKo0ZJ3KBJw+a0BCilRbBpAfjNI0k+HQLLzA4jL HQpBpJwwuAwqjUKQkhb4kfsQlR3lAIiRohXxuP0BEGYK2AImTCW7L4hGg07oEAPDorUJQbIR+s/F Lf8IeDhk3bf/+sdUyo+vfzpHKODADObZpA2krKMBT9Djj6AwjcVjkEJICnbQi54LlQEpVJJ4UipI kgJo6PtIEQoFZFG55JCIRYdjty9CksrlRTUoelpHcsATdPgxmMVkQQApgXQm2cyFwa8EEcGCAfSH sBwQZJJiGfTpHTipR6EIRmHSeQKSjRPv7BLk2wNI8If+ozC4URXGAyHvj2J9IBoI4aSuEzhMoRLk 1ALQSMaFcBQGaRA5NvxEALhnJQ3Dgp6wK4AATCqblKtoeg0cDSFep88bIcie5vJp7HMXI15X0E+h MunRtBgEDeZeLBiMZLafFIBgGIaYHDqHQSVJJckK+8ghKByAqFxSAVkT5M859zSK+APYuRAykv8M mJRVIIKFfsxACGRxxruAVE1fwBEgWGI2558rajyChNykbCIRKp0roEf1YgJtJx8khxBS60AaSGpY 1CWHQprK0UEMI0ew73lFoUEsGgUNoGF8nMMYEQ0bAyhMPp0ebSTo8IQjNCaHGu1WOgumwyBIKqY7 6CAtbxYpaXCUgeRoSyqRJ+D2IziVzuLTo+lQ8IhbHwwxIJyUACrMELAEDPj3y2U0if8LmbD+e2AZ /uapygc3mM46dNzXft+zhYKL59n4H0LYXrN6z937tV1nf15edmbv8or/WZJ+P2DG14489GLTt57x X+uuGnkxP+l/lqJJTGIS/2sxOQH//4Sw39iv7dF5w6SJB7DSZmWmcy4MGfofBx7UjHX2mPRBDEpI KJ0Sr/yfJuj3REir7ekzmpCobQ1kZM3L4v8buUgnMYlJ/Ffgt5uAo/lmfq96dv8pJvOmTmISk5jE JH5n/FaH7SG3qlbd7EIulivuXwJzuw0a6+iIZdSNXJrsaEQ0B+QEKdwiAd0pTb0lPJmDbRKTmMQk JvH74beagA0DG+/Y+WCbP/hvPk+4j9S+8sie++/deX+N9d9t5CcNRky29gM9VUPu81uzj2394747 L81bJjGJSUxiEpP4ZfitJmC+tOSa/KVy2nknlAQarZuG/oJdb4gjlCn4wf3mXYbQz6WX/75lDItE UORcywQeiYSC4dAPVi3q7dZ89/zpTY0W93lPMgV512WvPq8c0HjRhwuLQQA4hkQQ5GdLKUxiEpOY xCQm8a/xG7jwEP7u/qM1BjMXFwZCGMACcDSo1hzdOzrGhzB7ZGgUTbkqf80MhYIxcRgO4bAONKpr x9D42cKC9cBhcm61mc/s6GrgS0pmKOLPaE6MhGLXFsxJ5DGHujbvNhslMQunx7j2de0w0bNX5v4h j2o51LezyWUIEgCNs2LdrOWxEOqwDrWNdRnCqN7S10lziITKOC4PpgCj/dve0RnToRh/IACcLfuF +VWa6q3qahMSAMGMNflrp8v4dmvrru5GnBkTRLWDHu205LUr0qYI6b++0uAkJjGJSUxiEuP4LSbg sM7QfaR9c0fQz0m7oljExvGIWnvypbrNbJpMwaCbgsf1uCxJcFUqdwIHUZel5cMz63eo1DK6yIYM jF/DXc6OrXUvMdKvUzBXV/Vv3mbOKEsujecxzdoTr7Ts5nEPFPApNpt5hOgVCGfxoZZjPS2EOIUf 7N3Q85RCUvBgBreh9/NN6jOOCPhl25NH+phLSh67M3+egApaDW0HmzZRGPHXcZfOUQgBItTd/cW7 9RuqAtxUFm3AsqvJWP3swvdTAl1f1704TFMmc2J9gZ4aLTMlJn16nHTSb2sSk5jEJCbx7+E32IIG eVNLb/lb0VyQ5vSi0d1jCGZnJM+fQ0PliiXPrnztutQUn8sUiKATPEtaz6p9u3qbC/L/9PTKF+9O K4lepMASybSlSUlOxEZwM66QJiQCgXDUmwoqnPbAHWynM9RXkv7w+2u/+e7a19emJ3K5slRuLOEO Ot3DBNLeaXRAVHZ+xlWXJ5dy2TnL8+96ZM7DK5JyWOMx81klf/5o7h8MqPts6VnUr90+dOBbl+ye eS+9e+VHm+ZfXTf23bN1zRxx2SxlHJMruW32c4/nzMWc49USJ/ehJzGJSUxiEv8ufosoUlgoUKYK lXQQpkLRTV0KCPHYsQqIibKSCxSZo72izgg0cdQPEbKFbG6EmSfPzlcWyqyFQNs2KsSgUQUxNCaI gDCNzYToVApCjSadp/BEWVkwwAZXXFO+JDdaZZ1Avb2v9H/zkR28M//yQqqio/pFAIQpIFUmyS8U J3FsviL5vMVpcREEPZvuhSNIzJWmR1PMjyc9x1G/DQv4aKlZ0oxUaVycL4u8qHW7QVpeHEsggsXZ yjzAwWcCOPF9RVXE2tbbjgsyCxMTLlIhbRKTmMQkJjGJ83HJc0EDVn3jzrot27o3NnoNo0bcPNZJ E2XZ1N++3r/fRSH4QbBq9Mg+w1iCuLQkWhD7p9MwhY47Gmp131Ub/LBDtbHxnR7E53ZnL8lOM5vq t40NIRbt/rFDZ9wqPqtoikxw5sQ/blSdRDB92IyMmq08SboAGd3Rv0vlk1wWn+031m2xdqjdzEVZ sxUsyOUd2tdxQOt29HW+/HDVg1jM0hxQ/86BTw91bq72GQ1ub9hugzlKnruzU7O5xw4BruEPKp/o QIL3TH+xiNq2vmp9V5jNR6kdxhNVtlN+NHtxSgGHCjdV3rzg5As15rYkxVWZnIuVUp3EJCYxiUlM 4ie49Bawy9r0Tf8bR1wm8v9221ttNiCh8BqOtUlF4EKv8bTqpN6lQSK2DttACMtjQuftgUM5RQ+s c3kfbPr8vsZvK/iLCgBTq6HGD11ZkjIro23zBwONZ+87rRt0BxMOtr0ZIA1RxPrhwJNFgRU5Bcsz hcnLRMpK1cY7KzdmiW9dw8/f7P+43/t0iYCTKZ65QPzNBs0bRwBgTvy6eXHJsPfYIz1Pn21QZXn/ 5UDfYzElD819gUpwHup492aNDwByn5t78PHy/9fe/as0DIVhHE5syQlFcNNJ8SY6edu219DB1e66 KFhw6Z8k5zRxcZCKkO0UeZ6b+PEt73e3Xj8+H9Nm//H0utp3759FWry9bFK8LsLN7cN2tZwU8/uZ zSMAxjrTKcrY7A7DxWVd/9jSGmJsYz+E8PuryKmm2aVyOqvCyYHd97GLbTkN1eSvHfZvXbdtYqrq qzEPi4ZjG8tQ+SACwGhnGmAA+N9cbQCQgQADQAYCDAAZCDAAZCDAAJCBAANABgIMABkIMABkIMAA kMEXbXpWj/EaHBkAAAAASUVORK5CYII= --Apple-Mail-41-989526752 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit ---- --Apple-Mail-41-989526752-- From hartmans@mit.edu Fri Sep 4 06:05: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 89F7B3A677E for ; Fri, 4 Sep 2009 06:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 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 cX7oFuWOG4IU for ; Fri, 4 Sep 2009 06:05: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 C5DD33A6358 for ; Fri, 4 Sep 2009 06:05:29 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C0C9751C7; Fri, 4 Sep 2009 09:03:18 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Message-Id: <20090904130318.C0C9751C7@carter-zimmerman.suchdamage.org> Date: Fri, 4 Sep 2009 09:03:18 -0400 (EDT) Subject: [lisp] Confirming consensus behind echo noncing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 04 Sep 2009 13:05:30 -0000 Echo nonces were added to either -02 or -03. They had been briefly discussed on the list, but at the time the plan was to present them at IETF 75 and have a consensus call after that. So, this is one of the rare times when we agreed to add some text to the document before we had a consensus behind it. So, echo nonces have been discussed somewhat on the list, in the draft for two versions, discussed extensively at IETF 75. So far we've seen no objections. Normally, silence is not the same as consensus, but I don't really think we've had silence on the topic. Enough people have been considering and discussing the implications of echo nonces without raising any objections that I think it is safe to say that several WG participants have evaluated and understood the proposal. However, I wanted to formally confirm that there are no objections. If we do not see strong objections by next Friday then I'll conclude that we have support to include echo nonces at this time. All the locator reachability algorithms are up for experimentation. I think it would be fair to re-open the question of whether any given reachability algorithm is appropriate based on practical experience. From jnc@mercury.lcs.mit.edu Fri Sep 4 08:21: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 633BB3A6911 for ; Fri, 4 Sep 2009 08:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 oP96edsPJ7cv for ; Fri, 4 Sep 2009 08:21: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 4FCBE3A68F5 for ; Fri, 4 Sep 2009 08:21:56 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D22FD6BE5F8; Fri, 4 Sep 2009 11:21:38 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090904152138.D22FD6BE5F8@mercury.lcs.mit.edu> Date: Fri, 4 Sep 2009 11:21:38 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [#16]: Desire to expand data plane for map versioning or handle in the control plane X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 04 Sep 2009 15:21:57 -0000 > From: Margaret Wasserman > I'd prefer that we use short-enough TTLs to allow new mapping entries > to be detected in a reasonably short period of time without an explicit > signalling mechanism. Well, it's certainly true that DNS seems to do OK without a mechanism for detecting outdated mappings, so perhaps this is a non-issue. I'd be a bit wary of craking the TTLs _way_ down, though - it could cause a rather large traffic load. > If there is concern that this would result in too much mapping > traffic Mindreader! :-) > we could work on a mechanism to extend the TTL (and suppress subsequent > mapping lookups) when there is ongoing successful communication. Interesting idea. I thought about this for a while, and we can do something (although I think it needs either a new control message, or some incredibly hairy user traffic analysis), but there are fundamental limits on what we can do via this path. The thing is that just because an xTR is up and reachable - which is what all the various existing mechanisms give us - that doesn't mean that a mapping that uses it is correct, i.e. "ongoing successful communication". In other words, even if you can successfully send a packet for EID D from ITR Is to ETR Ed, and Ed is up and working, that doesn't mean that Ed is the right ETR. To truly check for "ongoing successful communication", we'd need to be able to ensure that traffic reaching Ed for D is actually getting to D, and that implies either i) some sort of deep analysis of user-data traffic (e.g. to watch for TCP ACKs), or ii) for Ed to tell Is that Ed is _not_ an ETR through which D is reachable. (A NACK is preferred to an ACK, for obvious reasons.) (OK, OK, so the latter is not actually making sure the traffic gets all the way through to D - but to me it's not reasonable to expect LISP to verify that, e.g. interior site routing is working; all it should be required to be responsible for is making sure that the _LISP_ stuff is working OK.) I'm not too big on the 'deep inspection' path, so that leaves the other; we'd need to define a LISP error message (we don't seem to have one at the moment) which says 'this is the wrong ETR for that EID'. Of course, that would be a DoS attack vector, so the response at the ITR, on receiving it, would be just to start a resolution cycle to refresh the mapping. (BTW, what do ETRs do at the moment, if they get a packet which they are not the correct ETR for? I assume they unwrap it, try and forward it, and depending on how the code is written, it may either get re-wrapped and send to an ETR, or forwarded to a PITR.) Still, this whole approach has a limit though - which is that it can say nothing about whether the _mapping_ is up-to-date, simply that Ed considers itself a viable ETR for D. LISP contains a number of features for load-sharing, for primary and backup ETRs, etc, and this method can't detect any changes in the mapping as a whole (at least, not that I can see). I think the only way to do that would be something like versioning; whether that's done in a separate control-plane interaction, or piggy-backed on user-data traffic, is a separate question. (Note that it could also be either 'forward' or 'backward'; i.e. the ITR could tell the ETR what mapping it's using for the destination EID, and the ETR would notify the ITR if it's old; or the ETR could tell the ITR what the latest mapping is for that EID, and the ITR would have to notice if its mapping is outdated.) But maybe I'm missing something? Noel From hartmans@mit.edu Fri Sep 4 12:25: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 AFFD53A6844 for ; Fri, 4 Sep 2009 12:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 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 sxTymXpEhzRz for ; Fri, 4 Sep 2009 12:25: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 CF6EF3A683B for ; Fri, 4 Sep 2009 12:25:04 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 268AF51C7; Fri, 4 Sep 2009 15:24:51 -0400 (EDT) To: Sam Hartman References: <20090904130318.C0C9751C7@carter-zimmerman.suchdamage.org> From: Sam Hartman Date: Fri, 04 Sep 2009 15:24:51 -0400 In-Reply-To: <20090904130318.C0C9751C7@carter-zimmerman.suchdamage.org> (Sam Hartman's message of "Fri\, 4 Sep 2009 09\:03\:18 -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] Confirming consensus behind echo noncing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 04 Sep 2009 19:25:06 -0000 Speaking very much as an individual. I'm not objecting to echo nonces. However, I personally think we'll find they are not very useful. In particular, they are not useful in any of the following situations * square routing * triangle routing (a sends to b, c sends to a) * cannot detect a full path failure: in order to conclude you cannot reach someone you need to get packets from them I think that triangle and square routing will be very common unless we take active steps to avoid them. It seems likely that in any situation where you have multiple rlocs of the same priority you'll likely run into that case if you have a small number of flows. Long term, especially when we take security considerations into account, I think we'll end up with required control plane probing of locators with possible optimizations through the data plane. In that environment, I think echo nonces will serve no purpose. However this is just my opinion. I can't reason about or think about the performance implications until I understand the deployment model of LISP. In particular, the performance concerns that matter for probing on CPEs seem very different than say XTRs at an Amazon data center. Regardless of the above, I think getting data on echo nonces can do no harm. From hartmans@mit.edu Fri Sep 4 12:27: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 564053A6820 for ; Fri, 4 Sep 2009 12:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 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 Oi9v0weI3Am8 for ; Fri, 4 Sep 2009 12:27: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 948543A681B for ; Fri, 4 Sep 2009 12:27:53 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 841DE51C7; Fri, 4 Sep 2009 15:28:09 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Fri, 04 Sep 2009 15:28:09 -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] Soliciting editors for a document on 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: Fri, 04 Sep 2009 19:27:54 -0000 Darrel will be talking to the WG in the near future about how we are going to explore several issues including LISP deployment model. I think we're need to go write up the output of that exploration--probably starting with the current thoughts on LISP deployment model and then adapting that writeup to converge with the WG's ideas. I'd like to solicit people who could put a few hours a week into such a document. It probably should be an internet-draft, as I suspect analyzing the management and operability concerns of LISP will require us to publish that text in some informational form. If you would be willing to spend a few hours a week working on such a document, please let Darrel and I know. If we're not familiar with your work, including pointers to internet drafts or RFCs you've edited/authored would be greatly appreciated. From hartmans@mit.edu Fri Sep 4 12:31: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 32D423A6A01 for ; Fri, 4 Sep 2009 12:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_71=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 OZs7H1BHV60H for ; Fri, 4 Sep 2009 12:31:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 581573A6784 for ; Fri, 4 Sep 2009 12:31:23 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D5A1851C7; Fri, 4 Sep 2009 15:31:35 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Fri, 04 Sep 2009 15:31:35 -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 of Security work X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 04 Sep 2009 19:31:24 -0000 I'd like to ask where we are with discussion of LISP security. In San Francisco, a group of people got together to begin thinking about this. We weren't at a point where we were ready for a presentation in Stockholm. However,I'd li ke to know what current status is, people's thoughts on steps going forward are, etc. I find that like the deployment model, much of my thought about how LISP should change is dependent on security analysis we have not done. I certainly have my own ideas, and if we ever find a quiet moment when I'm not running around reading messages about UDP or vpacket headers, I'll work on writing them up. From hartmans@mit.edu Fri Sep 4 12:35: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 1B1AE3A6A01 for ; Fri, 4 Sep 2009 12:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 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 M0O7UHmKgDDC for ; Fri, 4 Sep 2009 12:35: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 347BA3A6A46 for ; Fri, 4 Sep 2009 12:35:34 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 16F2951C7; Fri, 4 Sep 2009 15:34:56 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Fri, 04 Sep 2009 15:34:55 -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: changes to sha-1 and RFC 4302 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 04 Sep 2009 19:35:36 -0000 In version 04, Dino proposes to move from RFC 2402 AH to RFC 4302 AH, and to move from hmac-md5 to hmac-sha-1. I don't object to this particularly, but I want to make it clear that this doesn't come anywhere closing to addressing my issue #2. I did call out the use of MD5 and the old spec in issue #2. These are areas where everything else being equal, we probably could stick with MD5 and the old AH if we really wanted to. We'd have to do a bit of selling our position to the security area, but these are the things I brought up that I least care about. The areas that I feel most strongly about are the areas that I believe Dino objects most to changing. I understand I still owe the WG more justification. From jnc@mercury.lcs.mit.edu Fri Sep 4 14:23: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 F0BCE3A67EE for ; Fri, 4 Sep 2009 14:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 hC0h9Sdj+3qZ for ; Fri, 4 Sep 2009 14:23:11 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 41AC73A6811 for ; Fri, 4 Sep 2009 14:23:11 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 781DA6BE5CB; Fri, 4 Sep 2009 17:23:29 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090904212329.781DA6BE5CB@mercury.lcs.mit.edu> Date: Fri, 4 Sep 2009 17:23:29 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Confirming consensus behind echo noncing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 04 Sep 2009 21:23:12 -0000 > From: Sam Hartman > All the locator reachability algorithms are up for experimentation. I > think it would be fair to re-open the question of whether any given > reachability algorithm is appropriate based on practical experience. I honestly don't recall, at this point, how many problems have been seen with reachability in testing over the last couple of years. (Maybe some of the people involved in testing can add to this?) I do know that a lot of the organizations which are interested in running LISP have expressed concerns about reachability, and I do think that that has to be a factor for the WG. (Clearly, if people aren't going to run a protocol because of problems they perceive with it, then we'll never get to the point where we can find out whether or not it works in practise...) It certainly is the case that the design team has put a lot of time/energy into efficient, robust and timely reachability testing algorithms over the last year or so, and although I can't speak with 100% certainty as to the reasons why, I don't think we would have done that without a good reason (either user demand, or problems seen in service). Noel From mrw@sandstorm.net Fri Sep 4 14:33: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 784C63A6811 for ; Fri, 4 Sep 2009 14:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 NBuxOuqAHN1X for ; Fri, 4 Sep 2009 14:33:52 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 6F7FE3A6821 for ; Fri, 4 Sep 2009 14:33:52 -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 n84LXdUN040709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Sep 2009 17:33:40 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <0738CF8A-EBB2-4D1E-B1A5-6371BC26AE4F@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: Fri, 4 Sep 2009 17:33:39 -0400 References: <20090902225425.834666BE641@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [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: Fri, 04 Sep 2009 21:33:53 -0000 Hi Dino, On Sep 3, 2009, at 9:09 PM, Dino Farinacci wrote: > > (1) Leave the N and L bit settings as defined in -04. They are used > as "field-enable" bits. > (2) Don't have an R-bit since we cannot define how to use it or how > to ignore it. > (3) The E-bit is still used for echo-noncing. > > Now when the research guys want to use the Nonce and Loc-Status-Bits > fields for a new use, all they have to do is set N and L to 0. > Implementations which are spec compliant use the N and L fields when > the "field-enable" bits are set. Otherwise, they just decap the > packet and don't use those fields. > > How does that sound? That would work. If we ever get to the point where someone wants to overload one, but not both, of the N & L fields, we can talk further about how to do that at the time (when we know what we're actually trying to accomplish). Margaret From dino@cisco.com Fri Sep 4 15:28: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 EFCE53A6936 for ; Fri, 4 Sep 2009 15:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4LdJaXtXI5g for ; Fri, 4 Sep 2009 15:28:50 -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 75E2A3A6882 for ; Fri, 4 Sep 2009 15:28:50 -0700 (PDT) X-Files: rfcdiff-lisp-03-to-04.html, draft-ietf-lisp-04.txt : 164206, 149359 X-IronPort-AV: E=Sophos;i="4.44,335,1249257600"; d="txt'?html'217?scan'217,208,217";a="187904034" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 04 Sep 2009 22:29:11 +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 n84MTAAi001324; Fri, 4 Sep 2009 15:29: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 n84MTALf010416; Fri, 4 Sep 2009 22:29:10 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); Fri, 4 Sep 2009 15:29:10 -0700 Received: from dhcp-171-71-55-193.cisco.com ([171.71.55.193]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 15:29:10 -0700 Message-Id: <253ACAA8-4969-4424-9D95-578399C01BBB@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <0738CF8A-EBB2-4D1E-B1A5-6371BC26AE4F@sandstorm.net> Content-Type: multipart/mixed; boundary=Apple-Mail-49-1065726641 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 4 Sep 2009 15:29:09 -0700 References: <20090902225425.834666BE641@mercury.lcs.mit.edu> <0738CF8A-EBB2-4D1E-B1A5-6371BC26AE4F@sandstorm.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 04 Sep 2009 22:29:10.0492 (UTC) FILETIME=[1F8691C0:01CA2DAF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=322263; t=1252103351; x=1252967351; 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#16=3A=20map=20versioning=20re solution |Sender:=20; bh=LKlIN4kIIREbehY/UaafFUHhMQ/BOaENfEnXh5vRftg=; b=Yd8mrnzIqZkIf2Y4NV0zNDKHxzFFOQy23ou6JQVAuSczlxY88cMXCDY8vG l+/bvY2RJUFONTj4N0Dq/uLQu8sVL6BOYECgt54viowzGBQjH6O5K6XJLWmz giklLhW9on; 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] #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: Fri, 04 Sep 2009 22:28:51 -0000 --Apple-Mail-49-1065726641 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Right, agree. I have enclosed the latest diffs and proposed draft so everyone can start looking at the latest and greatest. Dino --Apple-Mail-49-1065726641 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 8, 2010                                          D. Lewis
                                                           cisco Systems
                                                           July 27,
                                                       September 4, 2009

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

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 8, 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 35
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 36
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 38 39
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 40
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 39 41
     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 43
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 43 45
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 44 46
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 45 47
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 45 47
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 46 48
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 47 49
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 50
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 50
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 48 50
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 50 52
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 50 52
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 52
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 52
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 52 54
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 52 54
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 54 56
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 55 57
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 56 58
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 61
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 59 61
     14.2. Informative References . . . . . . . . . . . . . . . . . . 60 62
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 63 65
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 66

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 statically 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 prepends 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
      statically 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 prepends 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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

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

   OH

   Outer 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 the ETR. packet for decapsulation.
      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 decapsulation, otherwise, it is silently dropped.
      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

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

   LISP Locator Reach Bits:  in the LISP header are nonce-present bit.  When this bit is set by an ITR to
      indicate to an ETR 1, the reachability
      low-order 24-bits of the Locators in first 32-bits of the source
      site.  Each RLOC in LISP header contains
      a Map-Reply Nonce.  See section Section 6.3.1 for details.

   L: this is assigned an ordinal value from
      0 the Locator-Status-Bits field enabled bit.  When this bit
      is set to n-1 (when there 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are n RLOCs in a mapping use.

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1.  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.

   rflags:  this 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
      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.  When the E-bit is clear but the N-bit
      is set, an ITR is either echoing a previously requested echo-nonce
      or providing a random nonce.  See section Section 6.3.1 for more
      details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator
      Reach Status Bits are numbered from 0 to n-1 from the right least
      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 is
      reachable. 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 Reach Status Bits
      setting in an encapsulated packet MUST reflect the mapping for the
      EID-prefix that the inner-header source EID address matches.

   S: this is the Solicit-Map-Request (SMR) bit.  See section
      Section 6.5.2 for details.

   E: this is the echo-nonce-request bit.  See section Section 6.3.1 for
      details.

   rsvd-flags:  this 6-bit

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The outer header Time to Live 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.
      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 is set to solicit the other side to send a Map-
      Request containing this nonce.  See section Section 6.5.2 for
      details.

   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 (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

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

   When doing Re-encapsulated Tunneling:

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

   o  The new OH outer header Type of Service field SHOULD be copied from
      the stripped OH header Type of Service field (with one caveat, see
      below)..
      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 that is labeled
      'Rec' above and occurs the number of times equal to Record count.
      For this version of the protocol specification, a receiver MUST
      accept and process a record count of one or greater but a sender
      MUST always set the record count to one.  Support for requesting
      multiple EIDs in a single Map-Request message will be specified in
      a future version of the protocol.

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

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request, it may
   originate a "verifying Map-Request", addressed to the original ITR.
   If the ETR has a map-cache entry that matches the "piggybacked" EID
   and the RLOC is in the locator-set for the entry, then it may send
   the "verifying Map-Request" to the original Map-Request source.  If
   not, then it MUST send it to the "piggybacked" EID.  Doing this
   forces the "verifying Map-Request" to go through the mapping database
   system to reach the authoritative source of information about that
   EID, guarding against RLOC-spoofing in in the "piggybacked" 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|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.

   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:

   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: this bit is reserved for use by the LISP mobile-node design
      documented in [LISP-MN].

   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.

   o  A "gleaned" map-cache entry, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply and or that stored in the database
   mapping service does not database system provide any reachability status information for Locators.  This is done outside RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the mapping service.  See Routing Locator Reachability Algorithms described in the
   next section for details. section.

6.3.  Routing Locator Reachability

   There are 4 methods

   Several mechanisms for determining when a Locator is either
   reachable or has become unreachable:

   1.  Locator RLOC reachability is determined by an are currently
   defined:

   1.  An ETR by examining may examine the Loc-Status-Bits in the
       Loc-Reach-Bits from a LISP header of a an
       encapsulated data packet
       which is provided by received from an ITR when ITR.  If the ETR is
       also acting as an ITR encapsulates data.

   2.  Locator unreachability is determined by and has traffic to return to the original
       ITR site, it can use this status information to help select an
       RLOC.

   2.  An ITR by receiving may receive an ICMP Network or ICMP Host Unreachable messages.
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  Locator unreachability  An ITR which participates in the global routing system can also be determined by
       determine that an BGP-enabled
       ITR when there RLOC is down if no prefix matching a Locator address from the BGP RIB. RIB route exists that
       matches the RLOC IP address.

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

   5.  Locator reachability is determined by receiving  An ITR may receive a Map-Reply
       message from a ETR's Locator address ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  Locator reachability can also be determined by receiving packets  When an ETR receives an encapsulated by packet from an ITR, the ITR assigned to
       source RLOC from the locator address. outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   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 an encapsulating ITR closest to the Locators about
   reachability for all ETRs at the source site.  The  CE-based ITRs at the source
   site can determine reachability when running their
   IGP at relative to each other using the site.  When site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route into the ITRs are deployed on CE routers, typically
   a default route is injected into the site's IGP from each of the
   ITRs. site IGP.

   o  If an ITR goes down, the CE-PE link goes down, fails or if the upstream link to its PE
   router goes down, the CE router withdraws the fails, its
      default route.  This
   allows route will either time-out or be withdrawn.

   Each ITR can thus observe the other ITRs at presence or lack of a default route
   originated by the site others to determine one of the Locators
   has gone unreachable.

   The Locators Locator Status Bits it sets
   for them.

   RLOCs 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 encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit numbered as 0.  So,
   for bit.  For example, if the ITR with locator an RLOC
   listed as in the 3rd Locator position in of the Map-Reply goes down, down (ordinal value
   2), then all other ITRs at the site will
   have clear the 3rd least significant
   bit from (xxxx x0xx) of the right cleared (the bit that corresponds to
   ordinal 2). Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will look check for a any change in
   the
   Loc-Reach-Bits value. Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to the Locator an RLOC that has just gone
   unreachable. is indicated as
   down.  It can start will only resume using the Locator again when the bit that
   corresponds to RLOC if the Locator goes from 0 corresponding Loc-
   Status-Bit returns to a value of 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 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 ITR 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 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.

   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 more secure to reach an authoritative ETR,
   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 have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   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,  Two are the Echo-Noncing and
        RLOC-Probing algorithms which is are documented in this
        specification.  The other two are third is 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.

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

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.

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, Sam Hartman, Michael Hofling, and Pedro Marques.

   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-49-1065726641 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-49-1065726641 Content-Disposition: attachment; filename=draft-ietf-lisp-04.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-04.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: March 8, 2010 D. Lewis cisco Systems September 4, 2009 Locator/ID Separation Protocol (LISP) (PROPOSED) draft-ietf-lisp-04.txt (NOT SUBMITTED) 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 March 8, 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. Farinacci, et al. Expires March 8, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 . . . . . . . . . . . . . . . . 35 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 36 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 39 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 40 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 41 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 41 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 42 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 43 7. Router Performance Considerations . . . . . . . . . . . . . . 45 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 46 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 47 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 47 Farinacci, et al. Expires March 8, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 48 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 49 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 50 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 50 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 50 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 52 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 52 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 52 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 52 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 54 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 54 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 56 12. Security Considerations . . . . . . . . . . . . . . . . . . . 57 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 58 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 14.1. Normative References . . . . . . . . . . . . . . . . . . . 61 14.2. Informative References . . . . . . . . . . . . . . . . . . 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 Farinacci, et al. Expires March 8, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 8, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 8, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 8, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 8, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 statically 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 prepends 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 statically configured. Farinacci, et al. Expires March 8, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 prepends 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 Farinacci, et al. Expires March 8, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 8, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | | Farinacci, et al. Expires March 8, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer 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 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 MAY be transmitted as zero by an ITR and when received by an ETR, MUST accept the packet for decapsulation. 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 decapsulation, 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. 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. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See section Section 6.3.1 for details. Farinacci, et al. Expires March 8, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. E: this is the echo-nonce-request bit. When this bit is set to 1, the N bit must be 1. 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. rflags: this 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 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. When the E-bit is clear but the N-bit is set, an ITR is either echoing a previously requested echo-nonce or providing a random nonce. See section Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least 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 outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Type of Service field (with one caveat, see below). When doing Re-encapsulated Tunneling: Farinacci, et al. Expires March 8, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer 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: Farinacci, et al. Expires March 8, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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 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 Farinacci, et al. Expires March 8, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires March 8, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 | | + 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. Farinacci, et al. Expires March 8, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D1 |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: Farinacci, et al. Expires March 8, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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 that is labeled 'Rec' above and occurs the number of times equal to Record count. For this version of the protocol specification, a receiver MUST accept and process a record count of one or greater but a sender MUST always set the record count to one. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. 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 Farinacci, et al. Expires March 8, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request, it may originate a "verifying Map-Request", addressed to the original ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map-Request" to the original Map-Request source. If Farinacci, et al. Expires March 8, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 not, then it MUST send it to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" 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=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | 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. See section Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is enabled for the Echo-Nonce locator reachability algorithm. See Section 6.3.1 for more details. Farinacci, et al. Expires March 8, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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: this bit is reserved for use by the LISP mobile-node design documented in [LISP-MN]. Farinacci, et al. Expires March 8, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 [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 [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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 8, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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=3D3 |P| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | 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. Farinacci, et al. Expires March 8, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 8, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. Farinacci, et al. Expires March 8, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the 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 Farinacci, et al. Expires March 8, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 are injected 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-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 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. Farinacci, et al. Expires March 8, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 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 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. 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- Farinacci, et al. Expires March 8, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 obtain those benefits, especially if the 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. Farinacci, et al. Expires March 8, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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- Farinacci, et al. Expires March 8, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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-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-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-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. Farinacci, et al. Expires March 8, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the 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 ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- prefix uses is the one copied from the SMR message. 3. The remote xTR retransmits the Map-Request slowly until it gets a Map-Reply while continuing to use the cached mapping. Farinacci, et al. Expires March 8, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending 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 more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. Farinacci, et al. Expires March 8, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 8, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, Farinacci, et al. Expires March 8, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 8, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 8, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 8, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 8, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Interoperable implementations have been available since the beginning of 2009. We are trying to converge on a packet format so implementations can converge on the -04 and later drafts. 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. Farinacci, et al. Expires March 8, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 8, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts 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. Farinacci, et al. Expires March 8, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. [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, Farinacci, et al. Expires March 8, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 September 2007. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 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. Farinacci, et al. Expires March 8, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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-02.txt (work in progress), 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. Farinacci, et al. Expires March 8, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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. Farinacci, et al. Expires March 8, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, and Pedro Marques. 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. Farinacci, et al. Expires March 8, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 8, 2010 [Page 66] =0C --Apple-Mail-49-1065726641 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sep 4, 2009, at 2:33 PM, Margaret Wasserman wrote: > > Hi Dino, > > On Sep 3, 2009, at 9:09 PM, Dino Farinacci wrote: >> >> (1) Leave the N and L bit settings as defined in -04. They are used >> as "field-enable" bits. >> (2) Don't have an R-bit since we cannot define how to use it or how >> to ignore it. >> (3) The E-bit is still used for echo-noncing. >> >> Now when the research guys want to use the Nonce and Loc-Status- >> Bits fields for a new use, all they have to do is set N and L to 0. >> Implementations which are spec compliant use the N and L fields >> when the "field-enable" bits are set. Otherwise, they just decap >> the packet and don't use those fields. >> >> How does that sound? > > That would work. > > If we ever get to the point where someone wants to overload one, but > not both, of the N & L fields, we can talk further about how to do > that at the time (when we know what we're actually trying to > accomplish). > > Margaret > --Apple-Mail-49-1065726641-- From dino@cisco.com Fri Sep 4 15:36: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 9619F3A6358 for ; Fri, 4 Sep 2009 15:36: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 ks1V5wde03Ii for ; Fri, 4 Sep 2009 15:36:03 -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 AC2003A6945 for ; Fri, 4 Sep 2009 15:36:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKgzoUqrR7MV/2dsb2JhbADBKohAASoIkAwFgkAIgU6KaA X-IronPort-AV: E=Sophos;i="4.44,335,1249257600"; d="scan'208";a="187904765" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 04 Sep 2009 22:36: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 n84MaKWi012673; Fri, 4 Sep 2009 15:36:20 -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 n84MaKnH022908; Fri, 4 Sep 2009 22:36:20 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); Fri, 4 Sep 2009 15:36:20 -0700 Received: from dhcp-171-71-55-193.cisco.com ([171.71.55.193]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 15:36:19 -0700 Message-Id: <62EE7C69-F737-451B-BFF5-532ACCFB10FD@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, 4 Sep 2009 15:36:18 -0700 References: <20090904130318.C0C9751C7@carter-zimmerman.suchdamage.org> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 04 Sep 2009 22:36:20.0013 (UTC) FILETIME=[1F8A45D0:01CA2DB0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2102; t=1252103780; x=1252967780; 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]=20Confirming=20consensus=20behin d=20echo=20noncing |Sender:=20; bh=upY3q0NsLAyWPCexCqoDf5rxTwebigyeTt6GiqFiVzo=; b=qv6N5xM4w0CmDzOUlF05+93NfTCl3I8LtyAav8lqjMSCgd6vo/oI07Vd2Q VWv4+cjfA5jN/CTRqMlskweHvYPyXUjCH8h2HYrMvy+/f0gRkpCE+jHmXejK dx0LPH9CmUAXsKVkllg5g0koV+MdxVQ+XLTQDTTJ7jCGVvfznSopQ=; 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] Confirming consensus behind echo noncing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 04 Sep 2009 22:36:04 -0000 > Speaking very much as an individual. I'm not objecting to echo > nonces. However, I personally think we'll find they are not very > useful. Echo-noncing is useful because it can avoid explicit control-plane probing. And we envision people will use active-active multi-homing so traffic will be flowing in both directions between a locator pair. > In particular, they are not useful in any of the following situations > > * square routing > * triangle routing (a sends to b, c sends to a) The top 2 cases are one in the same. > * cannot detect a full path failure: in order to conclude you cannot > reach someone you need to get packets from them Echo-noncing is a unilateral protocol. So the other side will detect its forward path is down. You don't have to detect your return path is down. > I think that triangle and square routing will be very common unless we > take active steps to avoid them. It seems likely that in any > situation where you have multiple rlocs of the same priority you'll > likely run into that case if you have a small number of flows. You run into the case if one side is doing active-active and the other side is doing active-backup. But that means that echo-noncing can be used on each active side of each site. Dino > Long term, especially when we take security considerations into > account, I think we'll end up with required control plane probing of > locators with possible optimizations through the data plane. In that > environment, I think echo nonces will serve no purpose. However this > is just my opinion. > > I can't reason about or think about the performance implications until > I understand the deployment model of LISP. In particular, the > performance concerns that matter for probing on CPEs seem very > different than say XTRs at an Amazon data center. > > Regardless of the above, I think getting data on echo nonces can do > no harm. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From vaf@cisco.com Fri Sep 4 17:09: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 86EAB3A69DF for ; Fri, 4 Sep 2009 17:09:22 -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 hkgiDCgd344J for ; Fri, 4 Sep 2009 17:09:21 -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 8E3A33A69A6 for ; Fri, 4 Sep 2009 17:09:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK9JoUqrR7O6/2dsb2JhbADBCohAAZA8BYQW X-IronPort-AV: E=Sophos;i="4.44,335,1249257600"; d="scan'208";a="382423407" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Sep 2009 00:09:43 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8509h5Z017373 for ; Fri, 4 Sep 2009 17:09:43 -0700 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n8509hFO028786 for ; Sat, 5 Sep 2009 00:09:43 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 n8502tWI007149 for ; Fri, 4 Sep 2009 17:02:55 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n8502tB1007146 for lisp@ietf.org; Fri, 4 Sep 2009 17:02:55 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Fri, 4 Sep 2009 17:02:55 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20090905000255.GA6807@vaf-lnx1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1742; t=1252109383; x=1252973383; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20[idsubmission@ietf.org=3A=20New=20Version=20Not ification=20for=0A=09draft-ietf-lisp-ms-02] |Sender:=20; bh=DySbPk3gq27WSKb97tYgAB+I4qpEZ2gyUVMAM5UgNyw=; b=wHTgy/ZiJ/kwX+Yr6nwrZ7/o3YIjcYj+8BbN2Gyd8UfsziISMO9Gu3p0mb Y/AwHTCsIrAz+D+gRbj+3TUJxdv1C9zbvozqwS5tcOEok7+MB4XpbUcm50rQ I3ILeq/VkH; Authentication-Results: sj-dkim-2; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [lisp] [idsubmission@ietf.org: New Version Notification for draft-ietf-lisp-ms-02] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 05 Sep 2009 00:09:22 -0000 There was one comment on this draft today: "SHA-128" apparently does not exist so specifying it was a mistake; references have been changed to "SHA-256". This is HMAC used for IPSEC-authenticated Map-Register messages sent from an ETR to a Map-Server. No other comments were received prior to Dino's announced deadline of 17:00-PDT on 4 September 2009. Vince & Dino ----- Forwarded message from IETF I-D Submission Tool ----- Date: Fri, 4 Sep 2009 17:04:12 -0700 (PDT) From: IETF I-D Submission Tool To: vaf@cisco.com Cc: dino@cisco.com Subject: New Version Notification for draft-ietf-lisp-ms-02 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkBAFdHoUpAqmIgiWdsb2JhbACQMgGLCAEBAQoLCAkSBqUJmQKEFgU A new version of I-D, draft-ietf-lisp-ms-02.txt has been successfuly submitted by Vince Fuller and posted to the IETF repository. Filename: draft-ietf-lisp-ms Revision: 02 Title: LISP Map Server Creation_date: 2009-09-04 WG ID: lisp Number_of_pages: 14 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. The IETF Secretariat. ----- End forwarded message ----- From root@core3.amsl.com Fri Sep 4 17:15:02 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 10C003A6A07; Fri, 4 Sep 2009 17:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090905001502.10C003A6A07@core3.amsl.com> Date: Fri, 4 Sep 2009 17:15:02 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action: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: Sat, 05 Sep 2009 00:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Map Server Author(s) : V. Fuller, D. Farinacci Filename : draft-ietf-lisp-ms-02.txt Pages : 14 Date : 2009-09-04 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-ms-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-04170412.I-D@ietf.org> --NextPart-- From dino@cisco.com Fri Sep 4 21:03: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 9E8453A67D9 for ; Fri, 4 Sep 2009 21:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 jszX2ThuLVSk for ; Fri, 4 Sep 2009 21:03:08 -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 D67733A6768 for ; Fri, 4 Sep 2009 21:03:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJZ/oUqrR7PE/2dsb2JhbADAaYhAAZAvBYQWimg X-IronPort-AV: E=Sophos;i="4.44,336,1249257600"; d="scan'208";a="382503083" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 05 Sep 2009 04:03:31 +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 n8543UJ0001158; Fri, 4 Sep 2009 21:03:30 -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 n8543UKj006777; Sat, 5 Sep 2009 04:03:30 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); Fri, 4 Sep 2009 21:03:30 -0700 Received: from [192.168.1.4] ([10.21.115.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 21:03:30 -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: Fri, 4 Sep 2009 21:03:30 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 05 Sep 2009 04:03:30.0253 (UTC) FILETIME=[D4132FD0:01CA2DDD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=232; t=1252123410; x=1252987410; 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=3A=20changes=20to=20sha-1=2 0and=20RFC=204302 |Sender:=20; bh=aMSRx4KV49B5byb3DbXtr3HnG4klV52ZsLOEPuMjCUs=; b=eLxoWxX7nvsCsfFLMgbnZlr6ZXyleH4i9v1X26fMXcfkfINzzxQ8E8p+jD Emn/pE+ZPVcDA8oc1THe0H2ZfOn0aEMTsDODyDywvDDksBE4zOsU7slsesTv ndGLe00eV7; 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: changes to sha-1 and RFC 4302 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 05 Sep 2009 04:03:09 -0000 > The areas that I feel most strongly about are the areas that I believe > Dino objects most to changing. I understand I still owe the WG more > justification. How do you know what I object to? I never told you. ;-) Dino From jnc@mercury.lcs.mit.edu Sat Sep 5 07:36: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 EBFBA3A67F4 for ; Sat, 5 Sep 2009 07:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 DZOHVf+exoRF for ; Sat, 5 Sep 2009 07:36:06 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id D94E53A67C1 for ; Sat, 5 Sep 2009 07:36:05 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 344166BE5DE; Sat, 5 Sep 2009 10:34:53 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090905143453.344166BE5DE@mercury.lcs.mit.edu> Date: Sat, 5 Sep 2009 10:34:53 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Confirming consensus behind echo noncing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 05 Sep 2009 14:36:07 -0000 > From: Sam Hartman [A few points in addition to Dino's..] > echo nonces. ... they are not useful in any of the following situations > > * square routing > * triangle routing (a sends to b, c sends to a) Note that nonces are xTR to xTR, not EID to EID. So even if a particular TCP connection is square/triangle routed (e.g. your example above), there may still be packets flowing back from B to A; perhaps for some other connection, and/or pair of EIDs. E.g. perhaps there are two EID-ranges using B and C as their xTRs, with different mappings, so there may be traffic going from A to C for a different destination EID, and packets from the combination of the two carry the nonces. We can also write a configuration/usage document which points out to people points such as that if they have a configuration which is 'strictly' triangular (i.e. only one announced ETR, b, and only one ITR, c) they lose the 'free' piggybacked reachability testing of nonces, and recommend against such configurations. > cannot detect a full path failure: in order to conclude you cannot > reach someone you need to get packets from them True, but if there is a full path-failure, the fact that the xTRs aren't hearing nonces will cause them to do a probe (which is the robust last line of defence), and that will fail, signalling the full failure. (And if there are no packet flowing, there is _no_ mechanism other than a timeout which can detect that anyway.) Also, with appropriate (more complex, albeit) logic in the sender, nonces can also be used to produce a 'down' signal in the forward-only direction (which is the only direction nonces tell you about, actually), not just an 'up' signal (and produce the 'down' signal more quickly than the simple 'we haven't heard a nonce echoed in the N second timeout, time to do an explicit probe' above). If an xTR has sent a nonce multiple times and not heard it echoed, even though it has heard lots of packets from the other end since it first sent the nonce, that is an indication that the forward direction is down. > It seems likely that in any situation where you have multiple rlocs of > the same priority you'll likely run into that case if you have a small > number of flows. > Long term .. I think we'll end up with required control plane probing > of locators with possible optimizations through the data plane. Nonces are an optimization, one intended to produce 'pretty good' reachability and liveness detection most of the time, at little cost. Yes, there will be corner cases where it doesn't work - which is why it's not the _only_ reachability and liveness detection mechanism. The concept is to have a collection of mechanisms which _together_ produce the desired characteristics of high robustness, low overhead, and fast response; there doesn't seem to be a single mechanism that touches all of these bases. > In that environment, I think echo nonces will serve no purpose. Nonces are one leg of the {robustness, overhead, response} stool; take them away, and you'll lose something on meeting these goals. It's actually a four-way tradeoff, with the last axis being complexity - having multiple mechanisms is more complex, but it does allow us to make _each_ mechanism relatively simple, since none bear the full load of meeting the 3-way goal. > the performance concerns that matter for probing on CPEs seem very > different than say XTRs at an Amazon data center. But it takes two to tango. A customer CPE is probably talking to Amazon, so we can't have a mechanism that makes sense _only_ at customer CPE's. Noel From jari.arkko@piuha.net Mon Sep 7 11:40: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 909A13A6831 for ; Mon, 7 Sep 2009 11:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 YJ-F1KtSulcA for ; Mon, 7 Sep 2009 11:40:36 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 1D9753A68E3 for ; Mon, 7 Sep 2009 11:40:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B7E1DD62A3; Mon, 7 Sep 2009 21:41:03 +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 t4xE2XQDwmbu; Mon, 7 Sep 2009 21:41:03 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 115FDD620E; Mon, 7 Sep 2009 21:41:03 +0300 (EEST) Message-ID: <4AA553BE.4020509@piuha.net> Date: Mon, 07 Sep 2009 21:41:02 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Noel Chiappa References: <20090808031330.BB9726BE5CA@mercury.lcs.mit.edu> In-Reply-To: <20090808031330.BB9726BE5CA@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: [lisp] xTR to xTR via nat64 (Was: 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: Mon, 07 Sep 2009 18:40:37 -0000 Noel, (I know my reply is late) > 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? > My preference is to not design the protocol to handle this case. There's probably other similar corner cases that we should explicitly rule out of scope in the name of keeping our solution simple and being able to get it out there. It possible that even regular IPv4 NATs are something that could be ignored... though for them I understand that there are situations where being able to cross an IPv4 NAT would be useful. The problem is that supporting more of these situations leads to complexity. And sometimes it may seem easy to support something, until you try to design a failure detection and keepalive mechanism that allows the NAT bindings to stay up in a multihoming situation :-) In any case, even if we don't support NAT64 or other corner cases, I would like to see that the LISP design is failsafe. That is, an unexpected condition should not result in a serious problem beyond loss of connectivity to the destination in question. It may be a good idea to check if a NAT did appear in the path. Jari From jari.arkko@piuha.net Mon Sep 7 13:18: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 B49953A69BB for ; Mon, 7 Sep 2009 13:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 J29DkWlWQAY7 for ; Mon, 7 Sep 2009 13:18:37 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7AAFF3A659A for ; Mon, 7 Sep 2009 13:18:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EA634D62A3; Mon, 7 Sep 2009 23:19:04 +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 n-5qH8wtyfxo; Mon, 7 Sep 2009 23:19:04 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 3EC96D620E; Mon, 7 Sep 2009 23:19:04 +0300 (EEST) Message-ID: <4AA56AB7.9020909@piuha.net> Date: Mon, 07 Sep 2009 23:19:03 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Noel Chiappa References: <20090811205547.C318B6BE59B@mercury.lcs.mit.edu> In-Reply-To: <20090811205547.C318B6BE59B@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 07 Sep 2009 20:18:39 -0000 Sam, I'm reading the mails about security issues, and wanted to reply. I hope I have not missed some later mails or a re-opening an already closed issue. In any case, you wrote: > * 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. I agree, and see further below about my response to Noel. > 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. Not sure about this though. I think the debate about using nothing-vs-nonce-vs-ipsec-vs-tls is too early. First we have to figure out what the security model is. And frankly I'm not sure we have a good idea about that yet, but maybe I'm missing something. If -- as Noel suggests below -- the mapping data itself is protected, then the map request/reply protection has far less to do, and a nonce is likely sufficient to handle DoS attacks. Also, Noel wrote: > 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. This is my preference as well. I'd like to see a security model that is based on protecting the data rather than the communications. This will also make it easier to distribute, cache, and re-distribute mapping information. And Olivier wrote: > 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. > I agree, but I would add that mere on/off path designation is probably too simple basis for the analysis. For instance, a control protocol between an ITR and ETR to set up packet forwarding between the two is probably OK even if it is vulnerable to on-path attacks. Once the data packets are flowing you'll be vulnerable to on-path attacks anyway. But I tend to think of the mapping system as a more valuable, centralized resource that needs to be guarded more carefully. And the mapping system is a new component, so if we introduce a vulnerability there then you have an issue with either the source to destination e2e path OR the source ITR to mapping system path. These reasons lead me to believe that on-path attacks may not be OK for the mapping system. Jari From mrw@sandstorm.net Mon Sep 7 13:39: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 08DDC28C175 for ; Mon, 7 Sep 2009 13:39:54 -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 QLhvmGZ2JbDj for ; Mon, 7 Sep 2009 13:39:53 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id F278628C130 for ; Mon, 7 Sep 2009 13:39:52 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n87Ke998085908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Sep 2009 16:40:10 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <2F2FD8E3-9D14-41A6-BAC9-0BD883C96F50@sandstorm.net> From: Margaret Wasserman To: Jari Arkko In-Reply-To: <4AA56AB7.9020909@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: Mon, 7 Sep 2009 16:40:08 -0400 References: <20090811205547.C318B6BE59B@mercury.lcs.mit.edu> <4AA56AB7.9020909@piuha.net> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , 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: Mon, 07 Sep 2009 20:39:54 -0000 On Sep 7, 2009, at 4:19 PM, Jari Arkko wrote: > > Not sure about this though. I think the debate about using nothing- > vs-nonce-vs-ipsec-vs-tls is too early. First we have to figure out > what the security model is. And frankly I'm not sure we have a good > idea about that yet, but maybe I'm missing something. If -- as Noel > suggests below -- the mapping data itself is protected, then the map > request/reply protection has far less to do, and a nonce is likely > sufficient to handle DoS attacks. When you say "the data itself is protected", I _think_ you mean something different than Noel does. Noel is saying that the mechanism for adding mapping entries to the mapping system is protected. This is currently true by virtue of the fact that mapping registrations use IPsec AH, and nothing will be added to the mapping system that isn't properly authorized. However, the data that is passed in a mapping reply is not "protected". An ITR sends a mapping request to its mapping server. The response will come back from another node (an ETR), and will contain data that is not encrypted and cannot be authenticated. The only "protection" on the response is that it contains a 32-bit nonce that matches the request. So, anyone who can see the request (or guess its contents) can send a spoofed response that will be accepted by the requesting ITR. Even if two replies are received (one valid and one spoofed), the ITR will have no means to tell the difference between them. > Also, Noel wrote: >> 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. > > This is my preference as well. I'd like to see a security model that > is based on protecting the data rather than the communications. This > will also make it easier to distribute, cache, and re-distribute > mapping information. I think this is a good general approach, but there is nothing in the current protocol that does this. > I agree, but I would add that mere on/off path designation is > probably too simple basis for the analysis. For instance, a control > protocol between an ITR and ETR to set up packet forwarding between > the two is probably OK even if it is vulnerable to on-path attacks. > Once the data packets are flowing you'll be vulnerable to on-path > attacks anyway. But I tend to think of the mapping system as a more > valuable, centralized resource that needs to be guarded more > carefully. And the mapping system is a new component, so if we > introduce a vulnerability there then you have an issue with either > the source to destination e2e path OR the source ITR to mapping > system path. These reasons lead me to believe that on-path attacks > may not be OK for the mapping system. I agree. I think that it should be possible for an ITR to somehow authenticate the mapping data it receives in a mapping request. Something similar to the level of security provided by DNSSEC would be appropriate, in my opinion. Margaret From hartmans@mit.edu Mon Sep 7 15:46: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 09E9528C125 for ; Mon, 7 Sep 2009 15:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_33=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 cwf+tHG3c3K7 for ; Mon, 7 Sep 2009 15:46:55 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 2E7803A68A4 for ; Mon, 7 Sep 2009 15:46:55 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 284D151C9; Mon, 7 Sep 2009 18:47:11 -0400 (EDT) To: Jari Arkko References: <20090811205547.C318B6BE59B@mercury.lcs.mit.edu> <4AA56AB7.9020909@piuha.net> From: Sam Hartman Date: Mon, 07 Sep 2009 18:47:11 -0400 In-Reply-To: <4AA56AB7.9020909@piuha.net> (Jari Arkko's message of "Mon\, 07 Sep 2009 23\:19\:03 +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: Noel Chiappa , 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: Mon, 07 Sep 2009 22:46:56 -0000 >>>>> "Jari" == Jari Arkko writes: Jari> Not sure about this though. I think the debate about using Jari> nothing-vs-nonce-vs-ipsec-vs-tls is too early. First we have Jari> to figure out what the security model is. And frankly I'm Jari> not sure we have a good idea about that yet, but maybe I'm Jari> missing something. If -- as Noel suggests below -- the Jari> mapping data itself is protected, then the map request/reply Jari> protection has far less to do, and a nonce is likely Jari> sufficient to handle DoS attacks. I agree it's really too early to be having this discussion. I brought it up because it was on my mind if it didn't get written down I'd forget it. My suspicion is that we'll end up divinding the security into three legs: * ITR to map resolver * inside the mapping system * map server to ETR. My suspicion is that each mapping system will have its own internal security model. For example, ALT probably ends up using something similar to SIDR internally. Some mapping system based on DHTs and cryptographically generated prefixes would not benefit from something like SIDR at all. In addition, I'm not sure that all ITRs will be in the position to have the CRLs, trust anchors, trust anchor updates and intermediate certificates necessary to verify mappings. So, it might be better to have a simpler trust relationship between an ITR and its map resolver and to have the map resolver do the heavy lifting for security. Also, before we have real security in the map system--while the map system security looks a lot like current core BGP security--then the link between the ITR and map resolver looks a lot more attractive as a target. It may well run over access networks or other relatively low security links. We may be able to assure that the alt runs mostly or completely in the core.q So, before there is real mapping security within the alt, we may get significant benefit from security the ITR->map resolver link. However, as you point out, it's too early for this discussion. Also, the above assumes some significant changes to the ITR<->map resolver protocol. I believe those changes are needed for other reasons. From trac@tools.ietf.org Mon Sep 7 15:57: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 637D628C1D1 for ; Mon, 7 Sep 2009 15:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, 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 oct4XRfmq6HI for ; Mon, 7 Sep 2009 15:57:14 -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 A479528C125 for ; Mon, 7 Sep 2009 15:57:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Mkn9a-0002hT-4y; Mon, 07 Sep 2009 15:57:42 -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: dino@cisco.com, hartmans-ietf@mit.edu X-Trac-Project: lisp Date: Mon, 07 Sep 2009 22:57:42 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/lisp/trac/ticket/18 Message-ID: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dino@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 Cc: lisp@ietf.org Subject: [lisp] #18: record count >1 for map request 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: Mon, 07 Sep 2009 22:57:15 -0000 #18: record count >1 for map request ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@mit.edu | Owner: dino@cisco.com Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Dino> * How do deal with record count greater than 1 for a Dino> Map-Request. Damien and Joel comment. Joel suggests: Dino> 1) Specify that senders compliant with the current Dino> document will always set the count to 1, and note that the Dino> count is included for future extensibility. Dino> 2) Specify what a receiver compliant with the draft Dino> should do if it receives a request with a count greater than Dino> 1. Presumably, it should send some error back? From the proposed lisp 04 text Record Count: The number of records in this request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record count. For this version of the protocol specification, a receiver MUST accept and process a record count of one or greater but a sender MUST always set the record count to one. As I understand it, this issue was opened exactly because we didn't know what a receiver should do with a record count is greater than 1. In any case, Dino's proposed text is inconistent with Joel's proposal so Dino and Joel need to touch base and come back to the WG with an explanation. -- Ticket URL: lisp LISP WG document issues From hartmans@mit.edu Mon Sep 7 16:07: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 07B3228C1AE for ; Mon, 7 Sep 2009 16:07:53 -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 wa3Ukyo3wcLs for ; Mon, 7 Sep 2009 16:07:52 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 54BA13A6AE3 for ; Mon, 7 Sep 2009 16:07:52 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3253A51C9; Mon, 7 Sep 2009 19:08:09 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Message-Id: <20090907230809.3253A51C9@carter-zimmerman.suchdamage.org> Date: Mon, 7 Sep 2009 19:08:09 -0400 (EDT) Subject: [lisp] Apologies in advance for the form of some issues I'm opening X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 07 Sep 2009 23:07:53 -0000 Folks, I want to apologize in advance for opening exactly the sort of issue that I said editors shouldn't open. Dino's proposed changes to 04 include some changes that have not been discussed on the WG list, some of which have process or other problems. In an ideal world, I'd have some textual proposal explaining what the issue is and why it's a good idea to enter into the tracker and then I'd follow up with a comment discussing my concerns as chair. However, I don't actually have that text and suspect for some of these issues the text doesn't exist. So, I'm combining both my iferred description of the issue along with my concerns as chair into a single message. I'd appreciate comments on how I could have handled this better, although it's probably best to send those comments privatly so as not to clutter up the list. Sorry for breaking my own advice here. --Sam From trac@tools.ietf.org Mon Sep 7 16:13: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 7CB8728C17F for ; Mon, 7 Sep 2009 16:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, 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 ooZ5tnMF2GCe for ; Mon, 7 Sep 2009 16:13:34 -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 C946E3A6ACE for ; Mon, 7 Sep 2009 16:13:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MknPL-0001tM-EV; Mon, 07 Sep 2009 16:14:00 -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: Mon, 07 Sep 2009 23:13:59 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/19 Message-ID: <060.a6bdaf04b35955374257c35fafb40c20@tools.ietf.org> X-Trac-Ticket-ID: 19 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] #19: mobility bit in map reply 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: Mon, 07 Sep 2009 23:13:35 -0000 #19: mobility bit in map reply ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@mit.edu | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Dino's proposed changes to 04 include a mobility bit in the map reply. Several problems exist: * The behavior for this bit is not specified clearly enough to implement; it would need a normative reference to the mobility arch draft * Some, including Joel have argued that the bit is not needed * most issues related to this are out of scope for the WG. I think that the best way forward is for us to decide on an IANA assignment policy for the flags in the map reply. If that policy permits the authors of the mobility arch draft to request a flag then they can do so; if after whatever review we decide is necessary we approve assigning a flag, then do so. Alternatively, put this on hold until mobility is in scope for our chater. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Mon Sep 7 16:18: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 68FD528C201 for ; Mon, 7 Sep 2009 16:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, 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 beDanOH3wwqs for ; Mon, 7 Sep 2009 16:18:24 -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 BB2A93A69B5 for ; Mon, 7 Sep 2009 16:18:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MknU2-0007xD-R9; Mon, 07 Sep 2009 16:18: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: hartmans-ietf@mit.edu X-Trac-Project: lisp Date: Mon, 07 Sep 2009 23:18:50 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/lisp/trac/ticket/8#comment:1 Message-ID: <066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org> References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, 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: Re: [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: Mon, 07 Sep 2009 23:18:25 -0000 #8: Limits on "Gleaned" Map Entries Not Clear -------------------------------+-------------------------------------------- Reporter: mrw@lilacglade.org | Owner: hartmans-ietf@mit.edu Type: technical | Status: assigned Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Changes (by hartmans-ietf@mit.edu): * owner: => hartmans-ietf@mit.edu * status: new => assigned Comment: In Dino's proposed 04 text the following is added: o A "gleaned" map-cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. We're still waiting to hear back from the WG and Margaret on this text. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Mon Sep 7 16:22: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 501EF28C116 for ; Mon, 7 Sep 2009 16:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, 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 vZekLgdytM0W for ; Mon, 7 Sep 2009 16:22:01 -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 B7FCB3A6859 for ; Mon, 7 Sep 2009 16:22:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MknXZ-0005Kh-S7; Mon, 07 Sep 2009 16:22:29 -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: Mon, 07 Sep 2009 23:22:29 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/8#comment:2 Message-ID: <066.e8731a9e76fe2c1de7b574201da3c2d4@tools.ietf.org> References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, 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: Re: [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: Mon, 07 Sep 2009 23:22:02 -0000 #8: Limits on "Gleaned" Map Entries Not Clear -------------------------------+-------------------------------------------- Reporter: mrw@lilacglade.org | Owner: hartmans-ietf@mit.edu Type: technical | Status: assigned Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Comment(by hartmans-ietf@mit.edu): Actually Dino had an additional fix to his proposed text in the second round of 04 changes: themap request needs to be sent to the eid not the rloc. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Mon Sep 7 16:26: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 09D3B3A6859 for ; Mon, 7 Sep 2009 16:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 aJrWGIOwMCzH for ; Mon, 7 Sep 2009 16:26:34 -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 56C163A6835 for ; Mon, 7 Sep 2009 16:26:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Mknby-0000Ns-Vf; Mon, 07 Sep 2009 16:27:03 -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: Mon, 07 Sep 2009 23:27:02 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/lisp/trac/ticket/20 Message-ID: <060.313584aef3158f06c1f1bd0419f8f57e@tools.ietf.org> X-Trac-Ticket-ID: 20 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] #20: SMR bit only in control plane 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: Mon, 07 Sep 2009 23:26:35 -0000 #20: SMR bit only in control plane ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@mit.edu | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Dino proposes to remove the SMR bit from the data plane and only include it in the control plane -- Ticket URL: lisp LISP WG document issues From hartmans@mit.edu Mon Sep 7 16:41: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 27C8F3A69CB for ; Mon, 7 Sep 2009 16:41:18 -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 SxRyXRV33Zj5 for ; Mon, 7 Sep 2009 16:41: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 B9C773A67B5 for ; Mon, 7 Sep 2009 16:41:14 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BB52151C9; Mon, 7 Sep 2009 19:41:29 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Message-Id: <20090907234129.BB52151C9@carter-zimmerman.suchdamage.org> Date: Mon, 7 Sep 2009 19:41:29 -0400 (EDT) Subject: [lisp] Confirming Consensus on RLOC probing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 07 Sep 2009 23:41:20 -0000 Folks, there was a presentation on RLOC reachability at the IETF 75 meeting in Stockholm. It's my perception from the audio that the sense of the room was that RLOC probing was something that we want to specify so we can experiment with it. I'd like to confirm that consensus on the list. Because I've seen a fair bit of discussion of this issue, I'm going to assume that we have consensus unless I hear major objections by Friday, September 11. If you need more time to review this issue, please let me know; if you ask for more time, I definitely expect a review of the issue and the specific text from you. If you've read the specific text in Dino's 04 proposal on this issue, please let the list know. Comments are of course welcome. From hartmans@mit.edu Mon Sep 7 16:45: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 615A73A679F for ; Mon, 7 Sep 2009 16:45:34 -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 MfQH2DzlzN9t for ; Mon, 7 Sep 2009 16:45: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 632963A6784 for ; Mon, 7 Sep 2009 16:45:33 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E760951C9; Mon, 7 Sep 2009 19:45:49 -0400 (EDT) To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> From: Sam Hartman Date: Mon, 07 Sep 2009 19:45:49 -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: [lisp] Changes proposed in 04 that have not yet demonstrated WG consensus X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 07 Sep 2009 23:45:34 -0000 Dino, the following issues require positive WG consensus to make changes. That is, we need to see on the WG LISP that people have reviewed, understood and agreed with the change. (We also need to deal with any objections). In general, each of these issues or each group of issue should have been addressed in a separate message to the WG describing the issue, the specific text change and most importantly the reasoning for the change. Including issues this large batched together with other changes ultimately reduces the review that changes get, and by the time where all going to be done, will end up creating more work for the editors and chairs than if they had been called out separately. I want to stress that I'm not complaining about your actions or those of any of the other editors; we're all still learning to work together. The fact that we don't have the process entirely ironed out for major changes should not be considered a mark against anyone: it really does take some time to get going. In general it would be best to use the issue tracker, and using the issue tracker is required when proposing text to address an issue that is already open there. >>>>> "Dino" == Dino Farinacci writes: * How do deal with record count greater than 1 for a Map-Request. This was discussed on the list. You proposed a solution different than the one that Joel agreed to in your revised text. However, as far as I can see, you did not follow up with Joel as required by our issue policy. I've opened an issue for this in the tracker. (As an additional note, I don't think your proposal actually works.) Dino> * Add the mobility bit to Map-Replies. So PTRs don't probe Dino> so often for MNs but often enough to get mapping updates. There are process and consensus problems with this. Opened in the issue tracker. Dino> * Margaret's comment on gleaning: I didn't see discussion of the text on the list; follow up required for issue #8. Dino> * Add section on RLOC-probing per working group feedback. This should have been called out to the list, and the chairs should have issued a consensus call. I'm issuing the consensus call now. Based on discussion in Stockholm I think we'll end up being fine here. Dino> * Remove SMR-bit from data-plane. Dino prefers to have it in Dino> the control plane only. This definitely needs to be discussed on the list. While I believe this was mentioned in passing in the Stockholm meeting and may have even come out of that meeting, there was no sense of the room. So, we cannot make this change until we actually get people to review and evaluate the proposal. Dino> * Change LISP header to allow a "Research Bit" so the Nonce Dino> and LSB fields can be turned off and used for another future Dino> purpose. For Luigi et al versioning convergence. Dino> * Add a N-bit to the data header suggested by Noel. Then the Dino> nonce field could be used when N is not 1. This definitely should have been proposed on the list, not just put forward in the proposed text. We seem to be moving forward on this, and may converge in a few days. I'll try to make an explicit consensus call shortly. From dino@cisco.com Mon Sep 7 16:51: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 186633A689A for ; Mon, 7 Sep 2009 16:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 TlgsMnCeTQFc for ; Mon, 7 Sep 2009 16:51:58 -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 26EC53A67B5 for ; Mon, 7 Sep 2009 16:51:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIE5pUqrR7PD/2dsb2JhbADCCYhDAY5nBYQYil0 X-IronPort-AV: E=Sophos;i="4.44,349,1249257600"; d="scan'208";a="383869981" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Sep 2009 23:52:27 +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 n87NqQJ0018235; Mon, 7 Sep 2009 16:52:26 -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 n87NqRCx009352; Mon, 7 Sep 2009 23:52:27 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, 7 Sep 2009 16:52:26 -0700 Received: from [192.168.1.2] ([10.21.147.124]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 16:52:26 -0700 Message-Id: <17E37F3E-9814-4697-8CCA-EF87015B9F1F@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: <20090907234129.BB52151C9@carter-zimmerman.suchdamage.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: Mon, 7 Sep 2009 16:52:25 -0700 References: <20090907234129.BB52151C9@carter-zimmerman.suchdamage.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 07 Sep 2009 23:52:26.0481 (UTC) FILETIME=[409B3E10:01CA3016] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=267; t=1252367547; x=1253231547; 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]=20Confirming=20Consensus=20on=20 RLOC=20probing |Sender:=20; bh=Pi7szM/i+ydQBEhgXrydekHrMsGLEsQszXxvgYIcPr0=; b=l+N69NyT0WY2JlNdq/PYG55Em3DbfuM7KP1GS58m4QGJ4d7YZmRFmKDd4X UECDE4NtTYk3mjSXQQyvu7ELqyyLh3jc05jpEOpCIES0OgMgpjnzu0dRwlmL j3gNMXwXQh; 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] Confirming Consensus on RLOC probing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 07 Sep 2009 23:51:59 -0000 > If you've read the specific text in Dino's 04 proposal on this issue, > please let the list know. Comments are of course welcome. Please note we indicate that this is an optional feature. And we are testing it on the LISP test network as we speak. Dino From hartmans@mit.edu Mon Sep 7 16:55: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 3BAA73A688A for ; Mon, 7 Sep 2009 16:55:10 -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 k407EDlSr2SS for ; Mon, 7 Sep 2009 16:55:09 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 29EEA3A689A for ; Mon, 7 Sep 2009 16:54:51 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 87D1451C9; Mon, 7 Sep 2009 19:55:07 -0400 (EDT) To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> From: Sam Hartman Date: Mon, 07 Sep 2009 19:55:07 -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: [lisp] Changes that have demonstrated sufficient consensus X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 07 Sep 2009 23:55:10 -0000 >>>>> "Dino" == Dino Farinacci writes: For the changes listed below, it's fine to submit, or to wait until we get closer on some of the open issues. Note that the issue tracking policy we agreed to requires there to be a change log section in the draft, not just in mail to the list. I don't see that in 04; that will need to be added before it is submitted. The level of detail for the changes below is fine. Dino> * Add Fred Templin in ack section. I certainly don't object to you calling this out in the changelog, but you need not do so. Dino> * Say more about LAGs in the UDP section per Sam Hartman's Dino> comment. According to the issue tracking policy, you should have followed up with me. However I've reviewed the text and it is fine; thanks. Dino> * Sam wants to use MAY instead of SHOULD for ignoring Dino> checkums on ETR. From the mailing list: Dino> You'd need to word it as an ITR MAY send a zero checksum, Dino> an ETR MUST accept a 0 checksum and MAY ignore the checksum Dino> completely. And of course we'd need to confirm that can Dino> actually be implemented. In particular, hardware that Dino> verifies UDP checksums on receive needs to be checked to Dino> make sure it permits 0 checksums. Dino> * Margaret wants a reference to Dino> http://www.ietf.org/id/draft-eubanks- chimento-6man-00.txt. I think we're still waiting for Joel and Margaret to give us final wording on the UDP checksum text. Feel free to include what is in 04: it is clearly closer to WG consensus than 03. Dino> * Fix description in Map-Request section. Where we describe Dino> Map-Reply Record, change "R-bit" to "M-bit". This may be small enough that it doesn't need to be called out. Dino> * Indicate SHA1 can be used as well for Map-Registers. Note that the text is still broken. The IPsec sha-1 is 96-bits long not 128-bits long. Also, according to some software I'm using but not verified with the spec, 0 is an illegal SPI. However this change is small and is supported by WG discussion. Dino> * More Fred comments on MTU handling. Dino> * Isidor comment about specing better periodic Dino> Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. Dino> * Change "loc-reach-bits" to "loc-status-bits" per comment Dino> from Noel. Dino> * Clarify that when E-bit is 0, the nonce field can be an Dino> echoed nonce or a random nonce. Comment from Jesper. Dino> * Indicate when doing data-gleaning that a verifying Dino> Map-Request is sent to the source-EID of the gleaned data Dino> packet so we can avoid map- cache corruption by a 3rd Dino> party. Comment from Pedro. Fine if the gleaning text in general is OK. Dino> * Indicate that a verifying Map-Request, for accepting Dino> mapping data, should be sent over the the ALT (or to the Dino> EID). Dino> * Reference IPsec RFC 4302. Comment from Sam and Brian Weis. Note this probably has bigger implications than you expect; it moves you from 2401 to 4301 for the base architecture and that has huge implications. Dino> * Put E-bit in Map-Reply to tell ITRs that the ETR supports Dino> echo- noncing. Comment by Pedro and Dino. This might have needed an explicit wg list message, but I'm going to let it slide: it's a really obviously useful idea. Dino> * Jesper made a comment to loosen the language about Dino> requiring the copy of inner TTL to outer TTL since the text Dino> to get mixed-AF traceroute to work would violate the "MUST" Dino> clause. Changed from MUST to SHOULD in section 5.3. From jmh@joelhalpern.com Mon Sep 7 16:59: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 B64D23A6A27 for ; Mon, 7 Sep 2009 16:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.892 X-Spam-Level: X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5 tests=[AWL=-0.293, 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 50Ov2QTEQ-iM for ; Mon, 7 Sep 2009 16:59:26 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 046FD3A682C for ; Mon, 7 Sep 2009 16:59:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 13C3E3230F80; Mon, 7 Sep 2009 16:59:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.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 hgblob.tigertech.net (Postfix) with ESMTP id 41FE83230F7A; Mon, 7 Sep 2009 16:59:54 -0700 (PDT) Message-ID: <4AA59E78.8020607@joelhalpern.com> Date: Mon, 07 Sep 2009 19:59:52 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: trac@localhost.amsl.com References: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> In-Reply-To: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] #18: record count >1 for map request X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 07 Sep 2009 23:59:26 -0000 After exchanging a few emails with Dino, I can think what is in the draft is sufficient to address the issue. Yours, Joel lisp issue tracker wrote: > #18: record count >1 for map request > ----------------------------------+----------------------------------------- > Reporter: hartmans-ietf@mit.edu | Owner: dino@cisco.com > Type: technical | Status: new > Priority: major | Component: draft-ietf-lisp > Severity: - | Keywords: > ----------------------------------+----------------------------------------- > Dino> * How do deal with record count greater than 1 for a > Dino> Map-Request. Damien and Joel comment. Joel suggests: > > Dino> 1) Specify that senders compliant with the current > Dino> document will always set the count to 1, and note that the > Dino> count is included for future extensibility. > > Dino> 2) Specify what a receiver compliant with the draft > Dino> should do if it receives a request with a count greater than > Dino> 1. Presumably, it should send some error back? > > From the proposed lisp 04 text > Record Count: The number of records in this request message. A > record is comprised of the portion of the packet that is labeled > 'Rec' above and occurs the number of times equal to Record count. > For this version of the protocol specification, a receiver MUST > accept and process a record count of one or greater but a sender > MUST always set the record count to one. > > As I understand it, this issue was opened exactly because we didn't > know what a receiver should do with a record count is greater than 1. > In any case, Dino's proposed text is inconistent with Joel's proposal > so Dino and Joel need to touch base and come back to the WG with an > explanation. > From dino@cisco.com Mon Sep 7 17:02: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 7C6B13A68FF for ; Mon, 7 Sep 2009 17:02:11 -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 EtswFKIsC2rl for ; Mon, 7 Sep 2009 17:02: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 6207F3A682C for ; Mon, 7 Sep 2009 17:02:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANc7pUqrR7MV/2dsb2JhbADCEIhDAY5oBYQYil0 X-IronPort-AV: E=Sophos;i="4.44,349,1249257600"; d="scan'208";a="383874176" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 08 Sep 2009 00:02:39 +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 n8802d0x013955; Mon, 7 Sep 2009 17:02:39 -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 n8802dKw010104; Tue, 8 Sep 2009 00:02:39 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, 7 Sep 2009 17:02:39 -0700 Received: from [192.168.1.2] ([10.21.147.124]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 17:02: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 v936) Date: Mon, 7 Sep 2009 17:02:38 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 00:02:38.0997 (UTC) FILETIME=[ADB1C450:01CA3017] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4457; t=1252368159; x=1253232159; 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=20Changes=20proposed=20in=2004=20that=20h ave=20not=20yet=20demonstrated=20WG=20consensus |Sender:=20; bh=CQ7z1GNeRr0C0DCpPtE5kIuKQMqPt8Q+0gN2cxzdAUo=; b=gGLUpssQM/ahEn+BJ3E9Cm1P8KQ6cZNMO9WC7RmUJRT5FL3ImFsu2Z4+M8 nob6iYJjdPrdYAT9Uqn7dDUaZHQZRSxFMYAiIHwcXUojMwZg5hmyNsZszXaP UwVb4D8+2BrA/G2PjYOFVL4FBwZTUpdcAYpHflKGqkpaA59GtUWaQ=; 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] Changes proposed in 04 that have not yet demonstrated WG consensus X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 00:02:11 -0000 > Dino, the following issues require positive WG consensus to make > changes. > That is, we need to see on the WG LISP that people have reviewed, > understood and agreed with the change. > (We also need to deal with any objections). That is what the review period is for, no? > In general, each of these issues or each group of issue should have > been addressed in a separate message to the WG describing the issue, > the specific text change and most importantly the reasoning for the > change. Including issues this large batched together with other > changes ultimately reduces the review that changes get, and by the > time where all going to be done, will end up creating more work for > the editors and chairs than if they had been called out separately. We tried to aggregate to be a bit more efficient. > I want to stress that I'm not complaining about your actions or those > of any of the other editors; we're all still learning to work > together. The fact that we don't have the process entirely ironed out > for major changes should not be considered a mark against anyone: it > really does take some time to get going. No offense taken. > In general it would be best to use the issue tracker, and using the > issue tracker is required when proposing text to address an issue that > is already open there. That creates more work for us and more overhead. We want to concentrate on the technology and experiments and not the process. >>>>>> "Dino" == Dino Farinacci writes: > * How do deal with record count greater than 1 for a Map-Request. > > This was discussed on the list. You proposed a solution different > than the one that Joel agreed to in your revised text. However, as > far as I can see, you did not follow up with Joel as required by our > issue policy. I've opened an issue for this in the tracker. (As an > additional note, I don't think your proposal actually works.) Revision 1 of this text was given to me by Joel. I inserted it. Then Vince word-smithed the text which I added in a revision 2. I have contacted Joel to see what he wants to do. I am neutral. > Dino> * Add the mobility bit to Map-Replies. So PTRs don't probe > Dino> so often for MNs but often enough to get mapping updates. > > There are process and consensus problems with this. Opened in the > issue tracker. I thought we resolved by not stating how to use the bit but keep its allocation in the spec. The current diff file reflects this. > Dino> * Margaret's comment on gleaning: > > I didn't see discussion of the text on the list; follow up required > for issue #8. > > Dino> * Add section on RLOC-probing per working group feedback. > > This should have been called out to the list, and the chairs should > have issued a consensus call. > I'm issuing the consensus call now. > Based on discussion in Stockholm I think we'll end up being fine here. Margaret said it needed to be more clear. So I added a paragraph to the diff file. I sent the diff file to the list so people can comment. What makes that different than "discussing it on the list"? > Dino> * Remove SMR-bit from data-plane. Dino prefers to have it in > Dino> the control plane only. > > This definitely needs to be discussed on the list. While I believe > this was mentioned in passing in the Stockholm meeting and may have > even come out of that meeting, there was no sense of the room. So, we > cannot make this change until we actually get people to review and > evaluate the proposal. We have discussed this to death on the list. What more do you expect to be discussed? > Dino> * Change LISP header to allow a "Research Bit" so the Nonce > Dino> and LSB fields can be turned off and used for another future > Dino> purpose. For Luigi et al versioning convergence. > Dino> * Add a N-bit to the data header suggested by Noel. Then the > Dino> nonce field could be used when N is not 1. > > This definitely should have been proposed on the list, not just put > forward in the proposed text. We seem to be moving forward on this, > and may converge in a few days. I'll try to make an explicit > consensus call shortly. Same comment. We got Luigi to agree to use the N and L bits set to 0. He even commented about this during vacation. What more do you want to discuss? Dino From dino@cisco.com Mon Sep 7 17:03: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 6CEE23A6A0F for ; Mon, 7 Sep 2009 17:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 iezAk1YZZBrN for ; Mon, 7 Sep 2009 17:02:59 -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 AAF5C3A67B5 for ; Mon, 7 Sep 2009 17:02:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIw8pUqrR7O6/2dsb2JhbADCE4hDAY5oBYQY X-IronPort-AV: E=Sophos;i="4.44,349,1249257600"; d="scan'208";a="238442196" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2009 00:03:25 +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 n8803PK6023625; Mon, 7 Sep 2009 17:03:25 -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 n8803PF0011117; Tue, 8 Sep 2009 00:03:25 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); Mon, 7 Sep 2009 17:03:25 -0700 Received: from [192.168.1.2] ([10.21.147.124]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 17:03:24 -0700 Message-Id: <3DA78CFC-7F5F-4535-A308-855B329ADA7D@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AA59E78.8020607@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: Mon, 7 Sep 2009 17:03:24 -0700 References: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> <4AA59E78.8020607@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 00:03:24.0778 (UTC) FILETIME=[C8FB64A0:01CA3017] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=165; t=1252368205; x=1253232205; 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]=20=20#18=3A=20record=20count=20> 1=20=20for=20map=20request |Sender:=20; bh=pL+QWdtcj7aisr30P0J2+u/PdDhbQg0KURSz9MdVw8Y=; b=ld5ycgOdpPVHmAW5GeGipLvh+on27ywDw148cfU/Ubus4gxZUVyo18zaqE v3tEzk+8vVZRVibWRPgHVo7rzHRehWfJwSD84luuN0WH0Sso86MXGDCSzr3q mznobRx/xA; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #18: record count >1 for map request X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 00:03:00 -0000 > After exchanging a few emails with Dino, I can think what is in the > draft is sufficient to address the issue. Thanks Joel for clearing things up. Dino From dino@cisco.com Mon Sep 7 17: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 E2AE03A6A46 for ; Mon, 7 Sep 2009 17:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 dDfELdBw2GH2 for ; Mon, 7 Sep 2009 17: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 D59813A6A27 for ; Mon, 7 Sep 2009 17:14:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOM+pUqrR7PD/2dsb2JhbADCHYhDAY5rBYQYgVmJBA X-IronPort-AV: E=Sophos;i="4.44,349,1249257600"; d="scan'208";a="238443959" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2009 00:15:26 +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 n880FQDN006341; Mon, 7 Sep 2009 17:15:26 -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 n880FQBt021385; Tue, 8 Sep 2009 00:15:26 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); Mon, 7 Sep 2009 17:15:26 -0700 Received: from [192.168.1.2] ([10.21.147.124]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 17:15:25 -0700 Message-Id: <14EB3D92-A53B-4EF2-AC25-4479C7D19B16@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 v936) Date: Mon, 7 Sep 2009 17:15:25 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 00:15:26.0253 (UTC) FILETIME=[7703BDD0:01CA3019] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1827; t=1252368926; x=1253232926; 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=20Changes=20that=20have=20demonstrated=20 sufficient=20consensus |Sender:=20; bh=Jj+E0POcWKYktM7Jt7/FVP20N5O+VJtJes40PF9Begs=; b=K19jodrEb/HRq6WzJH+1PVIFwY/W3UgYJooKfR2qQSo2AZJMNIZHrzcfw6 8XvVM+mPxFljkMbOxTfyB8a/6e2mAbW5jnngSpXpblsJdm9sgCg0fhWUY52H 1ZX1OiIoms; 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] Changes that have demonstrated sufficient consensus X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 00:14:59 -0000 I am responding to the technical issues of this email. > I think we're still waiting for Joel and Margaret to give us final > wording on the UDP checksum text. > Feel free to include what is in 04: it is clearly closer to WG > consensus than 03. We already got wording. I tried to capture everyone's comments while still making the text clear and accurate for implemetnation. > Dino> * Fix description in Map-Request section. Where we describe > Dino> Map-Reply Record, change "R-bit" to "M-bit". > > This may be small enough that it doesn't need to be called out. > > Dino> * Indicate SHA1 can be used as well for Map-Registers. > > Note that the text is still broken. The IPsec sha-1 is 96-bits > long not 128-bits long. > Also, according to some software I'm using but not verified with the > spec, 0 is an illegal SPI. > However this change is small and is supported by WG discussion. There is no reference to SHA-1 being 128 bits. Or do you mean the reference to SHA-128 should be changed to SHA-256. > Dino> * Indicate that a verifying Map-Request, for accepting > Dino> mapping data, should be sent over the the ALT (or to the > Dino> EID). > > Dino> * Reference IPsec RFC 4302. Comment from Sam and Brian Weis. > > Note this probably has bigger implications than you expect; it moves > you from 2401 to 4301 for the base architecture and that has huge > implications. We do not say we use IPsec in the document. We say we use the IPsec header format (i.e. AH). > Dino> * Put E-bit in Map-Reply to tell ITRs that the ETR supports > Dino> echo- noncing. Comment by Pedro and Dino. > > This might have needed an explicit wg list message, but I'm going to > let it slide: it's a really obviously useful idea. Thanks. Dino From hartmans@mit.edu Mon Sep 7 17:19: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 2A75828C0F6 for ; Mon, 7 Sep 2009 17:19:59 -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 k1HmehyInykZ for ; Mon, 7 Sep 2009 17:19: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 663273A67B5 for ; Mon, 7 Sep 2009 17:19:58 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C0A1F51C9; Mon, 7 Sep 2009 20:20:14 -0400 (EDT) To: "Joel M. Halpern" References: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> <4AA59E78.8020607@joelhalpern.com> From: Sam Hartman Date: Mon, 07 Sep 2009 20:20:14 -0400 In-Reply-To: <4AA59E78.8020607@joelhalpern.com> (Joel M. Halpern's message of "Mon\, 07 Sep 2009 19\:59\:52 -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] #18: record count >1 for map request X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 00:19:59 -0000 >>>>> "Joel" == Joel M Halpern writes: Joel> After exchanging a few emails with Dino, I can think what is Joel> in the draft is sufficient to address the issue. OK, if no one objects by Friday we're done with this issue. From hartmans@mit.edu Mon Sep 7 17:25: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 BAB043A684C for ; Mon, 7 Sep 2009 17:25:46 -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 5RnXYhabrcDi for ; Mon, 7 Sep 2009 17:25:46 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 0C7823A6835 for ; Mon, 7 Sep 2009 17:25:45 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8ACE351CB; Mon, 7 Sep 2009 20:26:02 -0400 (EDT) To: Sam Hartman References: <20090907234129.BB52151C9@carter-zimmerman.suchdamage.org> From: Sam Hartman Date: Mon, 07 Sep 2009 20:26:02 -0400 In-Reply-To: <20090907234129.BB52151C9@carter-zimmerman.suchdamage.org> (Sam Hartman's message of "Mon\, 7 Sep 2009 19\:41\:29 -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] Confirming Consensus on RLOC probing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 00:25:46 -0000 >>>>> "Sam" == Sam Hartman writes: Sam> If you've read the specific text in Dino's 04 proposal on Sam> this issue, please let the list know. Comments are of course Sam> welcome. _______________________________________________ Sam> lisp mailing list lisp@ietf.org Sam> https://www.ietf.org/mailman/listinfo/lisp I've read the text and certainly have no concerns about it going into 04. Long term I'm not sure that overloading rloc reachability probes onto the map reply/request messages is a good idea. Here are some things I think you may want to do with RLOC probes: * supply MTU probing information for the new PMTU algorithm * Establish a nonce to prevent certain spoofing attacks On the other hand a lot of security models we might adopt involve proving that someone can send from a given RLOC and wants traffic for a given EID at that RLOC before we send any significant traffic to that RLOC. Mixed in with this is some concerns I have about the complexity of the map reply and request handling in the current spec. I think I'd need to actually work through a state machine for a map cache in an ITR before I'd have a firm opinion. Also, the above assumes we have an understanding of our security and MTU related goals, both of which I believe to be false. So, the net of my comment is that this seems like a fine starting point but we may end up revising things later. From hartmans@mit.edu Mon Sep 7 17:27: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 83B233A6867 for ; Mon, 7 Sep 2009 17:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 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 Wbmo3TxtWu1q for ; Mon, 7 Sep 2009 17:27:54 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id CDC803A6835 for ; Mon, 7 Sep 2009 17:27:54 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4CF0051CB; Mon, 7 Sep 2009 20:28:11 -0400 (EDT) To: Jari Arkko References: <20090808031330.BB9726BE5CA@mercury.lcs.mit.edu> <4AA553BE.4020509@piuha.net> From: Sam Hartman Date: Mon, 07 Sep 2009 20:28:11 -0400 In-Reply-To: <4AA553BE.4020509@piuha.net> (Jari Arkko's message of "Mon\, 07 Sep 2009 21\:41\:02 +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: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] xTR to xTR via nat64 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 00:27:55 -0000 >>>>> "Jari" == Jari Arkko writes: Jari> Noel, (I know my reply is late) >> 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? >> Jari> My preference is to not design the protocol to handle this case. We've heard a numhber of people speak on this issue all wanting to rule it out of scope. So, I now think I have enough input to rule it out of scope. From mrw@lilacglade.org Mon Sep 7 17:35: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 DBCE23A69E3 for ; Mon, 7 Sep 2009 17:35: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 yq4cv3QUiqhH for ; Mon, 7 Sep 2009 17:35:32 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id EFEF93A65A6 for ; Mon, 7 Sep 2009 17:35:31 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n880ZpvZ092498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Sep 2009 20:35:52 -0400 (EDT) (envelope-from mrw@lilacglade.org) Message-Id: From: Margaret Wasserman To: trac@localhost.hactrn.net In-Reply-To: <066.05400d447ae9dbcf77be1ad4ee9237d7@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: Mon, 7 Sep 2009 20:35:50 -0400 References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> <066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 00:35:32 -0000 On Sep 7, 2009, at 7:18 PM, lisp issue tracker wrote: > In Dino's proposed 04 text the following is added: > > o A "gleaned" map-cache entry, one learned from the source RLOC of a > received encapsulated packet, is only stored and used for a few > seconds, pending verification. Verification is performed by > sending a Map-Request to the source EID (the inner header IP > source address) of the received encapsulated packet. A reply to > this "verifying Map-Request" is used to fully populate the map- > cache entry for the "gleaned" EID and is stored and used for the > time indicated from the TTL field of a received Map-Reply. > > We're still waiting to hear back from the WG and Margaret on this > text. While this text is better than what was in the -03 draft, it isn't good enough, IMO. On the list, we discussed an additional requirement that gleaned mappings will never overwrite mappings that were received in map replies. Also, I am concerned about the implications of this behavior in the case of intentional spoofing. If the attacker sends a message to create the gleaned mapping, he will also know that the host will soon send a request for that EID. In that case, he _could_ send a large- enough number of map replies for that EID, all with difference nonce values, perhaps covering a non-trivial percentage of the 24-bit nonce space. What is an ITR supposed to do if it receives two different responses to the map request for the gleaned address? Margaret From mrw@lilacglade.org Mon Sep 7 17: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 BB3253A6A27 for ; Mon, 7 Sep 2009 17:38:39 -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 QFdZ8EBBjiTe for ; Mon, 7 Sep 2009 17:38:39 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id E83F63A695F for ; Mon, 7 Sep 2009 17:38:38 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n880d5qi092608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Sep 2009 20:39:05 -0400 (EDT) (envelope-from mrw@lilacglade.org) Message-Id: <5F97F934-5508-46C7-8778-1978E4BD04CF@lilacglade.org> From: Margaret Wasserman To: lisp@ietf.org In-Reply-To: <066.05400d447ae9dbcf77be1ad4ee9237d7@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: Mon, 7 Sep 2009 20:39:05 -0400 References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> <066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org> X-Mailer: Apple Mail (2.935.3) Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 00:38:39 -0000 On Sep 7, 2009, at 7:18 PM, lisp issue tracker wrote: > In Dino's proposed 04 text the following is added: > > o A "gleaned" map-cache entry, one learned from the source RLOC of a > received encapsulated packet, is only stored and used for a few > seconds, pending verification. Verification is performed by > sending a Map-Request to the source EID (the inner header IP > source address) of the received encapsulated packet. A reply to > this "verifying Map-Request" is used to fully populate the map- > cache entry for the "gleaned" EID and is stored and used for the > time indicated from the TTL field of a received Map-Reply. > > We're still waiting to hear back from the WG and Margaret on this > text. While this text is better than what was in the -03 draft, it isn't good enough, IMO. On the list, we discussed an additional requirement that gleaned mappings will never overwrite mappings that were received in map replies. Also, I am concerned about the implications of this behavior in the case of intentional spoofing. If the attacker sends a message to create the gleaned mapping, he will also know that the host will soon send a request for that EID. In that case, he _could_ send a large- enough number of map replies for that EID, all with difference nonce values, perhaps covering a non-trivial percentage of the 24-bit nonce space. What is an ITR supposed to do if it receives two different responses to the map request for the gleaned address? Margaret From mrw@sandstorm.net Mon Sep 7 17: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 E514C3A65A6 for ; Mon, 7 Sep 2009 17:42:09 -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 yYsRxUZxQbZf for ; Mon, 7 Sep 2009 17:42:09 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 2B35A3A67D1 for ; Mon, 7 Sep 2009 17:42:08 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n880gY8x092717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Sep 2009 20:42:34 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <9C2EC0DE-06A5-4929-A120-B40BCE8AD444@sandstorm.net> From: Margaret Wasserman To: trac@localhost.amsl.com In-Reply-To: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@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: Mon, 7 Sep 2009 20:42:33 -0400 References: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #18: record count >1 for map request X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 00:42:10 -0000 On Sep 7, 2009, at 6:57 PM, lisp issue tracker wrote: > From the proposed lisp 04 text > Record Count: The number of records in this request message. A > record is comprised of the portion of the packet that is labeled > 'Rec' above and occurs the number of times equal to Record > count. > For this version of the protocol specification, a receiver MUST > accept and process a record count of one or greater but a sender > MUST always set the record count to one. This text still doesn't say what a receiver should do if receives a record count greater than 1... Should it throw the packet away? Should it assume that there is only one record, and proceed accordingly? Should it assume that there are N records in the packet (as indicated in the Record Count), but only process the first one? Should it do something with multiple records? If so, what? Margaret From jmh@joelhalpern.com Mon Sep 7 18:04: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 3BDBE3A685B for ; Mon, 7 Sep 2009 18:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=-0.291, 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 tRV-97tQN0JX for ; Mon, 7 Sep 2009 18:04:40 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 97E903A679F for ; Mon, 7 Sep 2009 18:04:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CEA303228086; Mon, 7 Sep 2009 18:05:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.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 hgblob.tigertech.net (Postfix) with ESMTP id 4AEE73228027; Mon, 7 Sep 2009 18:05:09 -0700 (PDT) Message-ID: <4AA5ADC3.3060707@joelhalpern.com> Date: Mon, 07 Sep 2009 21:05:07 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Margaret Wasserman References: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> <9C2EC0DE-06A5-4929-A120-B40BCE8AD444@sandstorm.net> In-Reply-To: <9C2EC0DE-06A5-4929-A120-B40BCE8AD444@sandstorm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] #18: record count >1 for map request X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 01:04:41 -0000 Actually, I read this as saying it (the receivers who receives a record count greater than 1) should simply process all of the records ) receive and process") which seems sufficient to me. Joel Margaret Wasserman wrote: > > On Sep 7, 2009, at 6:57 PM, lisp issue tracker wrote: >> From the proposed lisp 04 text >> Record Count: The number of records in this request message. A >> record is comprised of the portion of the packet that is labeled >> 'Rec' above and occurs the number of times equal to Record count. >> For this version of the protocol specification, a receiver MUST >> accept and process a record count of one or greater but a sender >> MUST always set the record count to one. > > This text still doesn't say what a receiver should do if receives a > record count greater than 1... > > Should it throw the packet away? > > Should it assume that there is only one record, and proceed accordingly? > > Should it assume that there are N records in the packet (as indicated in > the Record Count), but only process the first one? > > Should it do something with multiple records? If so, what? > > Margaret > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From trac@tools.ietf.org Mon Sep 7 18:27: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 66D493A68C1 for ; Mon, 7 Sep 2009 18:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 UtY2HRuQi6LC for ; Mon, 7 Sep 2009 18:27:57 -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 8C5E53A67F1 for ; Mon, 7 Sep 2009 18:27:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MkpVS-00073Y-8D; Mon, 07 Sep 2009 18:28:26 -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: Tue, 08 Sep 2009 01:28:26 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/21 Message-ID: <060.2f6008fac67bff8ffd8bab747df7cd0b@tools.ietf.org> X-Trac-Ticket-ID: 21 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] #21: Section 5.1 behavior 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: Tue, 08 Sep 2009 01:27:58 -0000 #21: Section 5.1 behavior ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@mit.edu | Owner: Type: technical | Status: new Priority: minor | Component: alt Severity: - | Keywords: ----------------------------------+----------------------------------------- Section 5.1 of the alt document is confused about its role. It describes its context as describing ITR traffic handling. That belongs in draft-ietf-lisp not in draft-ietf-lisp-alt. All draft-ietf-lisp-alt should do is describe what happens when an ITR wants to use the alt to discover the mapping of a packet. This comment is mostly editorial: the text can be reworded in terms of the mapping behavior. In addition, section 5.1 seems to only describe data probes, not map request behavior. The section should either be retitled to make it clear that it only discusses data probes or should be changed to discuss both cases. My preference is that the section discuss both cases. Finally, the text does not make it clear what the outer source address of the packet over the ALT is. I can see a couple of possibilities. First, you could use the local address of the GRE interface over which you're forwarding the packet if it has an address. Second you could use an RLOC address of one of your non-alt interfaces. Presumably you want the second option, so the text should say this. -- Ticket URL: lisp LISP WG document issues From dino@cisco.com Mon Sep 7 19:13: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 5958928C0F6 for ; Mon, 7 Sep 2009 19:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 Zy2Cdr6Q4Wbq for ; Mon, 7 Sep 2009 19:13:54 -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 D10783A69E4 for ; Mon, 7 Sep 2009 19:13:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgAAD9bpUqQ/uCLe2dsb2JhbACbPgEBFiQGpjKIQwGOcQWEGA X-IronPort-AV: E=Sophos;i="4.44,350,1249257600"; d="scan'208";a="48828532" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Sep 2009 02:14:21 +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 n882ELuM021467; Tue, 8 Sep 2009 04:14:21 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n882ELKW020353; Tue, 8 Sep 2009 02:14:21 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 04:14:21 +0200 Received: from [192.168.1.2] ([10.21.76.65]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 04:14:20 +0200 Message-Id: <6CC7FE39-8B40-4473-8A05-99C12DC7A05F@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <5F97F934-5508-46C7-8778-1978E4BD04CF@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: Mon, 7 Sep 2009 19:14:00 -0700 References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> <066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org> <5F97F934-5508-46C7-8778-1978E4BD04CF@lilacglade.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 02:14:20.0979 (UTC) FILETIME=[13A48830:01CA302A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2682; t=1252376061; x=1253240061; c=relaxed/simple; s=amsdkim2001; 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#8=3A=20Limits=20on=20=22Glean ed=22=20Map=20Entries=20Not=20Clear |Sender:=20; bh=V7wCxXFch4XfC58ovIv75+WaLRbb+8eGsCh+9LkzGGw=; b=bpWKMqyiAzgAF77F7WPWunjaY8/YzoevCW+KrHx0p3yBPW8NPvdX2l8EIP mGwBbFeXXaGbMXL0tUhnuvG1tPKjob+ePYP0e4gEAw1vFxB5jOw+bhNzLU86 9Cb5y45GIJ; Authentication-Results: ams-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 02:13:55 -0000 > On Sep 7, 2009, at 7:18 PM, lisp issue tracker wrote: > >> In Dino's proposed 04 text the following is added: >> >> o A "gleaned" map-cache entry, one learned from the source RLOC of a >> received encapsulated packet, is only stored and used for a few >> seconds, pending verification. Verification is performed by >> sending a Map-Request to the source EID (the inner header IP >> source address) of the received encapsulated packet. A reply to >> this "verifying Map-Request" is used to fully populate the map- >> cache entry for the "gleaned" EID and is stored and used for the >> time indicated from the TTL field of a received Map-Reply. >> >> We're still waiting to hear back from the WG and Margaret on this >> text. > > While this text is better than what was in the -03 draft, it isn't > good enough, IMO. > > On the list, we discussed an additional requirement that gleaned > mappings will never overwrite mappings that were received in map > replies. Right, and the text above does not imply that. The verifying Map- Request is responded by a Map-Reply. It is the contents of the Map- Reply that is stored in the map-cache. > Also, I am concerned about the implications of this behavior in the > case of intentional spoofing. If the attacker sends a message to > create the gleaned mapping, he will also know that the host will > soon send a You need to be clear about the case. Is the attacker spoofing the address of a real locator or is the attack spoofing the mapping data? > request for that EID. Yes, but the Map-Request will never be sent to the attacker when it is sent into the mapping database system. > In that case, he _could_ send a large-enough number of map replies > for that EID, all with difference nonce values, perhaps covering a > non-trivial percentage of the 24-bit nonce space. Who is he? The attacker? Nope, that won't happen, the attacker won't get the Map-Requests so it can't Map-Reply. And if it chooses to Map- Reply on its own, the ITR won't accept unsolicited Map-Replies. > What is an ITR supposed to do if it receives two different responses > to the map request for the gleaned address? What do you mean by different. In our implementation, if one is received with the wrong nonce, then the Map-Reply is rejected and a spoof-alert log message is issued. If the later comes in with the right nonce, it is accepted. So not sure what you are asking. Dino > > Margaret > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Mon Sep 7 19:25: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 B9AA93A6838 for ; Mon, 7 Sep 2009 19:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 jbCm7tG0FIiX for ; Mon, 7 Sep 2009 19:25: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 C8CE43A67FF for ; Mon, 7 Sep 2009 19:25:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN5dpUqrR7PD/2dsb2JhbADCPYhDAY5zBYQY X-IronPort-AV: E=Sophos;i="4.44,350,1249257600"; d="scan'208";a="383917952" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 08 Sep 2009 02:25: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 n882PWK0010225; Mon, 7 Sep 2009 19:25: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 n882PVHj012590; Tue, 8 Sep 2009 02:25:31 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, 7 Sep 2009 19:25:31 -0700 Received: from [192.168.1.2] ([10.21.76.65]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 19:25:31 -0700 Message-Id: <57B6EE3D-919C-4D5A-93A3-F2601E450C31@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <9C2EC0DE-06A5-4929-A120-B40BCE8AD444@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: Mon, 7 Sep 2009 19:25:30 -0700 References: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> <9C2EC0DE-06A5-4929-A120-B40BCE8AD444@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 02:25:31.0531 (UTC) FILETIME=[A352A5B0:01CA302B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1415; t=1252376732; x=1253240732; 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=20#18=3A=20record=20count=20> 1=20=20for=20map=20request |Sender:=20; bh=UGqjOZpkGaZMZmUnOLe3IST3ejnhAgMLX3wY77bGpYA=; b=SMKksmmbtrrWCo8s/khGd4fHNY6hU8Dsl1EC85pZ8nkK9HO6sxXENPBHGS 4Dz+++WuXQ8FrJ/THNJHvEp90nijPB4UQsli3CvSSMmE7toaucM/RUWxqgNS sOWGc5kobM; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #18: record count >1 for map request X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 02:25:03 -0000 > On Sep 7, 2009, at 6:57 PM, lisp issue tracker wrote: >> From the proposed lisp 04 text >> Record Count: The number of records in this request message. A >> record is comprised of the portion of the packet that is labeled >> 'Rec' above and occurs the number of times equal to Record >> count. >> For this version of the protocol specification, a receiver MUST >> accept and process a record count of one or greater but a sender >> MUST always set the record count to one. > > This text still doesn't say what a receiver should do if receives a > record count greater than 1... Right, because the text in processing a Map-Request says what to do. This section is just describing the Record Count field and not the entire protocol. > Should it throw the packet away? "MUST accept" above should tell you it means to not throw it away. > Should it assume that there is only one record, and proceed > accordingly? "a record count of one or greater" above should tell you that the receiver should expect more than one record. > Should it assume that there are N records in the packet (as > indicated in the Record Count), but only process the first one? No, why would you think that. The text never said that so don't assume anything else. Dino > Should it do something with multiple records? If so, what? > > Margaret > > From dino@cisco.com Mon Sep 7 19:29: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 B89873A67F8 for ; Mon, 7 Sep 2009 19:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 x4RkMzSM+53X for ; Mon, 7 Sep 2009 19:29: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 EC2D73A6778 for ; Mon, 7 Sep 2009 19:29:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAP9epUqrR7PE/2dsb2JhbADCN4hDAY5zBYQYil0 X-IronPort-AV: E=Sophos;i="4.44,350,1249257600"; d="scan'208";a="383920199" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Sep 2009 02:30:16 +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 n882UGrs028215; Mon, 7 Sep 2009 19:30:16 -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 n882UGt7015065; Tue, 8 Sep 2009 02:30:16 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, 7 Sep 2009 19:30:16 -0700 Received: from [192.168.1.2] ([10.21.76.65]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 19:30:15 -0700 Message-Id: <2EEEE52E-00C6-4AC2-AD54-CD8D3A567952@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 v936) Date: Mon, 7 Sep 2009 19:30:15 -0700 References: <20090907234129.BB52151C9@carter-zimmerman.suchdamage.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 02:30:15.0691 (UTC) FILETIME=[4CB205B0:01CA302C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2144; t=1252377016; x=1253241016; 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]=20Confirming=20Consensus=20on=20 RLOC=20probing |Sender:=20; bh=00SpRqOWgPhUVkcp+m0mwsoOu2X/iGjwsGhdKMfcPpQ=; b=mnzd4JXfUV0MaiWNUHczhrpulit9M9HeXg6BMyihZL9ipyY4RzEtYnLQqY vHgg1N6n71O9+EWGJ5Veu8zVkOJSkM+NCdbfrYM2xEWuBaHMK1eb+ridqRNL rUesH7Zfzv; 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] Confirming Consensus on RLOC probing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 02:29:47 -0000 >>>>>> "Sam" == Sam Hartman writes: > > Sam> If you've read the specific text in Dino's 04 proposal on > Sam> this issue, please let the list know. Comments are of course > Sam> welcome. _______________________________________________ > Sam> lisp mailing list lisp@ietf.org > Sam> https://www.ietf.org/mailman/listinfo/lisp > > > I've read the text and certainly have no concerns about it going into > 04. Long term I'm not sure that overloading rloc reachability probes > onto the map reply/request messages is a good idea. > > Here are some things I think you may want to do with RLOC probes: > > * supply MTU probing information for the new PMTU algorithm That won't work. If I send you a probe and say that my MTU is x, you might not use the same path to get to me. Plus you need the help of intermediate routers to tell you the effective MTU. Using Path MTU discovery as already specified in its RFC will suffice. > * Establish a nonce to prevent certain spoofing attacks It is there. If you use a Map-Request for an RLOC-probe, which is what is specified, then a nonce is in the packet. > On the other hand a lot of security models we might adopt involve > proving that someone can send from a given RLOC and wants traffic for > a given EID at that RLOC before we send any significant traffic to > that RLOC. If you do this, you increase packet loss. > Mixed in with this is some concerns I have about the complexity of the > map reply and request handling in the current spec. I think I'd need > to actually work through a state machine for a map cache in an ITR > before I'd have a firm opinion. It is really simple Sam. I wonder where you think the complexity is. > Also, the above assumes we have an understanding of our security and > MTU related goals, both of which I believe to be false. Why do you think that? Because from your commentary, I think you didn't understand what's designed. > So, the net of my comment is that this seems like a fine starting > point but we may end up revising things later. Dino From trac@tools.ietf.org Mon Sep 7 19: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 5EF7A3A68DE for ; Mon, 7 Sep 2009 19:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 pKhML8oIluT7 for ; Mon, 7 Sep 2009 19:31:22 -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 9FFBE3A68A7 for ; Mon, 7 Sep 2009 19:31:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MkqUp-0004yC-1H; Mon, 07 Sep 2009 19:31:51 -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: Tue, 08 Sep 2009 02:31:50 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/22 Message-ID: <060.ea8474f8e9e720ff4a5501041a5c944c@tools.ietf.org> X-Trac-Ticket-ID: 22 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] #22: An ETR MUST consume UDP port 4342 packets not addressed to it 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: Tue, 08 Sep 2009 02:31:23 -0000 #22: An ETR MUST consume UDP port 4342 packets not addressed to it ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@mit.edu | Owner: Type: technical | Status: new Priority: major | Component: alt Severity: - | Keywords: ----------------------------------+----------------------------------------- Two aspects of the MS protocol require that an ETR consume packets not addressed to it. (There are also cases where an ETR or LISP+alt router consumes alt packets not addressed to it; those cases seem fine to me. If desired I can explain my reasoning.) # an ITR sends an encapsulated map request to a map resolver # an map server sends an encapsulated request to an ETR An encapsulated map request typically has the source RLOC of the ITR for both the inner and outer header, and has the EID of the destination of the map request for the inner IP header. The outer destination UDP port is 4341 (the LISP data port). The inner destination UDP port is 4342. The problem here is that the box doing LISP decapsulation needs to do special processing on packets not destined for it. This complicates the data plane implementation. Also, this violates the end-to-end principle and the IP service model. There are very few situations when a router is expected to consume a packet not destined for it; none of them apply here as far as I can tell. I think the architecture is bad enough that this should change. But the practical effects are also problematic: * The data plane stack on the router needs to handle IP options, hop-by- hop options, and destination options the same way as the UDP stack in the control plane in order to avoid inconsistent behavior. * Whether you reach port 4342 on the end-system named by an EID or whether your packet is consumed by an intermediate router depends on where you are in the topology. Instead, I propose that: An ITR should send a UDP packet with source IP address of one of its RLOCs, destination IP address of the map resolver's RLOC, and destination UDP port 4342. The map resolver should receive this packet and generate a similar map request over the alt with source IP address of the ITR's RLOC, destination address of the EID within the map request to UDP port 4342. We need to decide how to handle the situation where the source RLOC and destination EID are in different address families. I don't think this case is fully specified with the existing mechanism, and I can think of some ways to make this work without encapsulation but need to think more about it. A map server should receive a packet on UDP port 4342 over an alt interface. (Receive is kind of a stretch here as huge chunks of the EID space may be "routed" to the map server.) If the EID is in a prefix registered with this map server, then the map server should generate a packet to UDP port 4342 on the RLOC registered with the prefix, source IP address copied from the packet received or the ALT and destination address of the RLOC of the prefix. One way to handle the cross-address-family complexity would be to have a way to specify the reply source locator in a mapping request. Really, unless you can include a locator of each address family you support in a mapping request, you cannot be sure that the other side will be able to reply to you. An alternative solution that would address my architectural concerns would be to send encapsulated map requests to some port other than 4341--perhaps even 4342. I don't prefer that solution and would like to explore all the options that avoid map request encapsulation before we go down that route, but it is an option of last resort to make it possible to unambiguously implement an ETR. -- Ticket URL: lisp LISP WG document issues From hartmans@mit.edu Mon Sep 7 19:44: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 A5F9C28C15A for ; Mon, 7 Sep 2009 19:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 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 2POvHxa+tb7q for ; Mon, 7 Sep 2009 19:44:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id BDC6C3A68DA for ; Mon, 7 Sep 2009 19:44:37 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BD51B51CB; Mon, 7 Sep 2009 22:44:51 -0400 (EDT) To: Dino Farinacci References: <20090907234129.BB52151C9@carter-zimmerman.suchdamage.org> <2EEEE52E-00C6-4AC2-AD54-CD8D3A567952@cisco.com> From: Sam Hartman Date: Mon, 07 Sep 2009 22:44:51 -0400 In-Reply-To: <2EEEE52E-00C6-4AC2-AD54-CD8D3A567952@cisco.com> (Dino Farinacci's message of "Mon\, 7 Sep 2009 19\:30\:15 -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] Confirming Consensus on RLOC probing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 02:44:38 -0000 >>>>> "Dino" == Dino Farinacci writes: Dino> That won't work. If I send you a probe and say that my MTU Dino> is x, you might not use the same path to get to me. Plus you Dino> need the help of intermediate routers to tell you the Dino> effective MTU. Take a look at RFC 4821. That spec requires that you send packets of various size and later determine whether they were received. Dino> Using Path MTU discovery as already specified in its RFC Dino> will suffice. I can't have that discussion until I understand the LISP deployment model enough to determine whether I believe the claims about MTU currently in the spec. So, for me at least, MTU is blocked on LISP deployment. >> On the other hand a lot of security models we might adopt >> involve proving that someone can send from a given RLOC and >> wants traffic for a given EID at that RLOC before we send any >> significant traffic to that RLOC. Dino> If you do this, you increase packet loss. Yep or queue them or use data probes. However, the IETF has had a lot of discussion about this issue in the MIP6, multi6, shim6 and HIP contexts. We're going to need to wade through all that discussion and either agree with it or disagree for good reason and sell our interpretation to the rest of the IETF. I think we're agreed that we don't want LISP to make the security of the Internet worse. I suspect we'll find we disagree on what the security of the Internet is and on what counts as worse. >> Mixed in with this is some concerns I have about the complexity >> of the map reply and request handling in the current spec. I >> think I'd need to actually work through a state machine for a >> map cache in an ITR before I'd have a firm opinion. Dino> It is really simple Sam. I wonder where you think the Dino> complexity is. Mostly surrounding security--when is it appropriate to trust a map reply or request, when is it appropriate to use RLOCs vs the mapping system, when I should trust data received in the map reply portion of the map request, etc etc. It's also the case that the requirements for what the ETR and ITR do are scattered somewhat across -lisp, -ms, and -alt; there are not good modularity boundaries in how the text is written, so confirming that the text is self consistent has been difficult for me. Similarly, there is a lot of complexity from lisp 1.0, lisp >1.5, cons etc still in the draft that gets in the way. From dino@cisco.com Mon Sep 7 19:53: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 181D53A6903 for ; Mon, 7 Sep 2009 19:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 DphHOMM6qhnS for ; Mon, 7 Sep 2009 19:53:11 -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 366DD3A68EA for ; Mon, 7 Sep 2009 19:53:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGNkpUqrR7O6/2dsb2JhbADCK4hDAY52BYIlgXOBWYkE X-IronPort-AV: E=Sophos;i="4.44,350,1249257600"; d="scan'208";a="238469309" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2009 02:53:40 +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 n882reeE025151; Mon, 7 Sep 2009 19:53:40 -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 n882reS9024683; Tue, 8 Sep 2009 02:53:40 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, 7 Sep 2009 19:53:40 -0700 Received: from [192.168.1.2] ([10.21.76.65]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 19:53:39 -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 v936) Date: Mon, 7 Sep 2009 19:53:39 -0700 References: <20090907234129.BB52151C9@carter-zimmerman.suchdamage.org> <2EEEE52E-00C6-4AC2-AD54-CD8D3A567952@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 02:53:39.0975 (UTC) FILETIME=[91B6C170:01CA302F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3138; t=1252378420; x=1253242420; 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]=20Confirming=20Consensus=20on=20 RLOC=20probing |Sender:=20; bh=/1ykXi5Dosu9n2EdGhvjcQkRbt5rjVSFXN58MgVR/GQ=; b=bDGgdz18l/XFLgz+8EUmUVoiPjayp1nT6jMUXdFAjczF4neySuQOyC6mmT EimDBrki7WUWGC2gUUc7lzFFbKuINcFXorKLPXjCrKc5Ay0s+gVvkm1BjW3H VkvzZmuE/g; 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] Confirming Consensus on RLOC probing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 02:53:12 -0000 >>>>>> "Dino" == Dino Farinacci writes: > > Dino> That won't work. If I send you a probe and say that my MTU > Dino> is x, you might not use the same path to get to me. Plus you > Dino> need the help of intermediate routers to tell you the > Dino> effective MTU. > Take a look at RFC 4821. That spec requires that you send packets of > various size and later determine whether they were received. We shouldn't put more mechanism in an optional procedure. Plus, you may not want to do make-before-break. So if you want to figure out the effective MTU, you drop packets in the meantime. > Dino> Using Path MTU discovery as already specified in its RFC > Dino> will suffice. > > I can't have that discussion until I understand the LISP deployment > model enough to determine whether I believe the claims about MTU > currently in the spec. > So, for me at least, MTU is blocked on LISP deployment. >>> On the other hand a lot of security models we might adopt >>> involve proving that someone can send from a given RLOC and >>> wants traffic for a given EID at that RLOC before we send any >>> significant traffic to that RLOC. > > Dino> If you do this, you increase packet loss. > > Yep or queue them or use data probes. However, the IETF has had a lot That is not practical in a hardware implementation. > of discussion about this issue in the MIP6, multi6, shim6 and HIP > contexts. We're going to need to wade through all that discussion and > either agree with it or disagree for good reason and sell our > interpretation to the rest of the IETF. I think we're agreed that we > don't want LISP to make the security of the Internet worse. I suspect > we'll find we disagree on what the security of the Internet is and on > what counts as worse. > > >>> Mixed in with this is some concerns I have about the complexity >>> of the map reply and request handling in the current spec. I >>> think I'd need to actually work through a state machine for a >>> map cache in an ITR before I'd have a firm opinion. > > Dino> It is really simple Sam. I wonder where you think the > Dino> complexity is. > Mostly surrounding security--when is it appropriate to trust a map > reply or request, when is it appropriate to use RLOCs vs the mapping > system, when I should trust data received in the map reply portion of > the map request, etc etc. You will see that what we have is elegant and simple and probably handles most real security threats. Darrel can share more with you. > It's also the case that the requirements for what the ETR and ITR do > are scattered somewhat across -lisp, -ms, and -alt; there are not good > modularity boundaries in how the text is written, so confirming that > the text is self consistent has been difficult for me. Similarly, > there is a lot of complexity from lisp 1.0, lisp >1.5, cons etc still > in the draft that gets in the way. Well, we need to keep some history as to what research we tried so new people coming into the work don't cause us to keep repeating ourselves. Dino From jari.arkko@piuha.net Mon Sep 7 21:18: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 C24DD3A681D for ; Mon, 7 Sep 2009 21:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=-0.074, 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 3HNRa8P+PuNj for ; Mon, 7 Sep 2009 21:18:36 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B607E28C104 for ; Mon, 7 Sep 2009 21:18:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7CD46D6261; Tue, 8 Sep 2009 07:19:04 +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 qxljHbIrJx0Y; Tue, 8 Sep 2009 07:19:03 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C99C9D620D; Tue, 8 Sep 2009 07:19:03 +0300 (EEST) Message-ID: <4AA5DB37.8080407@piuha.net> Date: Tue, 08 Sep 2009 07:19:03 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Margaret Wasserman References: <20090811205547.C318B6BE59B@mercury.lcs.mit.edu> <4AA56AB7.9020909@piuha.net> <2F2FD8E3-9D14-41A6-BAC9-0BD883C96F50@sandstorm.net> In-Reply-To: <2F2FD8E3-9D14-41A6-BAC9-0BD883C96F50@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: Noel Chiappa , 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, 08 Sep 2009 04:18:36 -0000 Margaret, > When you say "the data itself is protected", I _think_ you mean > something different than Noel does. OK, I didn't realize that. > Noel is saying that the mechanism for adding mapping entries to the > mapping system is protected. This is currently true by virtue of the > fact that mapping registrations use IPsec AH, and nothing will be > added to the mapping system that isn't properly authorized. > > However, the data that is passed in a mapping reply is not > "protected". An ITR sends a mapping request to its mapping server. The > response will come back from another node (an ETR), and will contain > data that is not encrypted and cannot be authenticated. The only > "protection" on the response is that it contains a 32-bit nonce that > matches the request. So, anyone who can see the request (or guess its > contents) can send a spoofed response that will be accepted by the > requesting ITR. Even if two replies are received (one valid and one > spoofed), the ITR will have no means to tell the difference between them. > >> >> This is my preference as well. I'd like to see a security model that >> is based on protecting the data rather than the communications. This >> will also make it easier to distribute, cache, and re-distribute >> mapping information. > > I think this is a good general approach, but there is nothing in the > current protocol that does this. Yes, I realized this. I was making a statement on what I would personally like to see as the security function. Jari From mrw@sandstorm.net Tue Sep 8 06:33: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 523793A6A55 for ; Tue, 8 Sep 2009 06:33:14 -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 tjFgvKx99jYF for ; Tue, 8 Sep 2009 06:33:13 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 785623A683C for ; Tue, 8 Sep 2009 06:33:13 -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 n88DXUGV027286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Sep 2009 09:33:31 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <57B6EE3D-919C-4D5A-93A3-F2601E450C31@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, 8 Sep 2009 09:33:31 -0400 References: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> <9C2EC0DE-06A5-4929-A120-B40BCE8AD444@sandstorm.net> <57B6EE3D-919C-4D5A-93A3-F2601E450C31@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #18: record count >1 for map request X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 13:33:14 -0000 Hi Dino, On Sep 7, 2009, at 10:25 PM, Dino Farinacci wrote: >> On Sep 7, 2009, at 6:57 PM, lisp issue tracker wrote: >>> From the proposed lisp 04 text >>> Record Count: The number of records in this request message. A >>> record is comprised of the portion of the packet that is labeled >>> 'Rec' above and occurs the number of times equal to Record >>> count. >>> For this version of the protocol specification, a receiver MUST >>> accept and process a record count of one or greater but a sender >>> MUST always set the record count to one. This would be clearer to me if you changed the last sentence to read: "For this version of the protocol, a receiver MUST accept and process requests that contain one or more records, but a sender MUST only send requests containing one record." Margaret From lear@cisco.com Tue Sep 8 06:59: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 D2B9928C167 for ; Tue, 8 Sep 2009 06:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.286 X-Spam-Level: X-Spam-Status: No, score=-10.286 tagged_above=-999 required=5 tests=[AWL=0.313, 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 ZYYkXdSMFVnc for ; Tue, 8 Sep 2009 06:59:54 -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 968CA28C0E8 for ; Tue, 8 Sep 2009 06:59:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0AAHwApkqQ/uCKe2dsb2JhbACBU5lpAQEWJAaoHohDAY9HBYQY X-IronPort-AV: E=Sophos;i="4.44,352,1249257600"; d="scan'208";a="48883523" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Sep 2009 14:00:22 +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 n88E0MXA014829; Tue, 8 Sep 2009 16:00:22 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp1717.cisco.com [10.61.70.181]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n88E0MUV003628; Tue, 8 Sep 2009 14:00:22 GMT Message-ID: <4AA66376.3090107@cisco.com> Date: Tue, 08 Sep 2009 16:00:22 +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: trac@localhost.amsl.com References: <060.a6bdaf04b35955374257c35fafb40c20@tools.ietf.org> In-Reply-To: <060.a6bdaf04b35955374257c35fafb40c20@tools.ietf.org> 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=602; t=1252418422; x=1253282422; 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=20#19=3A=20mobility=20bit=20i n=20map=20reply |Sender:=20; bh=gNpPCp8UvfJWjN1zq8x+dkoQT925e/26tdqZuxOxAfM=; b=kw7NLOmmvnCSiwqnL30eUo8BMNA1baZAFV9lguOSDj+M8l8lOLmU9HUanx 0rL6YHOf2bP3O7Y3zSGhQ9wnWatZyBcCWjNpgm3ISJ8w6GscfE0ZRb6goaPE y0VAN7fbhn; 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] #19: mobility bit in map reply X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 13:59:54 -0000 On 9/8/09 1:13 AM, lisp issue tracker wrote: > I think that the best way forward is for us to decide on an IANA > assignment policy for the flags in the map reply. If that policy > permits the authors of the mobility arch draft to request a flag then > they can do so; if after whatever review we decide is necessary we > approve assigning a flag, then do so. Alternatively, put this on hold > until mobility is in scope for our chater. > Sam, this is a great way forward. It tackles not just the M bit but also potentially issues revolving around the R bit as well. Eliot From mrw@lilacglade.org Tue Sep 8 07:01: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 E78573A6905 for ; Tue, 8 Sep 2009 07:01:50 -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 ZVoX-s+sYLrr for ; Tue, 8 Sep 2009 07:01:49 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 8A2AB3A6847 for ; Tue, 8 Sep 2009 07:01:49 -0700 (PDT) Received: from OMTA23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA02.westchester.pa.mail.comcast.net with comcast id eE181c0051c6gX852E2LQq; Tue, 08 Sep 2009 14:02:20 +0000 Received: from [10.2.0.20] ([69.33.111.74]) by OMTA23.westchester.pa.mail.comcast.net with comcast id eE6b1c0071cMU3H3jE6dRC; Tue, 08 Sep 2009 14:06:44 +0000 Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <6CC7FE39-8B40-4473-8A05-99C12DC7A05F@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, 8 Sep 2009 10:02:09 -0400 References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> <066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org> <5F97F934-5508-46C7-8778-1978E4BD04CF@lilacglade.org> <6CC7FE39-8B40-4473-8A05-99C12DC7A05F@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 14:01:51 -0000 On Sep 7, 2009, at 10:14 PM, Dino Farinacci wrote: >> On Sep 7, 2009, at 7:18 PM, lisp issue tracker wrote: >> >>> In Dino's proposed 04 text the following is added: >>> >>> o A "gleaned" map-cache entry, one learned from the source RLOC >>> of a >>> received encapsulated packet, is only stored and used for a few >>> seconds, pending verification. Verification is performed by >>> sending a Map-Request to the source EID (the inner header IP >>> source address) of the received encapsulated packet. A reply to >>> this "verifying Map-Request" is used to fully populate the map- >>> cache entry for the "gleaned" EID and is stored and used for the >>> time indicated from the TTL field of a received Map-Reply. >>> >>> We're still waiting to hear back from the WG and Margaret on this >>> text. >> >> While this text is better than what was in the -03 draft, it isn't >> good enough, IMO. >> >> On the list, we discussed an additional requirement that gleaned >> mappings will never overwrite mappings that were received in map >> replies. > > Right, and the text above does not imply that. The verifying Map- > Request is responded by a Map-Reply. It is the contents of the Map- > Reply that is stored in the map-cache. I think we should explicitly state that a "gleaned" map-cache entry will not be created if a map entry already exists for an EID prefix containing the EID in the received packet, even if the map-cache entry indicates that packets to that EID should be sent to a different ETR. > >> Also, I am concerned about the implications of this behavior in the >> case of intentional spoofing. If the attacker sends a message to >> create the gleaned mapping, he will also know that the host will >> soon send a > > You need to be clear about the case. Is the attacker spoofing the > address of a real locator or is the attack spoofing the mapping data? The attacker is trying to get an ITR to use a bogus map cache entry, so that data will be sent to the attacker's ETR (and processed by the attacker's end-system) instead of to the actual ETR that serves the EID. > Yes, but the Map-Request will never be sent to the attacker when it > is sent into the mapping database system. True. >> In that case, he _could_ send a large-enough number of map replies >> for that EID, all with difference nonce values, perhaps covering a >> non-trivial percentage of the 24-bit nonce space. > > Who is he? The attacker? Nope, that won't happen, the attacker won't > get the Map-Requests so it can't Map-Reply. And if it chooses to Map- > Reply on its own, the ITR won't accept unsolicited Map-Replies. There is nothing tying a map reply to the original map request except for the nonce. So, if an attacker can reliably cause an ITR to send a map request for a particular EID, he can then send map replies for that EID, even though he didn't see the request. If he sends a bunch (potentially thousands) of map replies over the next several seconds, perhaps one of them will match the nonce of the request that the ITR actually sent. In that case the mapping information from the reply may be added to the cache instead of the mapping entry from the ETR that genuinely serves the indicated EID. This is a percentages game... While it might only work 1 in a ~10,000 times, there isn't any reason why the attacker couldn't try it 10,000 times, using different EIDs and/or targeting different ITRs until it works. The spoofed entries could contain a long TTL and a short prefix, so that the attacker could cause an ITR to use his ETR for a large number of EIDs for a long time. If the LISP ITR were run by an ISP, for example, this could cause all of the ISPs customers to connect to the attacker instead of to the real site(s) that are associated with those EIDs. There are a couple ways to deal with this attack that I can think of: (1) Make the nonce in the map request/reply larger (64-bits or more?), so that there is a much smaller chance that an attacker can hit upon a matching nonce. This could probabilistically limit the case where attackers could create a bogus map cache entry using this mechanism to on-path attackers. I don't have the security analysis skills to know how long the nonce needs to be to make it large enough to thwart an off-path attacker, but we could probably get someone from the security area to help us figure that out. (2) Require that the reply be sent from the map resolver to whom the request was sent, perhaps with additional authentication to indicate that it was actually sent from that map resolver. This would make it necessary for an attacker to gain control of a map resolver and/or to reconfigure the ITR in order to inject bogus map cache entries. There are probably other ways to thwart this type of attack, so we might want to talk to security folks to see if there are other options. >> What is an ITR supposed to do if it receives two different >> responses to the map request for the gleaned address? > > What do you mean by different. In our implementation, if one is > received with the wrong nonce, then the Map-Reply is rejected and a > spoof-alert log message is issued. If the later comes in with the > right nonce, it is accepted. What happens if you get two different replies that both have the right nonce? Will you accept the first and then accept the second, overwriting the information received in the first? Or will you accept the first, throw away the state related to that nonce, and reject the second because it doesn't match any open nonce? Either way, if an attacker can send a reply with a matching nonce (regardless of how many replies he sends that don't match), you will end-up using his mapping about 50% of the time, instead of the mapping from the real ETR that serves that EID prefix. Margaret From mrw@sandstorm.net Tue Sep 8 07:08: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 7EB1228C0DC for ; Tue, 8 Sep 2009 07:08:08 -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 41Rbe7QkyQ7U for ; Tue, 8 Sep 2009 07:08:07 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id A2C403A6A70 for ; Tue, 8 Sep 2009 07:08:07 -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 n88E790C028936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Sep 2009 10:07:09 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <72871E32-9956-4888-9E4C-6E58E4D44631@sandstorm.net> From: Margaret Wasserman To: Eliot Lear In-Reply-To: <4AA66376.3090107@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, 8 Sep 2009 10:07:10 -0400 References: <060.a6bdaf04b35955374257c35fafb40c20@tools.ietf.org> <4AA66376.3090107@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #19: mobility bit in map reply X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 14:08:08 -0000 On Sep 8, 2009, at 10:00 AM, Eliot Lear wrote: > On 9/8/09 1:13 AM, lisp issue tracker wrote: >> I think that the best way forward is for us to decide on an IANA >> assignment policy for the flags in the map reply. If that policy >> permits the authors of the mobility arch draft to request a flag then >> they can do so; if after whatever review we decide is necessary we >> approve assigning a flag, then do so. Alternatively, put this on >> hold >> until mobility is in scope for our chater. >> > > Sam, this is a great way forward. It tackles not just the M bit but > also potentially issues revolving around the R bit as well. Yes, and all of the other reserved bits for which there may be eventual uses. Dino, I have a good deal of experience writing IANA considerations sections (and reviewing them, enforcing them, etc.), so let me know if I can help with this. Margaret From dino@cisco.com Tue Sep 8 07:23: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 AC99E3A6818 for ; Tue, 8 Sep 2009 07:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 jMz5RzdNuAed for ; Tue, 8 Sep 2009 07:23: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 A771F3A681E for ; Tue, 8 Sep 2009 07:23:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,352,1249257600"; d="scan'208";a="238707608" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2009 14:23:55 +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 n88ENtjV031131; Tue, 8 Sep 2009 07:23:55 -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 n88ENt05020619; Tue, 8 Sep 2009 14:23:55 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, 8 Sep 2009 07:23:54 -0700 Received: from [192.168.1.3] ([10.21.75.115]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 07:23:54 -0700 Message-Id: From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <72871E32-9956-4888-9E4C-6E58E4D44631@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, 8 Sep 2009 07:23:54 -0700 References: <060.a6bdaf04b35955374257c35fafb40c20@tools.ietf.org> <4AA66376.3090107@cisco.com> <72871E32-9956-4888-9E4C-6E58E4D44631@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 14:23:54.0728 (UTC) FILETIME=[FED48E80:01CA308F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2417; t=1252419835; x=1253283835; 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#19=3A=20mobility=20bit=20in=2 0map=20reply |Sender:=20; bh=Mr9ygacqFvr9aCZD3kQItY/lJIGiNHuLOM7lICdPX5s=; b=YOK8TtDaEuL5c7WL+LqIvlJLHYBkfE8ntAD5MBgw+pmis+tKQhPB+JIStW +gerQF8URUh+oOQjmWRpQdxyiMe9yKEjLgmLOlQN2JnXxysJMiG0XmC2BS2p N+Z0NyHGNo; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #19: mobility bit in map reply X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 14:23:25 -0000 I don't see any value in having the main spec depend on other specifications. As someone who has implemented protocols for nearly 30 years, it has always been a hassle to chase down code-points and header formats in various documents. So it is much simpler and cohesive to have it in one place. Having said that, in the future we should have an IANA based assignment document. But all the flags (maybe with the exception of the M-bit in the Map-Reply) are pretty pertinent to the core functionality of LISP. But we made a decision early (with CONS, ALT, INTERWORKING, and MS) that we would put the packet formats in one place. We decided to have a "one-way dependency arrow" for the documents. That is, all the documents point to the main spec for packet formats and detailed procedures and the main document references the individual component documents which describe introductory ideas and specific details about the elements of operation for their respective functions. I would like to keep it that way. Or else, we get caught up in doing documentation procedures more than focusing on the implementation, experiments, and deployment. And throwing more people on the problem doesn't really help. Dino On Sep 8, 2009, at 7:07 AM, Margaret Wasserman wrote: > > On Sep 8, 2009, at 10:00 AM, Eliot Lear wrote: > >> On 9/8/09 1:13 AM, lisp issue tracker wrote: >>> I think that the best way forward is for us to decide on an IANA >>> assignment policy for the flags in the map reply. If that policy >>> permits the authors of the mobility arch draft to request a flag >>> then >>> they can do so; if after whatever review we decide is necessary we >>> approve assigning a flag, then do so. Alternatively, put this on >>> hold >>> until mobility is in scope for our chater. >>> >> >> Sam, this is a great way forward. It tackles not just the M bit but >> also potentially issues revolving around the R bit as well. > > Yes, and all of the other reserved bits for which there may be > eventual uses. > > Dino, I have a good deal of experience writing IANA considerations > sections (and reviewing them, enforcing them, etc.), so let me know > if I can help with this. > > Margaret > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Tue Sep 8 07:30: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 CFD4928C211 for ; Tue, 8 Sep 2009 07:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 2oCZJTZpPEJi for ; Tue, 8 Sep 2009 07:30:21 -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 7EDC028C213 for ; Tue, 8 Sep 2009 07:30:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEgHpkqrR7PE/2dsb2JhbADERIhDAY9IBYQY X-IronPort-AV: E=Sophos;i="4.44,352,1249257600"; d="scan'208";a="238709622" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2009 14:30:37 +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 n88EUbCo013425; Tue, 8 Sep 2009 07:30:37 -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 n88EUb6b018698; Tue, 8 Sep 2009 14:30: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); Tue, 8 Sep 2009 07:30:37 -0700 Received: from [192.168.1.3] ([10.21.75.115]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 07:30:37 -0700 Message-Id: <9FF017D6-AE9E-40B2-B21A-6F9A2482508C@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 v936) Date: Tue, 8 Sep 2009 07:30:36 -0700 References: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> <9C2EC0DE-06A5-4929-A120-B40BCE8AD444@sandstorm.net> <57B6EE3D-919C-4D5A-93A3-F2601E450C31@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 14:30:37.0426 (UTC) FILETIME=[EEDB6520:01CA3090] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1208; t=1252420238; x=1253284238; 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#18=3A=20record=20count=20>1=2 0=20for=20map=20request |Sender:=20; bh=KdkH7ScFewA0JmFy/nW7obfHWb3HnIKxOTsSVPC+u4c=; b=huWeqN71IRCkNJT0AmDRKq2y+BNAAViVP3hKP5JhCoJeYLCCulhFqvGfos 1kXziCqeh6oF/FxpH+FUK3Ovca653ssgVqC8xFdjX0WibLm0J6cU4d2eKZc8 DH/ujnYAbz; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #18: record count >1 for map request X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 14:30:22 -0000 > Hi Dino, > > On Sep 7, 2009, at 10:25 PM, Dino Farinacci wrote: > >>> On Sep 7, 2009, at 6:57 PM, lisp issue tracker wrote: >>>> From the proposed lisp 04 text >>>> Record Count: The number of records in this request message. A >>>> record is comprised of the portion of the packet that is labeled >>>> 'Rec' above and occurs the number of times equal to Record >>>> count. >>>> For this version of the protocol specification, a receiver MUST >>>> accept and process a record count of one or greater but a sender >>>> MUST always set the record count to one. > > This would be clearer to me if you changed the last sentence to read: > > "For this version of the protocol, a receiver MUST accept and > process requests that contain one or more records, but a sender MUST > only send requests containing one record." > > Margaret So you just deleted the word "specification", and added "request" a couple of times. Is that your intent? What about the last sentence: "Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol." I think we should keep it. Please confirm. Dino From jmh@joelhalpern.com Tue Sep 8 07:31: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 949CA28C217 for ; Tue, 8 Sep 2009 07:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=-1.488, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=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 dtLHehRo4pBs for ; Tue, 8 Sep 2009 07:31:05 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id EC1D328C1F3 for ; Tue, 8 Sep 2009 07:31:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 868653230FBB for ; Tue, 8 Sep 2009 07:31:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.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 hgblob.tigertech.net (Postfix) with ESMTP id 146F53230FBD for ; Tue, 8 Sep 2009 07:31:33 -0700 (PDT) Message-ID: <4AA66AC4.5010108@joelhalpern.com> Date: Tue, 08 Sep 2009 10:31:32 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: lisp@ietf.org References: <060.ea8474f8e9e720ff4a5501041a5c944c@tools.ietf.org> In-Reply-To: <060.ea8474f8e9e720ff4a5501041a5c944c@tools.ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] #22: An ETR MUST consume UDP port 4342 packets not addressed to it X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 14:31:06 -0000 In trying to understand this question, and its implications, I seem to have totally confused myself. (Sorry Dino. I think you explained this to me once before, and convinced me. But I can not reconstruct it now.) The underlying goal is to get a LISP control message, in this case a mapping request, from the source to the entity that can provide a useful answer. The ITR wants to send the request to its Map Server. The Map Server send the request over the ALT to the relevant Map Responder. The Map Responder sends the request to a relevant ETR. The Control request is an IP packet, with a UDP header, addressed to UDP port 4342. The body of the request includes the information as to the EID whose mapping is being sought, and the RLOC of the ITR who is making the request. By assumption, that RLOC is usable by the end ETR to send the response back to the ITR. So why do we need two UDP headers (and two IP headers.) The ITR can send the packet to the MS> So it should only need on IP header, source=ITR RLoc, Dest=MS RLoc. And one UDP header (for control message.) Similarly, the MR needs to send the message to the ETR. But the MR know the ETR Rloc. So a single IP header, source=MS RLoc, dest=ETR Rloc, and a single UDP header for the control message, would seem sufficient. This would mean that nodes are only processing messages addressed to themselves. This would also seem to be completely separate from the question of what format messages are sent over the GRE tunnel inside the ALT. Assuming I am missing something basic, I suspect we need some more text somewhere. I paged back and forth through the LISP spec, the LISP-ALT spec, and the LISP-MS spec. Yours, Joel lisp issue tracker wrote: > #22: An ETR MUST consume UDP port 4342 packets not addressed to it From lear@cisco.com Tue Sep 8 07:33: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 10E9328C21E for ; Tue, 8 Sep 2009 07:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.297 X-Spam-Level: X-Spam-Status: No, score=-10.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 dYjppgkkXfQf for ; Tue, 8 Sep 2009 07:33:31 -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 B7BF528C200 for ; Tue, 8 Sep 2009 07:33:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,352,1249257600"; d="scan'208";a="48887130" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Sep 2009 14:34:00 +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 n88EXx3f024258; Tue, 8 Sep 2009 16:33:59 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp1717.cisco.com [10.61.70.181]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n88EXxsa013759; Tue, 8 Sep 2009 14:33:59 GMT Message-ID: <4AA66B57.5040300@cisco.com> Date: Tue, 08 Sep 2009 16:33:59 +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: Dino Farinacci References: <060.a6bdaf04b35955374257c35fafb40c20@tools.ietf.org> <4AA66376.3090107@cisco.com> <72871E32-9956-4888-9E4C-6E58E4D44631@sandstorm.net> 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=480; t=1252420440; x=1253284440; 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#19=3A=20mobility=20bit=20in=2 0map=20reply |Sender:=20; bh=Um1+XABRl3QZGcWin7Tkr9Rz8gxOiGstu/KI02hle4M=; b=qEPsR8RtY0ZdHAR12VSYndikUJprEqWSJIgI143OlCKor4IAErTQ18iAnI BEqQfXwYqr51CJQ9wQIG5ILowBhyuc0Zmxa4t2jTDiuZtoj36MhmVGyRrRJh fpN9Q1RdSJ; 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] #19: mobility bit in map reply X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 14:33:32 -0000 Dino, Just one clarification- > Having said that, in the future we should have an IANA based > assignment document. But all the flags (maybe with the exception of > the M-bit in the Map-Reply) are pretty pertinent to the core > functionality of LISP. I wasn't thinking that you would have to rely on other documents for core flags that were well defined. I would expect that you would seed the IANA registry with those from the LISP core specification. Eliot From dino@cisco.com Tue Sep 8 07:34: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 D210B28C200 for ; Tue, 8 Sep 2009 07:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 lLkwQO7XVgbl for ; Tue, 8 Sep 2009 07:34:48 -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 1BBEF28C1F7 for ; Tue, 8 Sep 2009 07:34:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPwHpkqrR7PD/2dsb2JhbADEUYhDAY9KBYQY X-IronPort-AV: E=Sophos;i="4.44,352,1249257600"; d="scan'208";a="93502512" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 08 Sep 2009 14:35:17 +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 n88EZIUr010697; Tue, 8 Sep 2009 07:35:18 -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 n88EZI9C002263; Tue, 8 Sep 2009 14:35:18 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, 8 Sep 2009 07:35:18 -0700 Received: from [192.168.1.3] ([10.21.75.115]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 07:35:17 -0700 Message-Id: <49C053AD-E5ED-40CE-A518-9BC9D8A51C51@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 v936) Date: Tue, 8 Sep 2009 07:35:17 -0700 References: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> <9C2EC0DE-06A5-4929-A120-B40BCE8AD444@sandstorm.net> <57B6EE3D-919C-4D5A-93A3-F2601E450C31@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 14:35:17.0985 (UTC) FILETIME=[96154D10:01CA3091] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1545; t=1252420518; x=1253284518; 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#18=3A=20record=20count=20>1=2 0=20for=20map=20request |Sender:=20; bh=JbdK/aLFjNTPkduGCX+FCvI+ddESTM/3wD550z5A6ck=; b=bfR7uBWZiRSDz/820CY8FuidZnYocwLMVqIBTsD9ArLjZWuHM07SH3f9X6 bB85vFnOAHjC4gI7Cl3d4blHQGdgla9IwNjs8JfdEU1FuPQhzVXZ7ZDDnZ1O dQWIWfqtVo; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #18: record count >1 for map request X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 14:34:48 -0000 This this text satisfactory? Record Count: The number of records in this Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Dino On Sep 8, 2009, at 6:33 AM, Margaret Wasserman wrote: > > Hi Dino, > > On Sep 7, 2009, at 10:25 PM, Dino Farinacci wrote: > >>> On Sep 7, 2009, at 6:57 PM, lisp issue tracker wrote: >>>> From the proposed lisp 04 text >>>> Record Count: The number of records in this request message. A >>>> record is comprised of the portion of the packet that is labeled >>>> 'Rec' above and occurs the number of times equal to Record >>>> count. >>>> For this version of the protocol specification, a receiver MUST >>>> accept and process a record count of one or greater but a sender >>>> MUST always set the record count to one. > > This would be clearer to me if you changed the last sentence to read: > > "For this version of the protocol, a receiver MUST accept and > process requests that contain one or more records, but a sender MUST > only send requests containing one record." > > Margaret From jnc@mercury.lcs.mit.edu Tue Sep 8 07:43: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 0E16A28C232 for ; Tue, 8 Sep 2009 07:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 4cXLTo7XLPPk for ; Tue, 8 Sep 2009 07:43: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 E1A4828C239 for ; Tue, 8 Sep 2009 07:43:19 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 28FA36BE5FC; Tue, 8 Sep 2009 10:43:49 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090908144349.28FA36BE5FC@mercury.lcs.mit.edu> Date: Tue, 8 Sep 2009 10:43:49 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 14:43:21 -0000 > From: Margaret Wasserman > a "gleaned" map-cache entry will not be created if a map entry already > exists for an EID prefix containing the EID in the received packet, > even if the map-cache entry indicates that packets to that EID should > be sent to a different ETR. _Especially_ if the map-cache entry indicates that packets to that EID should be sent to a different ETR! :-) > if an attacker can reliably cause an ITR to send a map request for a > particular EID, he can then send map replies for that EID, even though > he didn't see the request. How do you know the attacker is male? Maybe they are female? :-) > If he sends a bunch (potentially thousands) of map replies over the > next several seconds, perhaps one of them will match the nonce > ... This is a percentages game... While it might only work 1 in a > ~10,000 times, there isn't any reason why the attacker couldn't try it > 10,000 times .. until it works. The spoofed entries could contain a > long TTL and a short prefix This is all perfectly true, but I don't think people are saying that the existing nonce is the perfect security mechanism for all time. Remember, the current effort is just an _experiment_, and it's not expected that it will be perfect in every way. If nothing else, lifetime-grade security probably means a lot more configuration, and as secure DNS is showing us, that can be a big hump to get over. I do think it would be good to have the right _basic mechanisms_ in place (i.e. fields in packets) so that if LISP catches on, we can later deploy better security in an interoperable way, but that's a separate matter. In the meantime, 'reply without matching nonce' probably out to be logged, so that we can at least detect DoS attacks (and it should be possible to disable the message, lest it itself become a DoS vector). It might also be good to temporarilly disable 'gleaning' of entries, to make this attack less viable. > There are a couple ways to deal with this attack that I can think of: > (1) Make the nonce in the map request/reply larger That is certainly one way to go, if we want to 'harden' the existing mechanism. We probably ought to look at securing the entire system, though, to see if that's the direction we want to go, or if the overall security architecture is going to go in a different direction (e.g. security entries, not communication). Or maybe we do both - this is certainly an easy-enough change. > Require that the reply be sent from the map resolver to whom the > request was sent This has the downside that it probably introduces additional latency. Of course, if you already have a valid entry, and are merely trying to confirm that the entry is valid, that may not be a problem. > What happens if you get two different replies that both have the right > nonce? Will you accept the first and then accept the second, > overwriting the information received in the first? Or will you accept > the first .. and reject the second because it doesn't match any open > nonce? Either way, if an attacker can send a reply with a matching > nonce ... you will end-up using his mapping about 50% of the time I think there are two cases to consider here. The first is a DoS attack, but as I pointed out above, we should already have logging in place to detect those. Either one of these two events occurring could usefully be a _second_ message, which could indicate possible map cache corruption. There's also the possibility that for some reason, you could get this pattern (two different replies) for legitimate reasons. So what would the appropriate response be there? Noel From dino@cisco.com Tue Sep 8 08:12: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 43BF23A69B4 for ; Tue, 8 Sep 2009 08:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.042 X-Spam-Level: X-Spam-Status: No, score=-5.042 tagged_above=-999 required=5 tests=[AWL=-1.402, BAYES_00=-2.599, DC_IMAGE_SPAM_HTML=0.001, DC_PNG_UNO_LARGO=0.558, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=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 FyNEPu-Vt76Q for ; Tue, 8 Sep 2009 08:12:36 -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 0BACD28C105 for ; Tue, 8 Sep 2009 08:12:36 -0700 (PDT) X-Files: Picture 1.png : 117416 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKMRpkqrR7PD/2dsb2JhbADFJYhDAY9XBYQYgVk X-IronPort-AV: E=Sophos;i="4.44,352,1249257600"; d="png'150?scan'150,208,150";a="42482334" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 08 Sep 2009 15:13:06 +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 n88FD6q4015072; Tue, 8 Sep 2009 08:13:06 -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 n88FD6AC013567; Tue, 8 Sep 2009 15:13: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); Tue, 8 Sep 2009 08:13:06 -0700 Received: from [192.168.1.3] ([10.21.75.115]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 08:13:05 -0700 Message-Id: <14869896-3B75-4DDF-B075-FF507FCEEB5B@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AA66AC4.5010108@joelhalpern.com> Content-Type: multipart/mixed; boundary=Apple-Mail-7--762321555 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Sep 2009 08:13:05 -0700 References: <060.ea8474f8e9e720ff4a5501041a5c944c@tools.ietf.org> <4AA66AC4.5010108@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 15:13:05.0559 (UTC) FILETIME=[DDA9A270:01CA3096] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=165534; t=1252422786; x=1253286786; 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#22=3A=20An=20ETR=20MUST=20con sume=20UDP=20port=204342=20packets=20not=20addressed=20to=20 it |Sender:=20; bh=XWNydcjvn8Hcc442KGyPZJiSnYLNdnd4lht1K9ju0A0=; b=HkKaT9u9UZEqm/iDu5Zmt3zQJley7P3owYIQucrj/VeR2YpDtNuqwoghGs hkbiKdLzMLB3KzrwM0p3cd+1xvHXJp/kLcqh6KHmyYqiZQmjdnKlzy+WVlhg gqx4w8kfCD; 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] #22: An ETR MUST consume UDP port 4342 packets not addressed to it X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 15:12:37 -0000 --Apple-Mail-7--762321555 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Joel, see the enclosed slide. Follow the steps (1) through (5). That is what is implemented now and reflects what is in the current set of specs (-04 doesn't change this procedure). This should help clarify things. > In trying to understand this question, and its implications, I seem > to have totally confused myself. (Sorry Dino. I think you > explained this to me once before, and convinced me. But I can not > reconstruct it now.) > > The underlying goal is to get a LISP control message, in this case a > mapping request, from the source to the entity that can provide a > useful answer. Right. > The ITR wants to send the request to its Map Server. The ITR sends it to the mapping data system. The ITR is configured with the locator address of the Map-Resolver. Once the encapsulated Map-Request gets to the Map-Resolver, the mapping database system gets the Map-Request to the authoritative ETR. In ALT, that means the Map-Request gets to the Map-Server the ETR registered to. Then the Map-Server encapsulates the Map-Request to get it to the ETR. Remember, the fundamental premise of LISP is "outer headers have locators in them" and "inner headers have EIDs in them". This is true with control packets, but control packets can have either locators or EIDs in the inner header. > The Map Server send the request over the ALT to the relevant Map > Responder. > The Map Responder sends the request to a relevant ETR. No, the text above should clarify this. > The Control request is an IP packet, with a UDP header, addressed to > UDP port 4342. The body of the request includes the information as > to the EID whose mapping is being sought, and the RLOC of the ITR > who is making the request. Right. But that packet can't leave the ITR or else the destination address (the EID being sought) cannot be routed (assuming that EID- prefixes are not in the underlying routing). So the ITR must encapsulate the Map-Request so there can be locators in the other header. Also, if the Map-Request is an IPv6 Map-Request and you only have an IPv4 path to the mapping database system, then the inner header would have a source address of an IPv6 locator, a destination address of an IPv6 EID and the outer header would have source and destination IPv4 locators (see spec how Map-Reply gets returned in the mixed-AF case). > By assumption, that RLOC is usable by the end ETR to send the > response back to the ITR. Yes, the Map-Reply is sent directly from ETR to ETR with locators in the headers. There is no encapsulated Map-Reply. > So why do we need two UDP headers (and two IP headers.) Should be clear now? See slide? > The ITR can send the packet to the MS> So it should only need on IP > header, source=ITR RLoc, Dest=MS RLoc. And one UDP header (for > control message.) > > Similarly, the MR needs to send the message to the ETR. But the MR > know the ETR Rloc. So a single IP header, source=MS RLoc, dest=ETR > Rloc, and a single UDP header for the control message, would seem > sufficient. > > This would mean that nodes are only processing messages addressed to > themselves. This would also seem to be completely separate from the > question of what format messages are sent over the GRE tunnel inside > the ALT. There is one case where an ETR will process a control packet not addressed to it. We found this to be an issue 2 weeks ago while doing our implementation. We will document this on the mailing list once -04 gets out. It should address the concerns that was brought up in the tracker #22 item. Vince will send email once we get -04 out. > Assuming I am missing something basic, I suspect we need some more > text somewhere. I paged back and forth through the LISP spec, the > LISP-ALT spec, and the LISP-MS spec. Hmm. Maybe it's because you have the map-server and map-resolver functions not square? But we will try to clarify the spec. Dino --Apple-Mail-7--762321555 Content-Disposition: inline; filename="Picture 1.png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; x-mac-type=504E4766; name="Picture 1.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAoAAAAHFCAIAAADt0t82AAAABGdBTUEAANkDQtZPoQAADzdpQ0NQ Q29sb3IgTENEAAB4nJWXCThU3/vAz52VwVhCQhpCiAhZS/Zs2feKmBljN8YuIhFRhCxFopRKlpZv oULWJCVbSZG1SJIlY//fob7f3/P7Pb/n9/zP89y5n/ue97zve8975pz7AsAp6EKleiMAAD6+gTTL Q9oEewdHArYXMAMsfKGBkAsxgKplbm4C/mv71QMgxr1ThmGr33XJVKXBuPwXbmggUm3O/b+P22h4 GuwQAEgaZm7KJmsy2HWTrRkcEkgNhJlhi5vo7kKCOQJmaZq1pQ7Mtxh2KJtcwWDXTX7B4GAihTH2 PQAYLl+Shy8A2EmYNUjkACLczfBLIgUQfWC+AABCw8fHD7bP0Q7LJYhUGjyWgw6zKGNeNkMm+wOg thcA5sx/ZJ5wrGU0APgX/5HtYgGANwSA0n/Rm7XcmCuI902Am4L8hghi1QYA3b++PisOx5YGwGrq +vrytfX11esAID8CUOtNDKIF/54vCGoD4H89b77z74aEHTISLAxoYBKKQexDQshVtCjGE/ua2ZkF zdqDb+Co4/rIPbNVYRtJoGj7BGG3CE20SHxQkn23mswhWaW92xWwilNKHSr31c7td9AQPjimladj qbuqf8VA2fClsYNJl6mNWZ2FvOUlq2UbB9sqe7yDs2P5kbljik4055vH+105ifqkAPIVtzrKmAfO U9JL39vJJ9j3vF8+tcy/htYeMBj4MxiE4EOFwuTClU5sOzEVUReZedI/yiBaJHr11IeYJ6fzYqPj PM5YxR9MkD0rnMibxHYOfW79/GryWsp6KpSGTMdcxFxczhjKbMoqzk67FHLZNcciV+OKTJ7QVY58 VD69YPLa5+vdhc03qm6WF125df52xB3vYru7miUSpeyla+XgHvY+ywP8Q7a/WB+xPMY+Xq+Yqxyv 6n/S/vT5s/LqqzWJtSHP3eps6nUb9jWKNfE1s71AvKC3jL+sbU14ZdKGb3vz+sIbs3Z8e8vb2I6D HYudZV1u3du7O3uS3mm/o78v6XX9wPfhTd+Zjwc+zn0q7ycPsA5c+iz6uWRQdbBpyHpoeDhoBDuS PSo9WjtmNTb2Jewr69er4/LjDRNWE8PfAifRk+nfhb+XTalPNf6w/PF52nN69mf4DGLm3CzvbP6c xFzpvPz8X79kf11bYFtwW6ims9D16CfpFfSfi6TF/qWulci1pPV1xgoGERACuoDQRHIj19A7MUex lczquA7WJDyRw4hLjVub15Evkr9AsFloSlhop7EYaVes5MXdATKie17I+cvzK9Tt81DGq9xR01b/ cMBHY0UzQZtNJ0kPrR9x6IuhrdFfJtyHfU3rzXktPC3vWy3YHLANtiuzH3bcckT3qM+xHKd65zEX jKsoUYfkTA51S6bccH/q8cZz0GvWh8lXyE+eauR/lBYccCGwICghmByyP3Rr6HxYZ/i9E6kR1Ejb k2pRQtGo6MlTPTG1p4tjM+NizvjGOyYYnFVOFEviSlo/9+18d3JNyvUL8aneaZbpyhd3ZOAyZjP7 s15mP7pUeDk1JyrX+4pDnt5V+fwdBbiCOXg1tBU+vJFzM7bI/Zbjbbc7J4oT7l4uKSwtKXtW3njv 1f3XD94+7Pnr/aPex70VfZXvq3qf9D8dfDZW/aNm/jmoY6sXaJBqlG3a3rTY/OZFYUv4S4tWyVfg VU/b3den3zi2y75Fvn3XUdwZ1WXVLdY911Pz7vx7x17x3ukPFX0xHw0+YT896icNcA7UfvYb3DHY NhQ+LDn8buT06J7RnrHIL6JfWr76jnOOl09YTPz8ljwpNdn03eX78lTqD4kfddP205M/o2a4Zm7N asx2zLnO/Zw/9YvjV96C6EIunY+ev7h3sWspdZmyQlyNXctZJ6zbr6esN2/knwcYgUsQBPlD84hk 5H4UQPWhOzF9TIBZGhfC0swmhk9kX+L05xrlduBp3arCV8iPE6AIVgux7DAnZAsP7Nwl6il2W3xY QkDSTOrk7mLpDplfsrxy8nuN5W0VKIrUfSFKEcoRKuGqYWo0dff95AMkDbeDbprOWo7aljomulp6 CvrChzgMgMGUYa9RvXGpSfbhaFM3MzNzFQtRS7zlotWIdbtNtW2hXbi9kQOPw5DjvSPRR82OCR6b cKpyPnvc1kXMZc61jphKOk6WJi+6NVFS3Z09pD3onvVe571tfQR8un3P+Mn59VJj/MX922hBAfwB NYHkIOagsmCb4KWQglDD0JmwnHCD8PkT1yOsIjGRVSd9okSj+qIzTlnFsMe8Op0YqxsH4qrPnIhX jp9NKDvrkyiV+CWp8JzreaHzfck5KY4XBC70peakOaULp49cvJXhlamYhch6m331kt9lzZwtOaO5 j68k5bleVc3nzJ8oaLxWcD2mkHRD7+auIuai77c6b1fdKYBXWWCJU6lhmXL5znvs98H9mQfDD3v/ antU//hxxcPK4qobT/Kf5jzLrs6qSa89/zyxLr7+TEN0Y1hTUDP1hVuL28vw1vRXRW2PXle9ed7+ /G1tR0tnd9en7tl3/O+Nek9/ePFR4VPpgNEgemhsZOmL6wT7d9npL/NpyzcY+d88+xgNowRAhj4A tm8AsLwNQKopfNRxwAvkOADmbABYqwLERwmAuDUPoACFv88PPiAPDgM3cBJkglLQBD6BOYgVEoHU IHPIHYqCsqBSqAkagOgIDoQEQhtxFBGMuIAoRjQhhhDrSAGkCtIGGYhMRz5AdiJnUTwoZZQjKhJ1 HdWCmkELog+hA9BX0a/QixgJjB0mHlOBGccKYs2xZ7DPsHNM0kxuTNeY+pkFmY8w5zIP4HbiPHDl uEUWHZY0lkFWOdY41g9scmxn2UbwWvh8/Br7cfYmDhmOi5yAk8o5yGXN1bZFd0sN937uSh51nhre Q7wdW49t/cYXuY1z221+Hf5+gUhBYcHG7d5CXEJPd1AIPIRG4UARMZGhnU2i98UKxBN3hUlQJO2k dHfLSRNkWGR+7RmUfSn3YG+u/GkFH0WbfepKIso45TmVftVWtWr15v19B6YOQprbtCS1VXUO6zrr 0fTjDmUblBo2Gn0yXj68zXSfmZN5nEW55QdrThsD2zi7Bvsxh/UjhKNax9ydMpxrj0+7ihNJpELy KGW3e7BHoxevt59Pox8/NdC/NUA8MDroXYhc6Nmw4RO0yJ0nh6JvxPjGqp/hiZ8/253UdL4ipSz1 ZnpBRlFWyaV7ORVX6q/WFwwUphUducN3t7Ms+r7iw4HHl6qsn3HXDNQ9bbzw4mQr9fWJt0Fdqe+e fPjUjxw0HCn6euZ75nzQouLSu+XvK72rN9cKNvYPXrAXGG/kPwuUgxfgM6BDnJAkpAU5wHtKInQd egb1QNMIHEIUoYFwQATC2b+LaEGMIVFIEaQm0hkZhcxD1iKHUCjULpQRyg+ViapF/UDvQFugY9GP 0d8wBIwt5hymAbOCVcL6Y0uxk0xSTJ5MxUxTzHuZg5mf4dA4M1wO7iuLEksCSx/rHtYzrANsqmyZ bPN4G3wFOz/7KfZvHLYcdZyKnEVcglwZWzi2JHGzcifx4HkyeIV4i7eqbn3Bd4RvettZ/p381QJH BdYEC7brbR8XSt6hvKOfkCSsKDwgkrTTSfSgmIQ4XnxuV79Es+RDqdzdCdLBMsQ9FrKacrJ7ReS5 FZgVIcWFfT+UJpS/qoyrTqnN7Ucf4NPYfVBT017LS/uUzmXde3qv9EcNIMMdRgeNXUwSDt817TFH WShYHrfKsu6wZbE7bB/qEOuYfqT4aPWxj04rx3ld1FyPE5NJz8gTFEF3S49EzzpvyEfDN8TvAXWa JhFAgc/F3hCuUOOwuPCBCNfIhaiUU7tiamLt4xbjc86qJw6eS07en/I9NT/dLmNb5mh26eWTuTZ5 8vn4grVCiZvOt9LuNJZAZdr3Tj9ofyRbkfYE8SysFlt3sVGpuf9lWptzu1DHSvfY+4a+kv7KwaaR ga8p33qncqe/zHTNBczTFx5u5F8MmIFQkA+a4a9ILkgJOgpFQzegVugngg9xEEFBpCAqESNIDqQG 0ht5BfkahYD/4b6oW6hhtAiaiL6B/oqRwQRgnmDRWEtsAXaGSY8ph2mW+TBzMY4F54vrYtnPcpdV gDWFDcMWzbaGj2ZHsCdybOW4xinDWcl1iOvjFn9uFu4bPHo8X3lTt6pvHePL2mbMD/FXCQQLKgvS tz8RityhS2Ah9AhfFfHaaSp6QExRXGqXiMR2SUGp7buFpHfJ7NmjJmso57CXKp+gcFOxft+IMk5F UZWolqO+cMBD47MmSWtUh6YH6WcaSBs2GTubLJmmmEtYPLUytv5s62e35hB3hOtovpOKc6sL0XWd VOCmSRn2SPRS8B7yTaKq+o8GZAfpBc+H3go/FoGKLIwyip6KSYtVjPsYf/qsaGLTOa9ktpSSVIO0 wYsnM4WynlyyufwzNzlv99W6Apdry4UZN5WKOm5TitF3L5UqlLXe87hPf5jxSPpxQ+WxqrmnSdUS NS3PKfXYhsIms+bFlrxWkzbE6yvtAm/zOqW6anoo75l6K/u8PuH7Sz/bDU4O+4yMjFl9qRznnjD/ dnqy5HvT1NsfXdNNP/+auTDrPSc9920+75fBr5mFBLogvWxRdvHOkuhS3jJi2W355cqelfiVt6sC q+TVstWltcNrlevi62mM/G/WSxsNp+Pn7UcjmOjo/o/i7v/bfLyD/vjggi9WX1dTs9/8lRpobr2x CwGwFBBspQff4TML4nDz0Df8zQSSi64xzIIwy4W765gybMBs4kbTt9y0A9l7uhiZw4yH2ZPsa2P1 Wx5K9d6ocRmcSA3Uttw48QCUSw7Q+6PzMNzd2u732CZakKXNxlc1gLq8/Iwtf/uik8i6v2NDoHy9 TU02Y0ZwewQabtSyMEsBfeACV2MUQAYywAToAN3fvwRYToDJD+4lgwBYb2RD74+W7cazx7+NkoF3 ZYa94I0xXmAMZh9njxgabGtTowUQYZkL8P0jkSuWG5db+buf4dF7w+sfifF/SP5E+I+uByDB9z9y 4h85w7PPfbfgbL8wNVt3lDhKHrUPpY06gNJAqQICihfFD2RQiigVlBbqIEod7lN9Pfl48m8/m3Pj +vc7GsNWySBoY0Z8/2O+iP8SDdis3Te+ceD5z41lUH0GPfrf11kgOXSjPtbxo4bRPCjugQQtKtWb LE0w9CXukSbIy8mpgv8DQ6N5IR5ypDwAAAAJcEhZcwAACxMAAAsTAQCanBgAAAAkdEVYdFNvZnR3 YXJlAFF1aWNrVGltZSA3LjYuMiAoTWFjIE9TIFgpAGAyNT4AAAAHdElNRQfZCQgPDByCqfmnAAAg AElEQVR4nOydB3yTxRvH783eo0ma7j2gk1U2MkWWVBkCigqIA1EUFEVEQUFwggsVEP0jOEC27L33 hraUtrR0N02z9/xf8qZp0qaDMkrhvu0nnzf3vknuHXe/e+6eew6z2+0AgUAgEAjE/YXQ0hlAIBAI BOJRBAkwAoFAIBAtABJgBAKBQCBaACTACAQCgUC0AEiAEQgEAoFoAZAAIxAIBALRAiABRiAQCASi BUACjEAgEAhEC4AEGIFAIBCIFgAJMAKBQCAQLQASYAQCgUAgWgAkwAgEAoFAtABIgBEIBAKBaAGQ ACMQCAQC0QJgaDlCBAKBQLi1AIkChmG1Nu7VD6FrjUAgEI8sdic2D+zVtHTWWgBcceErwQOsmrv/ c4/mVUYgEIhHGVjz6/V6iURSWlp68eLFnJyc4uJiqVSq0+nMZnNL564FgPpKp9PZbHZwcHBYWFhq ampoaKhYLIYpJCdEIhHX47v5o0iAEQgE4tEB1vlQZQ8ePHj69GmTycRkMmNiYqKiogIDA/l8Po1G o1AoLZ3HFgBvkcArAxsiBQUFGRkZCoUCpiQnJz/22GMikYjiBCqx2ya+8x9FAoxAIBCPCjab7fDh w3PmzOnZs+fEiRODgoJYLNbdteoeGrRarVQq/eOPP3bt2jVlyhR4xRgMBrSSoQwTndy5BiMBRiAQ iIcfKL2FhYW//vqrRCKZNWsWNHl9HuYeEn6UR4Ld4JZufn7+3LlzuVzuqFGjYmJiYJOFRqNRqVRc g+9EhpEAIxAIxEMOrOeh4fvXX38NHz68b9++TCaz7gG47losFqvVanECN/DEFslzy4LLKoFAgCpL IpHg1di3b9/GjRuHDh3auXNnDocDryGUYXePdDN/BQkwAoFAPMTASr64uHjixImrVq0KDg72eQAu vSaTyWg06vV6g8EAt90a/KiZwrXUl0Kh4CZvZWXlwIEDZ82a1bNnT4FAwGaz6XQ6mUxutgaT7nbO EQgEAvGgAEV0y5YtP/3008KFC+tTX1x6oe5qtVq1E7gB35rNZrgL746+/zlvWfC+Zbf6QnuXxWJB xd26detHH30EGyi9e/fGWycMBqPZGowEGIFAIB5aLl26dOTIkTVr1gQGBtbdC/UDqghUX41Go1Kp 5HJ5VVWVQqGAGqzT6XAj+JEVYKipUIChuEKJherL4/H4TqZOnbps2TKxWOw+DG40T4ORACMQCMTD CVTQJUuWTJ8+vVH1lclkUqm0oqKisrISyjAUY7cF/Kj1P+PgFjCRSMQtYFyAhUIhvCyhoaHDhw// 8ssv586dix+Dy3AzHLKQACMQCMRDCBTXDz/8sFevXh07dvR5AJRVKLFarRYqLpTeMidQgJVKJUx0 jwGDRzI4pXsY2G0Ew0YJvCxGoxFeFnhJ+/Xrt3nz5jFjxkCFbnbALCTACAQC8RBy8uRJqKYLFiyo TxKguEI5UavVVVVV5eXlpaWlUIChKQwNYpgOtfmRdYF2g5u20MbV6XTQ9sXVF14WmD5hwgRoAWdl ZeFjwO4YHfDgpn8/EmAEAoF42IDyuWPHjpkzZ1KpVJ8HQGWFx0BRkUqlubm5eXl5UIChEuPq+8gO /eLxJnHnZzwFN2ot1cDLgu+l0Wg9evS4fPlycHAw3MbdofGPN90IRgKMQCAQDxsSiQSqRURERH0H QCGBWnvgwIFDhw5BOeFyuVBIQkND72MeHzjgNTEYDGVlZRkZGSaTicPhwOYLbu/CxgreGQD1FSZC xYV7ExIStm/fXlFRwXECTWF3kKwm/iISYAQCgXjYOH78eExMTN2AGzhQVJRKJbSP2Wz2u+++KxaL 8X7Ue7363gMOPiPLaDSqVKrdu3d/9tlnXCfumdBQnuElwmclyeVy2L6Blw4awX5+fnw+H15MuOu2 3KFRCFAEAoF4qIBSsW7dup49e9a3F2rGyJEjhwwZ8t1338XHx/N4PGi6PeLqC5y9zVA+WSxWUFDQ xIkToQaHhISUl5fjXfFup3GdTqdWq2ELRqPRDBs27NKlSzKZDPdcg+INj2n6wDkSYAQCgXioqKio KC4ujo2N9bn37Nmz33///RtvvPHMM8/clsfQo0Z0dPTPP/8cExMjkUhwTcXjheHBwnC3rDZt2igU CniAW4Bx57UmDp8jAUYgEIiHioMHD/br1w8ac3V3GQyG3377bfbs2aNGjUImb6NAU3j16tVJSUlQ WfEUd8xOeCXxxLS0tKKiIjx8GEzEHbWa+P1IgBEIBOKhIisrKyUlxeeu7du3R0REREZG3ucstV64 XO748eOhuHp2RFs8aNu2LTR/dU5u14G8FThhWTXyD/feMgCvxpqKzPhyUKywVvbtht83Z132blUw KdRxXaOTBD4agy2CVat4Z0c+IDXU9GETiaE8ekoIv20wj0tFjaSGgE+7FQBqg9cTx2bS/Xgk/6ba 0sRvNgGsR2LYuDjeI3UDzPKymfvLARGetB1QaNMei45iPyhlB9EUYNV//fr1sWPH1t2l1+sXLly4 ZcsW1PN8W/Tr14/D4UCrF3eKxqdHW53A7djY2CNHjuid4GPAeHpTvrkVCLDFqFuWI1GavIx6LoP6 XKew/gFeU9yMMulLGRW1Pi5gsbsmhD04AmwxaL/Prp3J+qASie/2SJjVI4hJRJ1FtYFlQK2Qzdxw Oa5ryrvJosaPN5k25EuOVhib/AsEur/f2FgeeJSuvVFV9f316ueTzBrZOQIJcKtDKpX6+/vXTT94 8GD37t1DQkLuf5ZaNUwmc8SIEcuXLw8MDMQwzG0K40rM5/Nx6cUHgG8reGdrbdxrjNYzxWrvjnZ7 bo68hbJzr4Ctqc+OZL15sLjpovFoYC8qlSzZeSngl/O/VthI90whkZnQClroCG9g1a9Wq6HFVnfX yZMnoZD4+owRHP4PZFXWTq8qBluPA2vto0HRdXAs28f3ZF8GmYXNynU1Gjk4ega4a/bCTHD+Irh4 Dpw7B44fB+Xq2sdnnALX6vyi3eA4nZyq2ukGOVi7GTS5D8yTvn37GgyGml/w0FcGg4FLLzSR4esj 4QUNTzKrSmX0PE2b5WixrsUydA+x/O9M9poCfUtn40HCpJiy7uqHFyVG2z2N1GO3gUcuEhDiIQDK AIVCqZt+69at1NTUOkdrweIZYPTz4I8LXumSLPDWRPD897UFuPAseGYQmP5n7e+5+C94YhjYd/KO sr7kHTDqmxoB/mceGP4keDIdpA8HI0aCPXk1R9pNYMu3YPCzYNMFr2JqUoPPpjhOZ90Vr2/WycEH b4KXXgBVzTFnYmJiNBqNz13wUuOjwnjnMz4A3EQjuPU2cO3XKrRak41Oc7UhzHr9Nk3rU6k0Mffl WIF7nNdismhM5itFig1yg8JSff9slu+OFj0bEUdvqVw+cNiMGrOp+k3zRFLMoM5pF8wl1ftxmN42 gk94lPqfEQ830DL28/OrnXrmAFj0F6hSApLZK/2Pj8GOM0DTxVuAFaDDIKA3gASD18EVJ8Dw6UAp g5VVI5kwG4CRAFh12gd2C1j1Flh0HKxcU6NLbBoYMAp88aHDVCRSgJ+HWV9wFixaBpQKYPDOyb7/ wLebfZzOoeVg1Xag0zSvvmCz2W5H6Lrgnln40O9tLR7VygRYBEClw3XeDv8uVShvGS1CmutGVsl1 VXJHncwgAKhcJjvWYM1s1xnMWqPF2aEPqBQSm05uek1rNJq0RnixMRaTQm+C+0/9YHGh/s/1jqbX /m3bsMMZr54okVQ/+gatospoD6H6yKNOb9SarAQMo1DILBqp0bMwGkxqkxUeRqdR6JR7O7Zst9s0 OpPeYiMRCBQqmUVprE/XDu+LSW2wYjBfzvvCopF9ZNF7+oS9WefAY3HG9I4T3pdeZsdwtc5ktNoI AAMEjEkj08lN+mHHB+FjagcEEolNI3s9a85rpTfbMAKBRac08U7aLBaV3my2ATKVxKXdxjNfC1jX qJwZIxGINDr5zkoBokVJ6QF2rAZdngQshlf6qNmAGw3evex9NBvs3Az+/g1cYXkl+yWB1RvBge9B o1ObLvwLFp8FX80HYVyPVFihrwVTfwXvrwF9oxwWMP5AyatAxg3w4UygNYG43mDWS4BRrVniNuDn v8B3dXzNuj0OdqwCXdIB0/t0Oj8H/g4CI19pPIcNUp+4uoeEbyuAdisTYAVwnKjrjVF7VGLqyHUJ cJFCVaxz9FwYMGD3PMwbeHVy84oXHb61X2PG+y/hC1QvEpUyq3342HaBHA+vY3Vl5fu7883ODn2t mfDeqE7RNuXKvVnflpusNscPEAmkKR1jZ/QI8NHd0zTsNkdjos4gJuGJ1OCYrEqJ1GXm6awmid4W QvWqtRVS6fe7s1ZKLVa74wswAkai0OZ3j3k6UcjwVb0bNKo1e64vKNZanT08BAJxSEzwF0OiCrJv /Xq63Nl7YKf7BX0zLBz3ujlyPnP1VSW8OsBmF0dELugT4JnxU3vOLy230JxXOjTUf3qvSI53fS4p Kfl4b95OpRXPHoGA8Vmsr/rG9Yvg+BILW1FB6VeH8rcoLY7sOQ+A9yWYSX27a/SoJH/8hCwm0x/7 rp0oUx2v+aD1f4ezbl0g60i0Nwa2SRXSGrniHqfQxJKyaf+FDUUmevVzQeEKv0yPcYf405Xlv7Wz orok2fVEzo/PJfKq95r0uj0ncr7MlBfYHLcaP28CkZAk5MzqHtMrnO3OTN61m3MuVOK1mpXOWzIq XnHz1vt7Ck4YndnEsDgO67OhyV39HY6HZpXsve3ZGyUG/BkmEkkfdI4e3zGIWV2gbVbrukNX9hYb 4d2Dza30fslPBpJ2nbw+7bIMPro257XtEiz+fkhsIOO2K4Fzl2/MPFmWa3B1FMLT6R4i+rR/fCwH DZq3Qth+oL1zzlJChFd6RCpgrwcWsrcrBBGk9QCHtwFinNfBZA7o0xlslwNzY4UqviP4dwJQK8Dy JSBE4Eq06cFfe4DeBH5+G6zAAG8g2LcUBJBA9iFwXgcGPwcSKGDRF8C/PXijs+sjDAFozwRlJSDE 20mQLwLtkx0bcd5xrYUhwJ/hqO8td399J0+3rIdZgO0EbAiXdlyhVzrPd/2VqmmxLLxivFYsLXGe uM2KBVAJ5cbangMQrVI+d/3FxWWmuruA2vDa3qu/Zkr/GZUYxXZdFp1Cu7VUXmpyXdD4i7mbL926 rPH8ZuPsg5d+yRBvGJHQQejLPm0uRoPVYq55UKgEEt9zPpLNvPts7qtHCguNtW624fmt5x/PDl46 sE0M1/Pm2q7nlb628/oRhVcH0bILOauzJG/FUP4oVKjwJCltIXAJcJZSs7JYiSf3ZtbqfrFeypT+ WT0m8hiD9brHU23Q6/45nDnpnLTWSRWpDE/8WTWxc+ynPcKDmTXF2mTQfrH96rdZirpOdMVqw7jN F17a77f/2dQ0EdVutZ2vkP1W5nUW1+Taa/CTJOZTBmudAa4GwJrovBURyDl5/mZ+tR8+jaxNjhFO TuCRMKBTyV5dnfunqfqRIBBf6RHuVt8buQXPb8s5q/HxKBYp9TvzKl5JS/i8bwiP4rizhaWatYUK fC+DbIrfY1h8obzS46MlakP35QcXD2mfYKsatKuW44lxyt6rhyp1/xsWg08MgGp/oUj2e7GrF45e UHH8cP6SQq8nv/j6rQ35sg2jUoeEs5o02c1ur5TJf95xed6t2n1xa5WFazOKvxzS7hXYsqAga7i1 Icl3vFJqT+sE0PbokgZqmRdWK5AWAmoXH9+jsoCkoNqJRik4ec21ndgViBKA/Cp4oj0IVQDDVoA/ r2Y9kCtBUmcw/V1gyQELloCZ7cGqVwA1FXz5Ipj+MiBZQMZ5sPFQjQA7swKINBAbVrsgl+U6Xsl1 1E0rB7Z2QMSonX6XaMbiUa1MgAkYoX0IL0NrUDpF8URuWbklPMhxEqZLN6rVgEKbFElZeF1Z67M2 s+HrA9d9q28150rKxm2h7nuuDdt5RzECwfPWfnLsps9PFUokL2zCdk1ICSXfdtUDzVZfMmDfmVmS 41FxU4k0Xo2+W7ZvvzzlirS4HiN/b3ZxutLw1+h2qdUaXJ6d/9y23It6Hx/Q6ZWLrnomEJpoxdR9 vKsxr9hyeV5e7evvzt7vZ25ItKafB8WFuIxKy387L83NquPf6JlJteytPbl/D48PcfxoPRcZA7fV n643mTILqxxd0PWUGgaLGSGgwa9MiQl7r03VlCuu5oHBbP7qxM2eIckJTPtvx/PWmmtuU/tQ8ftp rukfFnXlpP+yz2obKpN/XMpJDWa+liTAHFZsTbrOrPvgrG+Pwvn7rph8u57Z114q6BkfNDXWWb9g ji4H977lR335rEKM6okbLn49JHlSQuPTnatk8vfWXV5Trw+Lbd6+q1pb0uyO4uZ3bSNaBuczHM73 SrNbQJEWEOrKld1xfKzQ1/fQALXO8Yoc8MPPgEEBGBm8nQgYSrDoE6CJAXPG1+iP2QgMKvDBr2Cc 03i9/j3IPQ30r4Mf9gECzRk1gQBEJEDyNnZNcpDhU8ScDfRQbt0dAIjBgxRZoZUJsB0DogAuq6gS mJyX2Kw8XWl6OpAC1NLDKpeBEuvH6iLwUQFIKlS7C2pqeTKBMDpa1FdAPnBD8resRpUzS0uyVXGd uA3dpAnhPEmFZofBbYfZsyoqFpxWLOtZx8GhsRO6WS7bfpbg7t7Uaoy35JqLhYrNWqvBo54dmhru riCleUWjL0s9HQ8GhAmGCcn/y5Zc0rouQla59KvjxSuHRDjalybNgiPFtdR3UAA/gWL+t0RTZAUw 07Cy9/ZkaD7FF7Nm5io9mzlj4wNSiKYlOfLK6u4p2LzYGCt6I0kAz8ksLXs+s+a+pAq4H3QNjxNQ C/PLnj1RorO6PnKuoHx/ecgLIVSb1YdB6cBqs9yOU3SxUjV03YUGbnNCcMTh8bFUh/MHZfKgNhev nFxevSu/ovKbM1WfplqXXZRZPH5zwYD4CFePrv3k8ZsnPNQ3iEWf3lZE0uuW3JAVVhvTUMvPlqsm JwrqU6wXo8ThBP23N1XVTzeQV1vbbXnMybHsnWfL99UcbnlnX+Hk2Da+F4B1MjKUzzcZN1boZNUp KoP210slI6I5fo1VTAfOXIfq6776ZAL2RlIAWaH8stDVVtCZzAv35o5OFiZQUV90q4LgfGhL1aAN uyYR6mUI20fzFMMcxxf6amGTaT6m7vl3Bn/+4TQzYBvZAMY/C/47CFYfAMPTag4mkhyfvVYEgFOA ybGAkQAoRLB3I0gYAiL8gLQYHLgAAjp5/5wQJLjU1guiU6fLtSDGe6CaRHVmvt7LcBd5eAJxeGEH DCazF5Wc4brq9i1Z8vRAcWFmidvlPEbECKH7MHNzNCorlRppNZYbbHoKffNzXQYHO8YLJ/Uxpx/K ePF0Od6bawN2maOS8XWXCMSOscHb0hPEFIdBvetI5mtnygtdHdT2FYeuv9OpWxzt9hr/J4ur4H+D hxDaBQfOSuPj32u3mv66XOkWSxKBOKdv8vtdxFQCNrmHYvamS98Xu3aeLpXeVAa35ZJz8ip3yGvk lUdnLh6cOCHB0VaYUyl5ZkvGvvK7Ns3YatYsOCp1X30/BuOnJ1OfiXU0RV+vrJiy8drflY5OUZvd vC5b+lIbPyYJ02hMhupnlUGlzhiYMiqKCY23dmECZcfA0SsvXgUkMZvGoZMxK6DQqN+M7/O5RjLw l6tnq6/P3CeS30n0s9gAi34bY/E2u11nrkfLneiJmPshIFK4376aeGR11nUdroT2Vacv7TkHytwd 7xjpnQGdBge6tM9u0q3SElI4lAqdWWKxJ4QGbBuZFM5yFLepWsVLK86s1rg+qXC4E9R1AgBiLuev UR36Bjoe0efPX+m0s9SjwsMGpsSvHRrBJYKJadLn/ry4U+k6EVOVTGYFgb7kT+DHXzYscUQYC9ht 72YXTth141R1Hs7clByRRT0V2JCXvVlX+eN5lft6tRH7bxuXGsVy/NIreTfH/Jd33tlhY7aqPz1V 9Xdvf2QDtxpyT4Dpbzk2ZjwPli8HoltgUzF4ZRzY9An4aBW4BcA4DVg+H2z7ElRFg5eHgpljwZZT wHwYlFWBH58BXy8CgQPBUBGY9DbYsgf8dwoQDoCR0TXfjxEBrUZpwQdzwMI1IIrnlQe6HxjUG7ww HFC/A9Yr4NsKsGowIJvAxm/BnJ/Bs8PB3n/BTTvYNwoYqsDPy0HnSSCyEsyaBXYpwYWpIH49iCeB n38F46cD5Wnw3gzHd749CfxvGQjQgR/+A29NATe2gDEfAF0JGPcS+O47EOKtzS1EaxNgCEYb4U/5 pcI14yizVKKw8necV7l3h7DZTKKs7ue6RIVtEvhX6kwlWrOGyhgUXO2tQyAm8B3ew7WHU+sQI+L+ OjBWjFfyBPLAngnTVYZZV+TV8qXak6+Na3s37yuZSByTFDG3T6SgWgr0av3hqhp7MT40dEbnANx0 YXB5X4yIv7r08kFnNZlXqb4mN7TlELOrNHJTzblN6Bz/XFuXpc4T+a972jZ0xaWTzZmb7gNFiXy7 qea7hiZFpke7OoI4IvEXQ/VX/rie4az2T+RW3jLGJJC8tMJgMn154MrJLO64toHtQjhsluC7Zzoo HQJM5dDIFKerLYNGBkSax3QEjEsnsxgNWH13B5oo9PuuqhcOFZVXi25ZjXxj6Snh87t41Clk+uIn kqRqY4XOVKS1+Iv9cPWFECiM3v6k1ZqGhkJgO31wQmj3ANcjGp0cFL+z9Ez1TrHA/88hDvWFcDmc fmGcA1fdD6HJYSH7EuBPH096KszpOoYR4tpE/E0w9l6XXz2SbPw7Q9mwABddLTxavU2n0T/pF4ur LyQyMvydJOXLpytwg3/d2VtLe/oLkA3cWhCGgylzwUuOwGcg0h8osoFSDtunoPNw8K3T4uSHARoB 6KSgig/sFJD+Cuj3iiPdP9FhEilkgGEAdDF4+Q0wYYojvb2PIFzVEEFqV1/pJPD0FPCXGJzKAMwI sG4dGJzqaJZ+vgGs3wzkajBkCujzOAjjAEMlUFY53LW4QeDFN8CIyQBQQZQA2KtAVYXDwSogFrzx KXgVAAoHBPOBWemYkmSzgfAO4LsfHT/FFQG/prtq3ltaoQADrH0Sn3BViVeDlRptfrnsD62rLiQT CV0DeWSNDwGmUChBIkoQAMk2m9lqU+mNZZWq89dLVmdI9mib5BcXLxJBg9L9lkAiPxkt+jxLUVHd s6o0wGxYVv6472WFj48Pat9+x1BxrURo6pGdsc3M9lqdPcTnY/zf698mUeQlLUqtsUJeM7+tjR/H ZDJLXV2vGInCjiYDXIChNVqkdSyMlanSehhPlAlp/p4dnlyeaFA882SGtilXoDHshRKdwSNoaDib rjWY1K4Tw+xUdgAR4AIMzIYcjTWBSWSxqPAMcf2AVmlGhRL+/3LJIQ1dOIzRySFPtQ/iNjzNplkT +wgYxqIQG5jmyybW7gUZkBb5Qp78y1u15+PHi/3mdAv3LNMYRuCw6PA/CoDOVqvRYpMotYWlsn1X ir/LV1VYGskxmUDoEcivGfSnsNNo4Ex1L0avSIGguuBiRII/1TEc7+7E8HlCBKro2Vim5/kER0YO FRX9XOlqLVXpzL4+58Z6Nrum2cehkPlkTKo1VZ8sJqRSYbvU9QwZVCUGm4D5AI20IRqCFwyGBNe8 FQ0Bnzg3OJ1BvMdhL33r2uj/lNfHF/7k2hj65B1lA+rlyAlgpHcibBy89pZXCl0E5n1dnZNBHjuY 4Julzg0uGBrukZ4IfvzUuREPnvI8nweC1ijAQBDiP4BQsMdZj0vUhq3nSzKqazQKkdwhhA6u+/6g 3Ww8nV2xp1R5Pr/qdKVBcpu/GyVg1YqKy6KRPGvpG3KdFTBBffhyf+8WKnyrrUhvNF2pUm3IkBa4 RzExYGLRGYxGwvBuuHhlw8X6dtryFc4q0rMmpHNDazX+MEBpwohdsd5ouf3HZcH+cwv217fTklll ShdTyELxmtSSly/L6zZaTqt0p4/fePfkzTEJQeNSggaGc2l3b95ytFBweGJH/wZOCcNqawiZ8eGg mFO/Xzribb6+0T2+vdBH77dWpfovu/L0rarTRcrLWmvTw8TAdkEAx/PWE+ge+Qzk3ba5HxvAZXun wJNj02vO75pEYwSgid9boVIN/ONY/fvNt1TWFCTACERjtEoBBlTeCDFpj3Muit5k/jmryt9qd/rR AxLbL5pFrBPS1IHNbPhhf9a3VyS3TM2ymADwozbi3VmlMd7mFDMsTMQb0imcgQGL2fRcdO7gzYWu QPh269pL+WVq4+qnk0I9xpUJBKypbsrA10A2meSj86UJ/gJ5Uq3eMQm/sR8k3c4ao64jyekDk+Xk rI8vSct9moY2y9prhfsLqpamtxsd2WgWmgq0faHOEW5TJtg8ZrwNHPFOVJgtdU/arK6cuDZrr1Sv tN728wavIZte72223f5sBxG9EQ8riUpvakiAMfJtTXVHI8AIRBNonQIMCF1S+cQy5yRJu1VqBu4J p08nBrMw4FOAL1wvWnKuwj19kk0lx7Dow8P9Hk8UC5SVnbfnqxurKM9VqiyA53nJHK5uHh/qIHIs HFNf9egzGbM7/mGFRSJT2iUlfC/VTTgh1btk3H4kr+z9A6xfB0UwqrtKrTa7xcNziM+kcakYqEf2 /al17q/JbLSDWoG36lp6PnPfFN03Wby8/0RsGpOE1ddFLKwOjEWiMiYP6ji+p/rfwze+zVMVGy1q k9Xg/SmpRjtmR3761JRmxzy5c+xWy+ad11bUGS///UxOn6B2Pfxr9Mtu0S/4O2u9xOUeTMQwPwal PYc1so2of6I44+Cp9IxGHN9uX2Qb4liJTAdCvSaI2L1+olsQr8GmjV3rYfSTiQR/DpVcfw7ZaPEu BKIJtFIBBkFhAW0IlRm1hYf0TFuez+NhDXI4o9itvgFc3q+D2/SL4OKhG0uzfHiM+5cAACAASURB VIwZ10WhVivMdmGNGWwvUhg9A37QaPB6EhLbRbzvq3YND2zcP2tox/i3igyf14wy2rZmFf7XRjgm ylU9QqONRKyJspneMfm3xwQeX2DX6kxkCoXiDklptwmpZPcgKzAoLsqtff1qxNRsMVzL8x1k3Ita Gm2z5PuYt4RRSQRPC3hm3w7vptT4S9ntNp3BQqNS6oyuApPJrLUSunVsM7I/qaBEfq5ck6kxSCSK Hbc0NSMFckWhBcS03DN7Pa/o/Rwf85VvShSzjxTsHhXv7l2QlMjWamouUJ/o0O8GRCVUR+m6cWfB 8JqDTpGtsbVn1Vx3q1VfIK9pSjAYDTdsMJZHeA1/Lmfj6A5popqPmM0WWBCYVNL9PzMEovXSWgWY xeS34xEzZN7TSBicbvXG9rXkeUy2GZoaPiTGLdXWi2Vas4f5W59nztli6YFSzTPV4QMtRvP63HK5 xwfjHaHOCF17xvsKEgOa0jHHYLNm9gv//PcMd4pOr39t0/V+76ThC95yGBR/LgnoXS4zW8/nFHUV hFbXhLqyvIR1RRiB0I3L6BnCH9QxLJpLTmCx+VhluSublq+OFfUYHuGuO6+eubZe2dBsHBd6jcQC IqqfF0VRxXe+Jg6HCGlUMgFYXS2j3dklkxM5vOp7kptzfcBOCYGADRCyuoYKhnUOExMt/x3J/iNb cdbkWEaEQ6dteqFbQnRAQrQjDLLJZNl27tqkQ5LqBoJF53MgunkLJsDLdHv9z/olu3Nv6n32NtiP Zt+ae0r8RVf8obJLlEadx3DEhG7RCUK3fazbll3zKDbkBnYXsernHCnaOCTcnYmci9e3ampy2KGR WRmE9tEskOsy6MvkmmPl6jSRq+Vnt5qXHLq8NEvDIxMHBXDaBYuGdQpioyFgBKIxWqsAUymkqEAG JlN7doP1jRRy663NMGfkedfhKy8UTW3LS/Cj2S2ma7nl31yrcKuJ1WbPlxiA0Ed9ZDLox268Yh2e 0J1PsZnMm09nfplbE65IzAkcEOxwnMFuZxi0bj75waFXepf3OVzltsqV+qoZe4uX93dEjqKzmelB vI3lrl52mU756s4bS3qGhrJIcqVy8b/5RWqHmhYq9VvLdSGxAdFcSkIYN4xFKq9eBfNQ1s15fsRX 2gqINsv5zPwRR+tdRJlOIkKddnU92rTv78r/rHuAPw0rrlTM31/g023aL1g4kUteYHAJzP680vmn 2DOSRTwKqJDJF2wpLHLuWanUbyg1desYKiaCPJl2g9T1ZSU66yfHbi3qEhjIJEMFVumMV2X6GvOc ygrBbUi7Z6e79UCetA+PKNcZwgP8othN7aKuVMo/33alIVchO/AT+L3WJZhCxOxm46otp3+taalg jyfHz4vRp/93S+qakW77at+ZzkE9nw5jEJxBKhzqXn34klMFfYVRAQySUqXddSzzJ494uYVSo2Mi 8L2Xq51Xct9mgncShXTMdun6rScP1sw+Z9M442Iaic8XkRqVfqhyi3Ouns1ueWd3Vggzqa+YQcOs 1wvLN5yXFllAEWzPVWnFRdbHoQDf27NBIB4GWqsAE0ikVD6bAdQeMkDoEd5AK54UG0QD8mpHVI3s mX8v9Y3g2Az6EznSLI8pGLAyVPiKI+1Cq37u7zNd/ZlWneGsxnMwkLxwSIzP0GfNIKlnysuFZ77I rzm5/67e3BHHHxHOxAikYSkBiRcqXTay3b7rar5EIksUUIvK5EdrIiWALmH+3R0WOeCI/N4IZ75w zTUXyWA2fX4o62AGk2I1X1Y0FP8qkccNJ1bmVH/lpis5OWXlcWxCZqnymq6eYWci/fVewWvW3yzA 31rMSw5mXszlhzCw64Xycx6G37MdQ2OpREAgjm0n/iFLgfvQAZv17zM5JeXSNnwasFmKyhU7JTU5 HJzo77rCRKoQNnWq79q2K/kXswuVRvDN2LSmC7DMYP7mSmnDx0QHESalBVMI1jPnciddr8lJtL/f wl5ByQzbtAjZp7nuBb5tiw7npY1oG8YkiflUJjy76kAfGTcLJ27VxfMppeXyfaVeHf4q17oe994O tpiXHb1+OpPJw6wXZZ4e2YQn4sWxjfnbAwrv5U7Cw8crXc7qBs1z/5wbFMnnYuazNxU3ah4HyufD 2giR+YtANIFWW1AwQjsRi+XplUymtuU1FEmgX2JEgkf/dK5MueJC0cpML/WFWKy2iyWKBqMk2E9J NN7qi43vFDUuqv4JSLcLRp3WIzqVUXN3VDrdr+dKjM7ubn5I0P4xYZ75uVChWJ1ZccgdpdDJR/2j RbjrK4E8bljyG17ez7bTleqjMoOqQaftpEhBrEdwBovNdqlCuS5XXq/6OgmIj13c13O6s+1QUdWa bOk5fU3u4sTsNzsG4pGzA6IiNg3zmLlvtx65JV1+qXj5lXJP9W0b6P9F12DXDSSyeod6CS28NBpg vSlv8L7dPjRnoO6qcvmHZz2kmkga1TGyHZ9CodGmPRbG8HgILxaWfnfNYVnygoQzBDVX3Gi17s2r +PFc0cZiTa1rnlOuKr19N+nmYr9UpTkk1Ss98hDO587pFc5sfB1LMKBL/BORNQ+5xWbZllf5Z66n +oIXu0aOiUDrViPuA1aNxne89FZE6xNgt39lcCArwGN92SguPZHnqvIwrKZGc8w2cXYJx0cHfdUj vCOnttEfx2fP7xe/PMRdodtz5PIKXxozp0fbGQm8EO9rFsxivNQpbkn/CFqzriXuBF2XwAj/RUki z5TdWYV/FeCChPnHJpwaHjNUzBDX+VEGhfxYuPjg5L59PXxkiCTWgpe7vhPNEXq7pwYyGSPax8xM 8W26U9n8lX2iBwTS/bx/JZDFmNY1oWpCzWx3DHiYcBg2vHPi2sdCe/hR+XVqdRGDNjA6aO3IjvFs ovv45JR2hwdHPx3MCva19m8gkz68TfDfTyYm+dVYaf27Rffh1lp2B6tnlQLPXN4ezkFi6/9OXD/g 0bXwWGTQzHauC8kJCtnXVei+T3a7fcnezF3lZgyjvDS63fwofoD39B8GidQtRLh1RPIzHFe6zaZe l+2sR7wHLmoNY1g93ta6SN7dNQSfqyMPTW6zqXdgEtPr4edQyH0jQ/ZOTEvxcO33Gj/BMM8vpzBY fwxP/rStsB2bXDviKobF8tmvpsUu6hFGuz+j2oj7j92w5es5C3YX1CSY5X/9tmKJg++WLl32x5/r Mgtwp0m7RnLr8Kb1f/755/pNm3LLVMAm+3ps35iYhJjktNfmLr1UpvQsq+f/+7ZbSkpKZGT6i28f uJzXlLxYlXlD+rf/K6cRB1Kb1VJaWma23ub80PtFK+iCJnMEa55uhwexgLVD+yCXylJ5fivSU0uq h9M4dIp7AT5xbOQmdqDrMDKpo9jpekIkD+4Vnxzrf7RMlV+u0RIIbBo1SMDqJObEChmGWK5I5jJq GRQKz9eFobF5c7r5j01WnpOoKtUmgwULErHTQvjtg9hNX/4Fns6m0R3cb0N4zHpWMSQN7N1mU3iw Z5KnZ0vn5Og1YQGZEu11uaZcYTA6xhFJAQJmpIDVOZDDp9V2RuNwefOHt3+qRHGhWF5hsJJJ5AA/ VkoAt2MQ4/u9tdcNdCOOCNn4DPd0kSpLoqoyWElEUoCQneTPSRWzKGbNptEuNxwhm871MKEIZMro Xm37tg25KtXekGkr1UZom5Mp5EAhq42I3TGQTffWEIxA6NUxpkOb4MxSdYZMU6bQas0EaAqTqZRg EQf+XPtAdq15rHHhoX88wzlWorhVpTNY7TQaNcCP2TnMezkXb4g05mcDk6sMt1EUuQw6jYT1SYnb lFSTmBQs8PAixzr1TN4UoPCc+RaMt3xo7PdGt+9fKLtYoihXmexkkh+bESNidw7mCqmEKDZlnM71 6Abx4Aew5NSITcGuFZeJBCzRa21d4qQnOzxW3VUTI/ZoMGHEx9tH/xMZUt0hQ/IZWgTeuie7JyVG yU+UKotlep0ZcFj0pBB+z3Aex3sJL7oobNPo6hYFkZTA9eppIMMi8HS758tVl6u0BTKdUm82WACL SQsVsdr7c+JFjCYY0ohWi92YceTEFeYzNSlWQ8GNzJzign07joZ17kzRmPTsqIQIUfGVDTPfW3j0 mK7bsOSyG9uDnt3+17ToC7vO93pn6YgE68afP/lIp/t9/jvCaqtFUimJ6P70S4M7nDz0z4yX5m47 uSaksSERq8Vst1oNDYZzhxiUhYvemDPx+587hNytEcK7SSsQYAKZNjTWV+hOAqlTlKiTjx2AzuWk czk+dmCEkEDBuEBB3T1kkV+6qG5ybSg0eqdY+B/Q+KH1AE8nPb5JkUgJVHp6fP29eRjG5bG6wX9Q O7xlfdCY9B5x8D/QM9FuszZsN7LY7P4J8D+49g4SOz2+flcbjCAUcfvC/yZmDmBMJiMtlpHWtNOB mh0i5o8VN6S4tT9CJPcM97mGWiN0jPXv2MBuIqV7vO/gt2QypWt0APyvuyshVJTgncIXcNIFvh5a B4TEKEfgXV9gwWJucBOuGYFIjAkWwv9GDqM3eFsdR5DCg/zgf+M/iXgY0Xt0JWG0wNmfL5HmHHrm wq0Fa/7tLnSMUNgthj9W/L6O9JRU+THf3Yw0F8JqJqxD9yeHRveMs6VNO1BRpRMGu7x2yq/nhUSN 7zv8yXZRYM9/C+UmEEK2m40Grd6IEUkMBoNMhC1ym04llcr1LD8hj8OEz7MrjI7dJr9x6ngJ54l+ SSSrSaPWWR0DkgwGjWyQyyvKC66e33cuMy+UHM7zr3fZsZai9XVBIxAIBOLBwWTUGzTw1fXWbrcb NGqBOuevtX/v2nPgys1yqIhWrSLbbksM5ygluX8s2xwRHMjnetghZh20aC161dkLmSVkMYNkKzp/ cPrYwQGdenbp3uvlZUetwJKz55+BAWHDRz2d9tjgfaWuHyMQsIy9/zzRddBPf+9WK0u/+uiVHlHt +vZq13XQi4fzKv+bM63f4IlnCys/mzL6qTETc++2j8id0wosYAQCgUA8sGAOS85oro4jSyBRx7/5 kXLx0l+++05SWMQVBgx8b+nn/XQ37bZPJ6UvtqluZBZ8u22RP8NTfYzrVnx0bvtXBXnyoW8uDrYr vvx80nnSyH0bX1j/7QfH8qpMVUW//Pwd5/Xvfn+9f2HmNf/qIbazG5ev+uVr2vB3v//slaJd33z6 TdFvezbQs/4cPmXJxZufT/x4Yczz+Qvf/nDwp4t6hgeHcxvr177vIAFGIBAIRBOw2Y31hEi1AyrN Pf6PEeI6PP7dmsfhpl5e8O1rQ379dubE5A/h23adenXr2Cl99IgQLxcHu1ZpaN9pQM9O8T2ffLJr Qqih4tj2w+KPdk/v0Za/j8UY0D2i8tbFC1fFK1ZNiOFSY6NjHN9cZrCazD/P+YhMEv/y5vhoIem3 o7mm7sn7V85eu/NK+NjPx/QK59FBMpMmFgkCQ+Pj2zSwSGKLgbqgGwLDvDxn79KauQ82hPoCSyNa GZ7OyA9c1xuiFWLVKy/qlZHV3kx2q8nidI61A4IdmN31hvTGkbVbz+NzIun80FHjR1rMFoPB8QyO e2/e1JdGe6svRJ9fXNFzzOT33n+9R0Io3IfZ7Bwhh89mYERSOMuvvFKnlSqNoYFC57wHu9XxqwaF zKQjvTJr6dvPxr0++c2DNxREWHUd2kuIfmLD/hM3/35TV3jT1IQQfy0LsoAbQhAWeGiSn3sVQSG7 kWhBrRGMQJzcKyW9o+skiVTKQ3iSjx5EInFGepcXjS57hUF7UFYgR7Re7HYb/A8kqjJOHzp+ZM/a peu7vP7RgHDjrr0H8sqyx3ZNiBbFv/HzsvZlWyY9fzD3q/np3YPPb//u0+//Fff/PDrQ4Z9ls/uW RBvF7rlaDYEZyLMdXfXXBv5T8dtPHtt+KnzOT2lc5Z/Tvuz2xqDghfPmh0347dNUaB3FvzF7Uoym Q3bHx9995Yf3hrKIpFvBgSHUiksfjnvrFBi8asXSQJ+/98CABLghCCRytOCBGza46/gxGX53L4gI 4oEAw4QcZnN8vhGIesAIpLCgoOVT01dRaUw2i9embVrnmK3fLzxTIW/To3skht3yC+JyyNHtP/jo NeWW3+ZtWG4lU2lPvfXT7OkvsFVnu3brEePns3lPTknrSOHUzPigsiLenvfFvMUrXtiGBdOFqerN FbxpH8/+YNbiH1/bCuj0xHd7hpDMVcnt/GkkQAtot/yfBS/9cLTdC1+uNBX/+Ps3/9kwCi36vW8+ CGaRbFpiUASPVXve+oMCZr+7y54hEAgEouWw2WwdOnS4dOlS3V1PP/30pk2bmv/VdkvpzezCSj2L zRGKRXw+l0okGHVaMyDSaI6F0GoOtFnUCrnWaKExOTw20xncxW40WqhU3/aMzWqxY0SvhUnsVpVc brAT+TyWrFzBDxZRgF0jq1SZAJfHZ9LI8ADH0mquha6tWo2BznJEdteqFEYbxmTDvLmyopAr6Fwe te4SbLcJm83u1Mkx75VOp/P5/JCQkFgnGIa9+uqrgwYNiomJiY+Pj4iIEAqFjqlTZHKjywIgCxiB QCAQTQAjBUUnBkV7pVEZTGrdAwkkjp/Ie1Y7Vp/6Asck9TpKhBE5fkL8G8TBeIgGjOXnz/I4gEF3 jyUTmSxXJx5UfK/uPIzA83tw56wjJywEAoFAIFoAJMAIBAKBQLQASIARCAQCgWgBkAAjEAgEAtEC IAFGIBAIBKIFQF7QiNbKHc6ga3SGAAKBaApWi8U5h6i6QNmtZoudTCaZ9SqNicDlMAleZc2mrpKq jRZAIHG4fBbdt2u0UatUGTChgIN/0mo26Q1GQCDTGTTPtUztNrNMpmTy/GgklzGpUSoAlcmitY74 DUiAEa0JuxNbNfhb9y69ySRVaWyOeD3OmD02R3gvWDPYbYBKIfuxmHQKBdddzAmRSISvBAIBf9uS J4ZAtFbMm79aGPDklB5JrmDL0htbVx7Rvz5h1J4vxnx7jNp92FPjhg1KjA5wLQVokXw0uM+WSouF SOrQZ/ibs2b2jxHVKnsWffm3E55fbexxeus8JgD60osfL/olr6DYShP2HzJ20vhBrOplBa/t/mHS rF0L1//1eKwQ2E3Xj2/94JNVg95e8OrQ1Ht0tne3okACjGg14NJrsVjMZrPJZIKvVqsVl+HM4hKN 0WQDGI1KAQRCXesYHqbX66HS8pmMtkGBUHpJJBLZCdwmOKn1c25VxhX6fp0lAtGqMOWvXPznsHZj uif544XkxrZVOy4GTho/JPP4rmP7wbEje377PHj8u59/MX0EBVqvNv3NqyWv/3lwVBvbj7PH//AT r+sXH7C81+k98/M7n6zfp++WhL8tObJy3e4Ti5Z8S7u569n5CyM6th+e4lhj21x6cMCzcySKaLPZ UdzlV/8bOublm6X0Hi8Z7vM1aDZIgBGtBlyAofTqdDqNRqPT6VVabaVGI9UZ2Bw2g14Tyq5uMxWq LIvlmMQv0+l2XboSwGIGcDkcJpNGo1EoFFyDa9nBRCdQp90KjWQYgaiN3WJ2xJCvScAALqeMNqmP T+nyyoJXo7+c/fwvn75QrNCu/Hg8B7aGCRgvIDAyIfj1GVOf+uqG3mBhkd09xrayE//0mr2x53PD b5a61sKJGb34xkgyCTNrFDHD1uzVKPQw0aIr/3rUDIqwR8dAKR5HmuIf9+43f2Sv/7LWUg93Hcyb O/kqJMCI1gQ0fw0Gg1KprJBKCyWVRgKBweaIxbex0BiTwYD/aq2uqkJCtVpDeVyowdAOriXA8C1M pDmh0+lkZwUBlfienBUC0aqxAZuPRRaIXC7dCsU1pP2CFac69frm+WmTF8XEfzwUZBGwaf7UysIL S79eFxM2jE6rKVbaitx57y5IS5++8NnQyd/eqP4mijLvzLJvlp3JOX+dGD833h/YLIc2/raknL5s /Y/7532IH8UMSJ4yNnbq96+BOr1Zdxd83MrNnTijIAFGtBrgg261WnEBvlxQyPbzE/J4zWuBspkM O4OuUGtO5OSFMxxGsKeBCzeg4kLdZbPZXC4X/i6TycRLGjKCEQgvrEAvN1vKjO4Eg7pKxOxFJztk FVdCEo01cvIs48Ulv246qHwsNV+rHtkxmmC3kOj8f7+azCTX6OWmVV/+djrwzLaPqaeWORYxhHa0 M91ityqqzu4+ejWuWyCdhOmKT8x/+ZOnFqwaFM3arpfpDWZ3bjCuICBQcI/OFW+j47pLcgIb5biv CWjW8DASYMSDhadTVa1dUH3NZrNSo7lSUuYnFrNZrDqfvg1gaeFz2OSIyPzcHEwh93SthKULSjKH wxEIBLB0QTGGb2FhQ73QCERtGGFd+wMbz1FcHWXDUrl9/Qlm+htkglWlUIHqZTAxAiUheZA+/7re nEym0KZ+sCgtqW3vfr2FDA9r1Zyz4Y8TMXHWMV0TDQpVeaU0Lfn075v2PhbDDYrv9s36K+9nbe/W 4839h3OCz78liYgqXz43aalJWlG2dlD732b9tWXGAJJFXiElAOI9LKSwEoCiS60GVg4Wi6XZfdFI gBEPCrhLs85gyC0t0xj0sECbzBYKmWi3ATqFEiYSUIhElVqdW17B8ePTqHdngVsWgx4SGXXlzGlt SZE7EZYxGo3G5/Oh5EPpZTAY8C0UYHyX+zC3QzXw8NhCIB4xGLGxQVt2HXplcDK0eguPbVyTR57d px2FYMzJPIN1fBU/yCq/PnPZEXbkPDaNQKRQhrww6bGgOkWYHP7dps06q8VqteQf3fDmzxf/9/uC lCCw8ZXJ+gmfPNc92L9tj95hJq3F9Ni0TZueN8DGsVEl/fKDee1ff/fpbp2cHdmwqriH0S1wwxfq Lp1OZzKZeM1gNBob/2Q9IAFG3Cfsdah1gMFkOpaZKVdpqVQKFRYjJzqzo3NJptFcyMujEgihXLbS aPLj8+9ixrhsln9U9A2jgUQkYwRgM1v0eoPabjWo1FB9WU7gBiztuLuW52eJ1bi9tJAMIx4xCF2G jJv35JsDdfqPx7X5aObnetrUsf2jMKCDpmFOYVaJpJIov/nZa1MPXSlb8+doFnYKOGoDm6+vooTF xjk37MSKk2R/VUqHFC5Q5uzd/fXuw3kz31MefnuDrsP4pEiOWMgRO44zqSU8JjspsVNsCE+Vf2rG /K//OpF/5dVpftv/fTzs7rTR3eCdz1B9ofSy2WwOhwNrBijA8DSb/Z1IgBH3A9yBGRqU+CQi9/Qh fK/RbL5ZUVmmVML2JIfto2OZSCIFiUQ2qy1XVsVjs+969mLCQuMjIzxTjAZDlUym0mrL1Bp7RQXM rVardftqgerSiDtquTujUB814kEGWm+w9JHJdzlIReqglzZvMv+09sSyFReikl/98+h7/g4jlNLz mbdOrj301MBNGIEcEBLx847VY5P45qqAMaOfiebRG/xKjC+MfaoLzSmh3HfO7TRNX3TpwA6MmP79 ig97tRW6jyNSGN0H9hRz8TOC5ZE/YcIIAATUu90LDass2M6GhR2KLo/H8/ODVgAfajA0haEF3OyW N3aH4YQQiKaASy98UvVODAYDrAhw5wWd0ZQjlbE47LteL9w5sGzo9HqFXG7XaYNYTHwYGN+Fqy+D wXC3heE27pTRsnlGPOLAYtWhQ4dLly7V3fXqq6/OmjUrMjLyXvyuxWiw2GFbmUwmuYoAbHWrZFLY jMUwIlcg4rHpTo2yWyw2EqmxYuJosgNCtY7abLD2MAGMTK8T4gqeL2wM3+t2b1lZWefOnfv06QOl NygoKCQkJCwsLDAwEL6trKwcMWLEoEGDoqOj4+LiIiIihEIhrA1g/dCoKiMLGHE/gO08qLg6nU4u lysUCrVaDcUYSrLJaq00W0IjIuvGwXgQgKWHSafD/5IKyZWCPLajqNfMU4KNXyi9sLDBs4PSi7tS IyO4YRwtft8XyFnhEtClu4fEx8efPHnyHgkwiUqrJSdQF7kCf25tl2SscfXFP+xxFIFAotN9q9X9 qToyMzPFTvz9/aEABwQECAQC2OymUqm4d0jzQAKMuB/gATQ0Go1MJquoqICvcNsRzYrJjm7b9sFU X0+Cxf5QG7LPnrUoZHgKLHWwkQvVF267PTIeQCP+gUJZdvXvP/8R9X9zZPsAAIyXj+wtxaIG9Ewg Y/ayK3uW/3t08IQZnaP9WjqbDy0DBgyYOXPm2LFjH/wS96CxefPmhIQEaPWKRCKovrDg83g8vMjf ycVEtwFxP4ACDC1gvV6vVColEklJSUlRUVFBcSmdz4cPcUvnrkkEwoIXHS1VqiqqqaysrKqqUqlU 8LzwgW00oNMg+pXvP/nuhwsP3ZLbTOoNC14bPmbyr6sOGZzuOJLMoz8u/mzaW29kVDbfpxTRMImJ ifARzcjIaOmMtDKkUunly5d79eoVHh4eGhoK7WA/Pz/c/MXjyTf7m5EAI+4HeAwNo9Go1WqhYkEL GD7TRjo9OjKyFXXYBoeEktkcpRN4Fmq1Gp6OwWCApjw8u5bO3QOOLX/XF+/8Xd71+U8WDYnL3PHX +/P+V1gusxjMztuPpY6c8eWzXS9u3//r8j0W1Iy5N0C1+Pjjj9etW2c2mxs/GuEE1l379u1LTU2N i4vDx30FAgGHw8GnJt5hXwISYMT9wO0FDUs+VCydTmew25NSU1tXVxiLQY9ISjRVY3ZisVjcqzO1 dAYfXOy64hmzlgkiEqa+8TKLQgzu0OPdOZO9jiD7Tfx2zZNxkrW7tioMSB7uFV26dIFN3r1797Z0 RloNZWVlUIDT09ODg4Oh7cvn891Dv3fu8NGaqj9Eawe3gy1OSAxmWGhoS+fo9oCFTSAU41prdYJP pvKcUoXwiVlVdqHSFBk4vGeiYx0bfljSixNH1D6IGT3+tRfLTmTlqZo/sfJRRq/XZ2dn7969W6FQ 1HcMmUyeOHHie++9t3///vuZt1YKLOPjxo1r3759mzZteDwem81mMBh3uyGEhwAAIABJREFUS30B csJC3GfcUTh4IhGhFc7YaY15fhBQFJVYjEZa545csjvgto/DeAFhTNtBudYEQMPzRB8VHKtc6/Va JzqdTluNWq3WaDTwFR8Kwd/Cdq1IJIJWWsM9zJGRkTt27Jg+fTpUl379+t2JE+/Dza1btz766KPu 3bsPHDjQc/XxuxhvB116RMtApdBazdivB2azqaWz0Jqx1Zi2rlkmGBl4PAdsCosDrLZHsjvBZDJV VlZKnOAb8FUqleIT3iD4wlw4TCYzICAgNjaW7QE0zqAwQKnYsGFDw78VFha2cOHClStXnjlzZvLk yfCr7s85thbgvdi2bdv69ethY+Xxxx+vqqqC1xwmMpzg0w7x+Hd3+ENIgBEtg2PGZ+txv8LRG42l twpaOhetEhswOeKa2K24tNpt5pIbeTC5SpGr0BpZbNdyslWqsjLAp9UJtvCQAZU1Ly/vppPc3Nw8 J9CKDQ0Nja6mTZs2Q4YMiYiIoNHuckhFnPj4+C+++OKff/7p1avX4MGDn3vuuZSUFDr9ke54MBqN 8Hbs3r17xYoVQqFw+PDhPB4P2sF4+EmOEy6XC9s68EK5F2i5k19EAoxoATACwWCxWK02YqtywpIr lXkXzrd0Llolgqi2YTRGyeE1V0qGpAUzru5c8dToqTD9+Lal03/o/u/sUY6D7OqzW44BcXQos/XV S2azGffwV3uj98BgMOAbsPr29/cXiURt27bt3bu3vxNYs99/n8TRo0f3799/7969q1evhkoD849H qXNPq3ukXAuhUctisQQCQY8ePeDtkEgk0PYlk8lQgGE6TOHz+QInUJjxQNB32IHf+h50RKsGWkBG OiMgKSUkLIxIbE3qCykqKdHqtC2di1YJ2a/Ne2PbPLP0wP9WrWn3/suxPZ9euy/BMdQLSCFxic5D DEdXfbBky7l+U4cGsx5oC1ihUJSUlJSWlpaVlcFXfBuqLzSM8BDBfk7gRkhICLScPHuP8Y0HZNgV 6qvFYoGq37lzZ2hql5eXV1RUSKVSpVIJTwePVec59vnogI+4A6ckw5uFB52F5i9+ZTynHcIbeicX 54F4DhCPCGqDUUYmd+rZi06ltnRemkOnlBQSgXB6x3aDsl4vU4RvMOrTC1eNW5P260evMlJ7fTW0 bVr3QI/d9ssbFox4Yymjff93XpnCIN3vlhmUGUs1+NQy+AoVCNpAbomFr7jiwjo33EloaGhMTAy0 IPEASa1rTh0+JQHau9BMh6Jb6gSPUodHisWjteMW8KMmwDju9c2gAOP9Gfi8f7xvAI87CxX6TmIA IAFG3CeKZfIirT4qIpLUah2JYWHr4BgnYxzdssmINPh2oUQtPrazy7qtQWJO3Z3+cY9Nexd0e+qV vinie5oLWIfKnMirgdswsa7GwOoVGj3Qlo2MjOzYsSPcwJfBobbO5mMt8PDser0eGr7Hjh27du0a FGBo4eFd0LjGPGq6i682CMHnGuGJUIChyQsvC2yUwA188UF4JKWaO+mlRwKMuB+UyxWFMplA4HfP Vy25x8DSGBcdpXqs98V9e1o6L60PYUzn12d1wnxYilhg8uOzEwfcRZ8AqCJQWoqdFBUV4a/QioWt KH9/f7FYLHICt6Ojo6Gy4jUvrE/dG5BWFKbtdnGsZm807t69+7fffktKSho2bBi06SnV63A/msBn pqys7OTJk5s2bYKND/iQ4IMF8DHAJ/07V17C8EVI8ZXCoVTfSVgxJMCIe47Fas0tK6dSaa1dfXGg Bd8mMbEo94a2pKSl89L68KW+rj3EJiyFhC9qidsi7le1Wl1rAg9EpVJBfQ1xEhoampqaCl/hdmuJ PX5PgeoClebHH3+sqKhYvXo1lN6WztEDxPDhw+fOnbtixYqVK1dCocXnHbm7BKAAw2YKPiQM223w FT6Tze4tQAKMuOdo9QaFTtdKx319wmOx2nbuem5TI7MtEc0GVmpyuVwqleJhw93AehDaH7hfDMkJ 3MDXhQwICIiPj+dWA1Na16Ds/aS0tHTatGmjRo0aPXr0I271+gTq7ptvvtm3b9/58+dnZWXhi57h jgIGgwF3d8c93vGFWJr9Q0iAEfcW2DA8l5NLe+jW6RP6CTAiCZ+ngfMIjpndFWBFVlBQkJ+fD19v 3rx569YtuA1NWLFYjDs6hYWFwY3ExET4Ci0PPACCmztcjuYRBKovlN7Fixd36dIFtVEaICkpCRrB AoEAXiU/P8cqmbjfuNFoxMOTwVfcV7zZP4EEGHFvgY9slUpFvzfBBFoQIonI5PHcQaHdcaFbOl8P BPBSeMZNdG97TpDFDQiNRgNrN6i1AU6GDBmCb4tEImKrddZ7kIFqAUVlzpw53bp1a+m8tAJYLFZ2 dvb48eOh0FKpVLyRDa8hvhyL21ccNNdRHAkw4p6jNZoePgEGjuFMDF/fCfcaxTW4pTN1v4GyKpVK JR5UVlYqFAq8Z9gzeiLcZrPZ0KKFrxwOxx1AEdZryIS9b1y7dg3esr59+7Z0RloN8Il94YUXli5d ijvluddiwSet4XOQmt3yRgKMuLc8rMF09EaTvKxMIBC4Z466e6EfSjmB51VaWpqbm5ufn++Onnjz 5k1YAUVERLgDKHbq1CkqKgrWWQ9IrAlELebOnTt79mzkidZ0iETi8OHDly9f7k5xL65aaxHSZsgw KiSIe87DJ0dQbytLS/AS6Pna6rqgcRfiuuvq1A2gCF+5XC4eQLFz587Dhg3D5/CwWKyHssHxUJKd nS2TydLS0lo6I62MgICA1NTU8+fP8/l8+LTjxdy9sNudPP9IgBH3FviAkkkP22BelVKVefI4cE4Q bOm8NAl4FyorK0s9wOM6Qdsd1il4fAl3GMXIyEhoIdWKnghBDjutnT179kyaNAndx2YwcuTII0eO wAKCv71bTW0kwIh7jojD1lusrTcAVi30BuOFo0flpaVQmqAAE6u5Kwt03xbQ5sZ7v93d4BCtVlte Xu5WWTxkcZmztxx3Jw4NDW3Xrl16ejp8C6W3tbQhEHdOZmbmjBkzaqfabaDqJpg5BfT4HEzuWJNu NYHj/4FPT4IdXwPPmUpmHdi0HBzhgx9f9PoeoxosWwJYXcCkJ5qRN7vdotTk7D+/8brGmho3vE9k Iqt66oTdqtt48L1z9pR5/SZTiQSrWX3+2oo11/YbiTEv9Hu3sziE7PEMq1U3ft//mSBt6XMhLI+v t1VVZS49/MdTT3ySwqR7/Ki5tOLIL8ePvjBgRizXR4A2N9AChiWrGefVMEiAEfec5PCwA1czeGx2 S2fk7pBfVFSYedXujIlD8gCfFXOP9EytVisUCqUTuKFSqeCGTqfDXcA8NRjmAbbThUIhNGTT0tIE 1ZAfuplgiNtFJpPBVlft1MJMMGEsOJQBhKUAeAjwgeXg9fkgtxPwMvYM4JP3wA9LQei7Xl+iLQHz ZoKv/waL1zQra/aSoh3zd0y1CAfEsW3L96Xf6LTyzbQBZEdhMl248OlP2f/yxAJHLAyres+ZeUuu HHksvj/VcHPhf2OnD/6nf0goXuqsuuvf7J92tPTyGKvX1CBNxe7P9354QckYaPM8Gcv1rN+/OPxR EdZrpMXYcP78/f3x5RnuLkiAEfcWKEh0CoVOIkFxID8cjjl2u16rJVbbvu6gEHdlQqrBYChxUuQE D6AIrVg2m+3vgUgkgoYsl8t1R090x1CEOUFGLcInJpPJRyBrqEndejsEmEasdTQYMhD8Lge1fCht BNC5O1B4l2WbEWgjwMheoLElzrRV53eVMJ9OaVPrOLPBmtjux7Ep/flkM7koSaLIMtodAiwp3vnD pX8ihX3xXChkl3fk/jem//bx0dFEq1K4uffhm5t7BL1Bd4ZRI1h1bCwpkFlOJnidi05XweANjrWe x7y7jg1ac1TosPJSTaNrk8MyfocOzz55KCpExIMNVKdQP15WWQX/oQhOFOwvYvoJDHIZcDYvcOnF zd/6PuKeNegZQxGasPi8HXwNOHwbCnCQE6iv4eHhPXr0gBvwLQpXhLhXRCaD+R+ART+BcKFX+tDp QD8XrJR4e1HSwMIlYPFscC7A62B2FPhpIVjyMrA2MuVBKz+3+vgiOfjn2cRODKJbgLDIuKenQR23 GotK95wyETvQIykYsJgkf19ermZOm90l4Odz2fA4ubZQbn7imbhYRzuCyO+V9NSlEqUFtiGcAoyx O7w9kPfxznNm7xWK/CMnTOddmrfhgLd4ktqnTQ1X7MveupZGbJn+ISTAiHsLlCioTEF8vlQquyWR BAiFrd0OhnJLplAM1aeGv+IbZrNZLpdXVYNHT4QbeAD3WgEUGQwGj8eDKpuSkoJHT4RvmUwmsl8R 9xul1PEa6O+dagcWKwiLA7W0yWYDahkI7eTje3ILQFIjI03+Uc/O6FS26uLUW5KX3ur3utCz1WpT 7jy9aPX1TYGRU8ekDqBg5uMXPztabpo2/EWmeqvN7tBUjVllZAjdUQVIJPhzXr3Her1crzeKaLUN fbvdbCUE+FNqe6Lo1cU2Go9BbJkGbuuuChEPPriNCA24YD+eRiHLKSiICAll1Cke9wO7Rac1EqkU Cpl8RxKHYUQSCZqwUGu1Wm1BQcHevXvVajU0ZDUaDR46EXd3gqSlpcFtePqeoRPv6WgxAnHb6B3d OUDA9E61AaMZiP1BLc2y24BeAcQsUBcLHfBrqTgwyrY/s3E6vt2ny97pyeHd2r16+MZfh7KPvdTH Q4AtFYv/HLjbSH+m2//GJ3SmEokm6Y4F59eZAPHrzV3tNpPRahv7e9m0Xj2JOoUZuFoFSlkJAN6G O9Rpe1A0jw68gSdjAVxWnW4qk77csfQgoWVcRJEAI+45DpORTIYPOZfBwCokZrMY3LEAG5WlB9f/ mZFXZbYDIonK5LH5foFif8KWhT8S26QGhImpGLBaLTZAojPpLCaLFRARaCn6ZclKBQAsQXDawKd6 9+2Z0DaCRq4peDYbLOVG17/J6OoyNhg0arVWpcKnympVarmsKj/nhs1sZrFY/v7+kZGRbdu2TUpK SkxMhFpLc7pG3+HZIRD3F+cTy/MOV2ezghIDIPm0aDEg8BXKA8pYnYefRE96OWU+oFBpGCU6jF9U svvLbRNk3Cc/HfVJRI3+2HOz/tyvw17ov2ZsbDTBmR8SK2lKxy+0NqvNoi9TnThSmtk94rEQpogD Mi4pdN15DLtZfrboFE/8AslzHS3nWHDdImg0KRX22sPZwGkh0GgUYmND1/cIJMCIewvmBGow7iVE c7oL3/nXGuSFp/f+e77AOzWqfYDVXJ5xLjej9vFUOrVHem+Fc1tTVXLw76Untm4Y9PLUF0cPJBFd hXXnhg2FBTepFPjn+ic73ZroDKZQLP4/e+cBH0XxxfHZ672mXXolCWmQEAi9I0UQUEAQ/qJI74KA IogKgggKiqBUQZAiIBKk9xB6KCGQkN779V73P3dLjiQECJAK+/3Ec29udnduud3fvJk373n4+NAZ DLitUKvP//uPRirlcDgikcjPzy8gIMDb2xsL2v7qXw0Hp0GR5oPDR60b638Fc8cDoRGkK0BIALh3 DjxIBfczwI5/wYiBQJEKShigpQic3AMS08Ht3wGTDt5rA5JuAE4gcDKCA4fB+TtAuRUE+YGIx1Yp ke71dtuKdIeo/tzDJK/QZbNChvjy+JUaYZFoSyyoa0nR1lW5ShSQA9xHDQxsM6jd/7CPH+aw72n9 Z3QfTTEWtRCYfz0xUxb+gbR4z36JalKrvjSCOSv3FkMY5kgs/ffeP3m6tP+u/gBCJoXxzHezH3p6 RJGUt2JT4g2m9L2XN78XM56mfJhpco4WCXJzzh5Ov55dLN91s/W4jgNrMurrF1yAceodbNwVm/ik kYilYokPk/n83Z4J17vd59suWID0p+6DrwC/BTuWO5sUFIGnuzNXr9OalQ8XD5qY5t5t3caFHFSv N1qoRPrV/346C8CM3Rc6O6gv7P5h3dZz/65Z5BzR+u3gR4NmA4YNq82pJenpOoXiFduPg9NUyLgM Fq6ybmzfCgYNAoR9YOFD8M8WcHQT2HXCWr7OEQzqCXoGA0F/8M8mMHcseABLbwMkArztDgYMAd4j wF/DwJQZQKEBKRtB91mVBbgKCLV72zk1xaFGGDQBgtw+k25xpgnoprJy0+VeAVGUis6xBUFNtuVQ JLr7zN4/TtrRZ/XZw/DtgHbnBgf4An3izNhhfdr/9LGraev9rbD8VNIqD5dRAca4T89892GP411V /+67vwWWH76/qXXLIfHXF57OUW+f9O/Vez/9m5NgLU86Mqz9QFaD959xAcapd5AKoAxTCYT8kmIv d7dXNhYRCt06zSNoCcADmquXt3fFqDaNzgD0gNBQkFaoJZBoPA7XWmoxVjQGUNkOfSasYKAzV267 eul6oV2Aa4lcJjfo9XisY5zXhDbDgWT447fyj8DKEiCggYUHwMJK1Y7EgxwW4LqC+1WW0oLd2wCn NXBzAvJXiVNBCA2ffzR8/tM+DnQfvc3VQrHF1COzIzZPyhSrVCQKh2d7CABq4PJem1gu7Rlc9pmp j7+Lxdjrqw7sADehiLHsTOtl9uKA1p9HB7u6EpnD3z46/MmTNSD4QwSnIcAEGNswl5flFhd7u7rW 4fEt1dfmEWksaKuWy/UW96ofiDMeJpdrks/9feZSInzr5vZiw05ms6UkL/eV2oqD05TheoHOXjWU e3YAT8TwsCpIh5eJe/WiwP46pVKXHSEyHbiVR9GoIYF9atiL7NAlbMCTxSK3GFE9NPIlwAUYp4Gw azDBbMq8d0/I47HrKiWLyI1XPdsh3SuwI7ha/GTdnQsnVLSHENx75IddfarX0OvBls3g5g0wbTqI tAUGMpnA7dtAXA66dS9SKLPv3IJfg2yxkCyWyq4eqMmEVl19iIODg/MMcJ8RnEZAkZ97NyFBrdW+ 8pFsP2AO6ylTyvJSRfUIcyQvf77Nr5PM4rWMiqQQnnCXVClB/CUgk4GDBx+VpKSAn9eAjb8b9/9d lJNt0uu91Or3MzMHJiUJZJhfF9ClpWV8/XXWhg1GuRwr0ZeWFvzzj+zuXWAPnYOimrw8i/45Qe9w cHDeEHABxmkEzAZD2rUrl+MvSZWqlz5EfvLd+BNHczMByDqz5rsf13yz6vyt7KqVysXK6ho/ZuGP S1at7BHMMSglsb8snftjrLra0gQGE0RGAg4H9KkYWyMSgG34S2k0Prx5HW446vVcg4Gt1XIq4rPL YmPLDh/O+u03dUaG9T2KJi1Zcnfu3Ltz5pgr+hn3lyy5MmJEyvff209Vcvr0nTlzlKmp9hK9WKxI Tn7Ja4KDg9OswIegcRoHaEcmnz8nKS6JaN/ey92dQiYTn+6WpVCraRRrAA17iU6Ss/eXLy/cKrG9 k8cf3gN/zLnM4G6R3o9qEGEBk055/AtHbN1NDpvt49Nt1rb2bf76acPWY7kH1iR/8FYb10pD2HQ6 mPNZldMHBoF5C4zl5Q9QID13GhaksVguej1sUYlQiE0m0QICzLduMdzdyRUJy0xqtVmvN6lUWPBY i9GY/eef0PwtOHSo5eLF1hKTKWHyZLNGI09K6nrC6m6Kms2Xhw5VpacHzJgRNN/qkGKQSh8sXarJ zQ395htOcDB22PJLlxACwaFjR6JtDN9iMEBrm0ClUh0c7KswzTodgUxGXpcMVDg4ryW4AOM0HPao jfYUfiUpDy4VFyW7uXkHt3Rxd4ciwmEw7IkLzRYLNJENBkNJYQGLwwnweTxfS2Y7dhz0gUuEgkKH 0ky2zS7TAtu1s1do8dZHnzhLOvkLKs5NbBHVc8QnboEOmLc0tcPw2SyPqKx8SpDj86KCEAjGoKC0 7Jy02ENG2wCyjEI55uFhXQdMe6Tc3P793Tt04Lm5Mb29sa8a+tVXJZ07s1u0INocNaEchixeXHzy pHPPnvarwQ0Lk968yW/dGiuBIq0tLIQb8nv3sBJVRkb+vn2oxZK9fXv4ihWwpPjEicTPPoNSHbFq lft770FTu+Dw4fRffqGJRGFLl7L8/WEdqNC5e/fCw3qOGkW0tRAeVnzlCj8q6lHzgC00n0JBYrMR fO0yDk4jgQswTkOASS8WEgtL8M5kMmGJ2WxGDXpxVqa8sCCJRHLy8GS7udMZTBQBZqhGGo0kK6sk P8+o17kHh7i6uDDpjyLMEWm8dn2GRaMAC8f85BkdvMIHVfblRAjeoR08W7a3h7whkKitOveOAOC5 YatMZnNWXn7cvt3qivndGr4gkcgKCaGz2XYblOnr6wt7DJXa5jVmjNuQIcQK1zO4S/SmTXqxmO7m VvGlaKFLl8pu3/afMgUrobu4sAIC1JmZTj16YCVQeqHpDA9rfbVGKzJLrl+HRrOuuFidnQ0FGJrU mVu2lJw8Kbl6Fe4FFRfq+q1p06CoCzt0aLd9O3acu/Pnl124EPjZZx5QxXFwcBoDXIBxGgJMgCkU CovF4vF4Op2OZAunbDI9StuJotDMsyiLiyR5uVgISKPRCEvMFX7FhRlp9xITo6Ki7LkcEMKLDbDa FiJXV9vnqq9Wb8jOzrr835FnqO8zTlnlHex/cLmVSyhCIfyrXOI5YgT8s7+lu7t3PnIEXhoS69Fy KVG/flCDYQnUcmDtRpBcBw5UZ2XRXV254eHWEioVyrA0IQEqNwkbo9bpTHI5FGZDeTl2EH1pae7u 3cBiydmxAxdgnFpiNurlWqOAY/sposaS/CK2iwfjZQKroyppuVSlI1PpXB6v8jzRm8ab+81xGhJM fbH8P5j6wg0owFBisQpQgKEYwxKtVqtSqTQaDdyAJRYb1homU8qVy1DGw8PD6U/mNH0FLCgqUSgd uJxq5VD7i8WSh4l30m7dUkvEdXjGF4JYdbEWVGLP99+vXOLYuTM/MpJAJhNsKQuhzAdMn+7cvTs0 rKmOjtZd2Oyw5cvLr1wRtm2L7ULm833HjRNfu+Y5enRDfQ+cZk/C+QNfrrn3V+xyBwJQZhwf9uHq j77bPrar14sqMGoy7Fm36Ld/b9JZXCeXqOlfze32gsFwXhSTIvtcgqRzt0haEwvTjgswTkOA5eNj MpkCgQCKMZvNxmxc1AaoEGCozUqlUi6XKxQKtVqNKXRlkc5LuAHrtI+JqeyQ9YrklZZmpaUhJLKL qyudRoMWtg6a5mZzaWHhw4vnZWWldXWi+oNUNbQnmcMRduhQuUTQtq2gQn0BNiG9ZAm8oLLEREVK CicoqIEaitOcSTy7+9TRI3G5S4Z4UzNOH467fCvsdOLoLl4vbAMjQKIQ8zuPXPIWZ8G8Rd1b/nAo WfpOEK9eGm0jdf+yj1Zej4272dqxcfL+Pg1cgHEaArsFDJWYSqVC8xfKrXUCuGKNLNyAegzFFUqv 3AY0gqFIV64DlRjupS0qvHL+nJufv6OTM4fJeOnUQ1D/1WrNg/v3ch88KM5IB7bhXBqTRedYo0fL JWLUYsH6DfbUgZXPBY14Oh3qtdU725ZgovmlFyw8cuTOp59CMY5YtUrUv39jNweniWPKvncH/u/m g9IhHqzYg/HWnGS6fJMFJRMRo7r81pXjyfkEF6+grl1bJV6IvZBE7d2GkpqrbNOjt5/jEyF3iKBl cEjHvn2PhXWc8tGwbyesbX9msRPZnBh/9lZaIZHk3qVPey8nJkAtpVkPjp+/rNAYOT4RI/vGXDv2 t3PkgABXdsGD23ckjAGdgowa8fUjp9I0Or6LT9dunXk0gkaSdzXuzLWEe+cvpc7a+Ccn6+z1dLVK Wn5g++8JrXt/3DOw6bgd4gKM0xBgHlhQerFXbGzZbv4CmwBDrYUCjKWmV6lUWq0Ws4DtdWAFKMnQ RJZKpVkJN3MYDPegYKGDo5DDfiHx0+r1UqW6rLAg+frV8vw8g06HlUN518hl8A9UTSABJRZuY9PY 9oPAj1gsFjTlYa8CfqPmqMEmpRL2eiwAGPHcEjjPxZh153I+/P/+c7c/jxD9lyVzC3QsFmcZjBaS Vrzq2/mbt//p5BFdUij5/vzV3LMH5i89s9UHzS5Uh7abGXvqG1HlhPewt617tDie5erdvwU5IeGa VGuRHV/2/ry9Qp8W+pNXT82e8dO3C0hF12cO/yRJGB7CyL6uTxnaM+TPX77vviQmQMS4f/7gugfe /WO8dm1c/tXnB8MHhOalpXdesO+nQQ7Lvpq7dce+Vn2GJ6VcOZyQ43/rwPb917QKxcm//3bX+Y3F BRjnTQNTLyhmmCN0ZenFwAQYGsFMJpPD4WDqW3mMGtgEGJrFUH3hEUyFhSV5udmJdxEa3SM8wsXD U8jnO/C4RLufFdRC1OZkVTHErdJoSuHOUpkkPzf9xnWTwYBFx4T6Cj+mWcwoQtQTEFDJZYxJpXAp NAKbRa4qsQSziYqQyDwOn8+H1jxs8yORNuitwW2aiVOJaOBAvVhMoNHcBg9u7LbgNHUU94/ddon8 fDDx180X73ZxKpa1/HXnx+tXntXoTTkX9v++Ju6ruJxhjvlDhixy5XNobEchLXr92W0hssuRvUfG 5SwY4oFqdEbbnUxi0hF5bs5dw82zruoDP63ZcSG1/eyvPZG07mN+CFh2aNNA4QLvqKy8LBOKHl/9 4UO33ud2/Vh2c++XaxMRTc6dRNCdAA1jc5Y4Swm8lWUP9649terSxXbsjIljPikoVKhL1FcuxhWP 3LltxSBjUSHNN9BxxK5p4/70f2fVpqNnIoRN695sWq3BeY2B6gVVEHvFSp7UYIoNOp0OjUsot9Ws ZFiiVquhuYkpMcRoHUZWZ16+lIGidC6P6+zMYLMpZIp1batVKwnAYsbGug16fXJS0t0rl1VyeUhI iLOzMzZ0DKEQkJDS3HHJaTle0Rv8hQabAFvdxIho37QHbz0k/PPZiFIWA+s9WAVbXtw69kCAPPDo 3IEkNlsgEECTHbaZVJJEXLgCGTQLjO7R0Bf3pSCz2QHTpzd2K3ALgvtQAAAgAElEQVSaBfpTv25y dY8aMiRk9V/rVvzowXn7g44hLX4q+D1HppWWp4RNnzoyUmTMK7QAJocGJARC25kf9PDmG8ucyVRK anpB/Nkd3+y5aEFJFEa7bQe+JBCpF/av6rnBurJg/Mq/Vn/6ji7532STiX7sxwE7JWGTZ30zdZ4j uej0P2W9548SsCjFBr0KPiLIbKEAAMwnhGBdA6GXFeZqdHu/HfNJhmHIoKmLx0UzSeJB7w0HJ9Z0 arWg89DlP68KhNXMtscLilqe9RUbA1yAcRqOJ2dSKwPvDyxlIZS6atKLAaUUqib8CEqvUqnU22Ji 0Gg0bMES3DaUl8E/bEWT2ea9Za401l2WmSGXSGA1uDsb6jSFQrXhV5zzyY27Ar1JGsR1c3OzC3D7 eyf63kwiGUPdvf3YXAY2fo4g6qCRXziWlCJ+gd6+vgiNBs1feDS6JoXebxSSUQj6TKj364iD08CY yv/emSQcO79lTJC7ft6R84qVRzqyWY7+rqUX0grDUSLBmigQIdFpZLpGZgt2bjBbb3ONTAHvQQ6H E/PB3D1DZyBQNkkUDgHe106Lf/iql6Bs4cJFseu/CguMGOVnHRg2eA/4Y907fq7OuQ8Sc0op6nJg oZlh7bLSDBmFjFAdPDwtwGx1ziARrOKFomZLKdp60Lxvekf6iZjx/8SSeg+Y+Om3oyeqUs5tGjdj 2ukZ7w7xtgYP0OlMYrEaOFCe9TUbHFyAcZoKmPpWs5Irg60JNhgMfD5fawuwDNUXbmC2cuVqEFMF djcuWCc7OxvWl8lk8AjQbGUwGNByFYgcch24nK37GM6evv7+pgoB5rBMJc6uol0yB08vHo8BBds2 BG0mLJxj+O8otdjJ2dXV6qNFJkNtptB9wbQV6P09zSX6oyY3N2fXLn6bNi69ezd2W3CaOsay9L06 MDKmJcOxxeQBnMWp0V1C3MkMkmugz+79d/sObnlr5q8r/Zy5Wf/du3fm543XPiKDW6vmjBAfz7l9 1cIcPKi1M40BaBWZP80GDUBKZXpC54EfH4/u8OnID7+fOUq4Zf3AQJ+EU6eOBRGUmZd3brmxNHb/ 2C/aTVv7OVs76OqGFZ6DvycRaS7MwrVL598Pdz8de9TSowPTya9tjOTciUNCY9amC3/sjiufODd9 07YTE0a9pUi+oSTS2TTb/YiiRrNFaTA14jWsEVyAcZoW9qyFNWJfTAxlFW5DEa0czQNUzCXDEqMN TIMxAXZyckpMTMzLy5NKpXBfHx8feChov0IVL4zyD966jxoW6u3vASq6ApTgIIMpD0ENPGdnwKZC ocXahnzwMZqdijr5s/n8SpE1XcHM0ciCg8DYPDIS3v/66+Ljx0kcTu/r10lsdmM3B6dJgzCcPx4z dnhbPwSw3pu/mvCQHSziEshozy4DU28Cv07vLl8pibt2Rsz2/HjKHHGx3OABRO1a+TgJvN7636Bx H3lXdYKGVnC3dz8kBLSA2wyXoPVH/umy4YCXZ4vfjuzd+vPOtOQHRKr7F+snDGwXRInavtR51+3M Aj2B4UZ3ICDU92ZvVuw5Xa4GbboNpLT2YgoDv97wx/Z9Z+8lPqB59Nrw1/86eGm4ksL7D5MJVO85 q2Z3dbGavGRei3Gjhrd0r8eVTi8HLsA4zQZMF6HNCm1ZuMFisXQ6HeZQba9jF2BMg+0CjNG2bVso wLBCcnLyoEGD4KEwH2aqRAZvU6ann5eXCFQ4YZFIBA6LDlrHMBx5RDIJ01rrOUxqolqMCIR0W1xM pBKgWA7aCJ7S/KYFFv+SwuMRKqJ74uA8DRI3cP3vG0i2uOLenT6e2QFgIV07vTeuzRCESSN/MGnu cKMJKisR9lhN5pO/nPXrNPK774ahAHkyyQpCpLw1fKo9DB2B6TpqLuaL4DB92XKTdYSZCO8+awHV adTEWSMsls3apHS6IwEBYR3e+aHtAAu87azJt4nwWN6t3l4U1tdsQa0dYdu5Zi0ON1rDtRIpZBJ2 DrJz2xXfRJKoTWsRMMAFGKcZ8cgwtcV7gvYoFOAqobIqwAJY2sefK08njxw58vDhw1CYr1y5Am1f V1dXKL7WQWTUGiGHGujt5MS1n4uAmCk6BGGxqXTaY/WFoPA5YAR+jkTbaHMVex1lA1b1iFpNk5aL Fzv37MkOCiKQ8IcAznNB4F1Qsfk4BiyRTGGSH5VRqI9KqUQE3pAGa5j2p07HWB0kaywnEMnV9rLe 9dqsu0mUABbmQkJ6FISHZJdTKPyVd4JvqcRqv2oChdq0Zn8x8HsPp9lQYZiSsBVNdumtPGFsN3Yx 6cWmje0CLBKJOnbseP78eb1ef+bMmVmzZmGLfQkq6/QUhUwjVoSUssoqaoKnAbYzVlFZuA0fH0ZL DUPlRHJzSbENv5Vj166N3Qqc1xJCaI/BH6kd6+6AzA+Wr7W4tSY0p2X2tQIXYJzmBGYEV46JUaO7 FibMlYN42Jk2bRoUYLjxzz//fPrpp9bgXBk3CCtWwxLi57MI638CHAlyT4l2jQbHNyB/nAUPLyNz EbD0U1B0EeQ4gq6+YPVccPo6OJkCFCvBorfBf7uBVx/gpQFzvgR/HAB3MgDyL+jjWa/XAQenCYP4 RXb0q9MDhnV8ty6P12TABRin+UGoIYVtKgAlAHR+7r6dO3du0aJFampqUVHR3bt34Vtg1gOqFxg7 FjDcERIJpF8A+8uRNq0AgQLadwHtAXB2BsAIVi8GxB4gZiaQG0D7ftZjCZjAKAVrfgNtUDCvAzBS rAeBsF5ysAt2F9IKi6xROU3mnNLSe9k5RpOJRqHoDAb4SiISpSo1g0rRG008JkOiVJJJJCKBoNbp 2Ay63mCCb7hMBqwDN3QGI4VEbh8c5CLgYUcOdHfDZshManX6+vWlZ8/6jhvnNmRIc3HbxsF5/cAF GOc1IA+A0QBEAtDBGmT2mXC53E6dOkEBlkgkV69ehdtIcFewodJgrGgk8NYBLhUMnAYGVtrzu11A SQM0Pli+rVKpBWzeBpjugM8A2yqXvwAZRcXlcgXsVaQXFiXl5DhyOUq1lkGn9o1qDSVWbzRq9QYz aoGqrNJqoUUPN6Aauwj4WCJks8VCJpJgBSKCUMhkD0eUanU+Icg1msvJybAO1N1yhTLC17ulp4dG p2eKyyWxseqMjKKjR13eegt3gcbBaSxwAcZp7sgAmALADQDoAJRDc/XZtalUateuXf/66y+dTnfq 1Knp06fTaLQqNRh88EToeCtcD8B9spQAvFq8XLsLxRJop6bk5x+7mUAnUxAEMaPo1Lf7uQkFUrWm WCItlkoNpiorFzHTn0ixvjKekpMRHsdgNBkAgOId7uMNS2hkMrmo8PLhw0kiNzWZREPRVgym1fk7 JIRYNY0SDg5OQ4ILME6zxgLAMgBO2bbTACh+rgBDunTpIhAICgsLr1y5kpeXFxAQUN+trAy0Yq8/ TINm69m79wLcRCgK3u/S2d9VpDHoVVpdXnn5g7z8an7dr4jOaNSRyGGHDwGDgeToqOHySklkcVBL SZnYcOhfRCj0Cgp0cH7+dcPBwalbcAHGadZA9V0HgC32nXUO+AEAEc/dx9PTs1u3btAIVqlUmzdv /v777+u7lXb2XryUW1qm1etbenn2bh3u4ehYKJFCgbydmWWqlHix7uHxQMsQcCvBVFJCKSlxt5VZ 7t/L2f+3hUop5wuILs7evXp5ffABGR+Rxqk1eoWkVE/2cKz4zaCGrPRcvq8/XZb60/pD0YNHdQtz rzwnVJR25YcfNuTJDH5t3575yVARr4axJosi/Yd5S9zeXTiqdzABALNWcTf+UqpEHxjZIcLPuZIj tOHKgfV/XOd+/91HPNs51OV5J44elxMcu/Tt6edQXz/jus141kzWTODgVMcEwJ8ALIUGXkUJtBpP 1mZPAoEwZcoUbDh306ZNUIbrrZHWCVqNXv8gN2/Nodhtp86kFhQ683lje/cM9/E2mC0p+QUKW95j Y0W4rnokJgZUfXYQTCaKVkOTyQxZmdqrV+Nv3Fx/+lxqfoHWAJvW5MLW4zQ9LDf/+D6i9xpNxXtd WdqUsf23P5A+vPzPr6vn94oK6DhsxuELd+W6RzMpubeu/nsw2WJOObR+gc/IuQW66j8zs17y8/vj Fmw5eOx2EfzMrJPNnzS430fTvl2yoEdkuxUnMypuEjTjSuy42V/H7rmqsYWey78X27dXt8+Wrfl+ yczQqHdvyZpHQDpcgHGaKXEAfGtd7l+FM7bEJ88nJiYmPDwcbkil0pMnayXbLwHU1KTsnJ1nz/9z +aojl+Pt5NQltGWEj3dyXv7D/AKjqWEj0/r6AW4Nk9gYaEioof/bdBpt88nTu85dSCsorPcOAU5z BzWVlCkMXGD/oRhUGr1KTQGAzuCRSCFTP5vjq7k4vHevecvXF0htHWUCCBwy8sD+2+f/3Riac3jL xeJqh7x9Zv/aInmEJ0CItkBZCKlLr8E7Dxy7FHdm0dg2S74/inW3TerC9YtXq4waBBAxDcu5c8W7 x5Sj5+PP/LM5in3/bGY9prjGlkFiyUlf0SDGBRinOZIPwEe2Sd8ny2/WZn8ikThu3Dhs+8CBA1i8 jrrFYDL9cerMlpOnI/38JvZ/q11gC4vFotbpc8vKDQ0svRgODsDdveaPhEJk0mSRu5ubUNAtLMSJ y910/NTPh4+odLqa6+Pg2KFUUhHElgMUIHyhiErzn/DFt5v3nD69+7Mty+ct37bXYEZNZuDhxoXV +M6udGsqlKoCZM5fNWZun9GfTIyyjXDB+5TKGjh6Ru8oT0l+xs30HJMXB4t+Ff/zlP+k7BVfTLWu D7TRdvjCjctnBIp4Jl2xWlHGZVT1rKxTMN0lVOKlD4ULME6zIxtYlwfl1PQR7Iv/Xcuj9OnTx9nm eXT37t3MzMw6a51t2PnU7btf/blbolS936Uzl8m4m5kFrV5N4w7tstnAx7eGcgoFDBwEXFzgtbNY s7tZ7ZmOIcFylWbxjr+uJKdYcFMY5ylYfyyFlXOhWFALnUUhIVbjECUhCIPt0Ondeae2fb7r5z0p Cl1eaUp2YcqpY//MGD+9UO7VN+xxtCyTVrph2vs3fd6aNmyEXg3v5Ec/OwSVLOvcJbpTt93Hsg7M 7UdCTRknf+/x1am+Yz9r4waNbTNWj0xlEgyKswd/Hz1sirH3t6OD6iXCuV16sVTiZDIZC8xn//RF D4gLME7zQgnAAgDuPb3CcQC0tTmQi4tLu3bt4AZU33v3nnHAFyMlL/9A/JX4+8kD20V3jwjTGgwp +QUafbWhckAV5wcdu8R4JMc6z2txvjeu+sXH+8fHBZ6+xnpCpl2unXdLK6peatH4njzslCevVkxS FQdv3S1QVbWz4dMhoiYPtdaRoEcPQKhixpCJxNb+vsEe7oeuXN8fF59RVIyPSOM8AUHgRCdRzHbZ UUqLVFLXUBHLthz/sRpFdX67g0PW/RLrZPGDM7Gr1m6jt+yz9eDGMF6FhxaqP/3H2k83X9WU5K34 cuaftwxX/v5+Y+xV60cI+4PfN+7Y9GOnNg5fz9xXmHNz4fwlCDA9OLd13tpYqfj8zG9/KVTpdfLC NYsm9R2xpsucDf/9MLX+EoxgCcspFArNBtzAYvO93Fg07gWN07y4DcAdm7/V0yiBIghV5bkH4nA4 nTt3/u+//7Ra7ZEjR4YOHfrqjUvMzNl1/gLc+F/PbmVyuViprLEaSSMPXfOV6ym30rc62RxYFP4z 51RakNtWcbGdyh5Ny6IN3rfaf82lvM+XFwSI7JWIWknkVxNcrmnTPg8s9+DarwhNnNXmiy94aSXa gUMlrKo3eGgYIJFA5QFwJhNMmQpYNbuMugj4bAb9cnLK3azsEV06YauKcXAegRAd3JnktKv5WoAZ nFkpyVmugS04aG5hkkYts1c0GEw6jZszm1YKQP+Z3/4+Y9gThyK4tYz64stFRrMKkltsLiRnyPS2 Ph9C9g5r7R0W4aDK7DnlaAlhYK+PZgVJtGq1usyQb0YT9Co1yYLeOr5uwb7Si5m3OnvUY3YvzPal UqkMBoPFYsHX6lEEXhBcgHGaF10ASLaNP58CYCUA6ba+NrwH1BUVVADcrY0AQ3r16gXvH3gnHz16 VKlUsl92BY7JbM4pLZMoVQcuXY70940JCkwrLNQ+YfVW1FYFrvvSMYl1/4/pkkdmJ1sX6SzptTgv RoQgJC1XoK4Uy5KZdU10PlvvTAeWyhPVqMOFc5wigjUzE6VK19vx0km60joxVoPFSqGArt3AmdOP 3tLpYOJk8MxvzaTRekSEZ5eUbjx28r1O7d2EQj9XEaFOV2LgNFsQ34jerqx133y75dspAxmG4g2/ 7ejd/yvYlTQagcWikygUeiJFIy3ctm5VssnTh0sutd4sNd4X5LCuA+GfbduwNn37zY6b5r/XXpoZ N+m9bz/8dXWIM7h2P5XuE+rq6tV6xnxsn5wjX5+6F/j7DwucyODcrct9+4RpE04evGFGEGZ4165+ gjqeBoY2LlRf+MSA0su1AZ8Y8K3RaKyxcm2OiQswTrMD/rK9bVEnMfwAWGIbdr4OwBUA7tus5A/g Lf3cA4WGhkZGRsbFxZWUlOzcuXPy5Mkv16DUgsKD8VeDPNz6RLZiUKn3snOePmBrcbm4wftEauHc 71Q8hGwBRqsG64kGhSB2I/8/I0KgKPv+L+HdTnaLVuceeWdxYIsfp1Q9DiLp3Dsh1CfmoyUWOqXy yUq7DVcH+HSYtqLm8/cf8EiA4QOifQfQps1zvx18lHg7O9Eo5OsP01S6ex907xro7vbcvXAaEQqF otPpXtE4qw0s7+jffvn2y69mDjm5hWEsURIH7R7bF5ZT6VwiKXXqsCFubIpGUpiRp16+bb8Xk3IN WLj050ZKtwANQLXW7ibT0T/UTTvxg2EObFRGdVrz52znSpJFoFJQtNzmtAAYLu5xvx6W3bwO2BR5 WtbwPy8v6edVt18W3gh0Oh2KrkAgEAqF8JXD4cASuVz+0qPQuADjNFMKbd5YEB8A3gHW6JEf295K bWZxrSYsYX925syZUIDh9vLlyydMmEB8wcwEFhSNvXr92sPUPpGtW3p6JKSnq/X6Z+6gdt93n6CR ua2Y5YaaTc69b//2eQlTzLqvI7gzcpZMN6Se8l83N6zthbsejyJNmqkciSuZqNSZqybuNTI5MjIf pVP1jvzK31bP5TMy5Fb3jhrH6X18gKcXyM0BLBZ4bxio3TMaPllEAgH8Sy8s2nDkaK/I1v2jo3A7 uMkChUEmk7m4uFQrZzKZCoUCflpnZyLS2w+bdmLQJ6VlpQadxcXHm2a7gQJ7Tbxzq8M/h0/lipVC z7Ah7/R3s9mj707+9d3nOx7RZhwpMyB0eCQiW7Qo9tykojyJ0iJydeewqoRf9eg9L+WeHkt9MnD2 TtXsOvtaT6LRaBgMBo/Hg9LrbANuYAKsVqthjwdT3xeVYVyAcZoppx+tVADRoErsZr6tpLYMHDjQ y8srJycnLy8PKnG3bt1qvy9U31tp6ecTk7qFh5KIRCjDz90F0anJJp2634icft0tmnzPTVs9/rtU Nqp10dDRZe8ML2jhTPBlCv+74HAjD3j4Vz4VoDE1jvxqR6OWZpMQBH0iSypBr7YQQtScp5ga0dGg tARMmQaeeEA/F28XZ2jcX36Q4uEgDPP2epUFGDj1h6urK/w9PynAHh4eiYmJnTp1qtvTkag0V/fq +Td5nmEfTQurVkgm1ypRGEJjVlJakqPIx1FUY0Uih1Nj3Pa6JyMjw9HRUSQSOTk5wcuLCTCLxaJS qcXFxTQaDfOOflEjGL9/cJopZyo2urzKUWDX1e5+FRsb+0K+vhcSk/46HzekQzsWjSZTq5+/gzX4 lJ5oNql7j86Ibp3VdWBpsJgtK0AIgnuzJxe2sK6JQm0j7NVvYoOYmWUNTfAEFguVZODX6HXCMZOe 8ixoGQKGvAvatq1Ng6tBIhAC3FxdhYJd5y7uvXDpJY6A0wAEBwffuXPnyfJ27dodPny44dvzGnDx 4kVfX18vG25ublCGuVwuNH9JJNK9e/egAEP1JRKJ9gAdoHbTwLgA4zRHZDZfaGCb6H3+LOaz6dOn D4Nh7UffuHGjtLS0NrsYTKac0rKjNxLebtdGozdoDIZaKreFTDNTyKz7D8kGE0mnohgDlUJv1FQe sv9fQZmKZNS7XD/KLioubyUCqJmi0xNQgJiNNC1d42EmSBVkM4qYTRS91emDYNQTNTqiVs/KLSNa YLkRHhOWE/VastoIUC1FpUJqbFVICHjnHfAKA8juDkI/V5f45JQ7mVl40MqmBnzuR0VFnT9//smP evXqdejQIZlM9uRHOM/AaDQePHgQXj27+vL5fCaTCbvvUG7Pnj0LTWGoxEQbLxQhCxdgnObIvxUh J3vYxpxfCWgutGhhTSmYlJSUnp7+3Poms/n4zVubjp2IbuFPJpKMLxJFC6U7ZA3pTt25qO2qtZFL 57veYhW3DQFGLev8kaiFSyJXLY/4Zb+y7/xkXyYn+Vr0suUeEiMzN6Hjgjn8hNIWP64KLtILb19o u2Ibx4w63DrRadlviKQw8KdfnaVqQcKR6L3n4ClcT++OXPEXUXsp4qdNTGUN/plWX2hKrUYCnwZ8 xrgKBAGuoh2nzp69k/gqh8KpD6Kjo1NTUxWK6uEYoU58+umnf/31V92m23rtiY+Ph7rbpk0bDw8P Z2dngUAA1ZdKpULRFYvFGRkZUI+xxcHwFdPgWh4ZnwPGaY4cqth479WPBW8qeGvduXNHKpUeO3as Y8eOz65fJJFeT00b3aNbvlhcy5HnShBLeo+95NPG514GgdXm6vRIuRPbgoCE75a7JaVA07Zw8Iel fp4GaMcIBCaRt5ZG0nAiLi9ZiVh9PYkmRypDyzMF+OkIiDq8e9z30QgsJlAMPAab5WBysN7ORV3f FUf2gxsoha5nPd8V/KXxcXGmU6lHbyR4uzhDMa6/E+G8END2YjAYXbp0uXr1ap8+fap9+sEHH8yb Ny8nJ8fHx6dRmtfsUCqV0PwdMWKEq6srjUaDumsXWnip9+/f7+joSLWBlWOxsWppASN4gBuc5obM lnMwFwAqAA8BqIPFBidOnOjb17p8ws/P7/79+9Sn5Lo3Wyz55eKdZ86F+3gL2GxJfaZRai7cz8lV aDQT+r3l6eiA+2Q1EYxG47Vr106fPv3ll1+SSNWtrAsXLsyYMWPXrl2hoaGN0rxmRGlp6cqVKzkc zqRJk7AZX0xfMYnVaDSDBw+G3R0vLy/YofH39/f29nZxcWGxWNjo9HOPj98wOM2ORACwsTX4+HB8 Tt3aAc0FePMAm6/jM5IjpRcWbT5+0sfFhctiSl/Y9n09CfJwZ9HoW06cLhBLGrstOI+Aj37YlSwv Ly8rK3vyU/hrX7Fixeeff378+PH6SEPy2pCfn//ZZ5/5+vpOnTqVy+VigSexuV7MwL1y5YpcLmez 2VCbmUwmVGJsXLr2FjBxyZIl9fslcHDqmKMAxNrmgAcAMMgWCetVIZPJFosF2sFwG95RH3zwQY3V tp440z440MvJqUyhwIaOUBtwX/gffJbBDfi/1/YPfk3bt4UvdjcT+KRx5HE1et3l5JSu4aF1m64c 56WBMpCdnf3w4cO2T7i7w3+jgICA7t27L1++/Pbt2zExMZRX8wl4/YC/cNg7mTNnztixY0eOHAmV tbLha6+2bt06mUzm5OTk4OAADV+4IRAIYGXM/K3NvYAPQeM0L4wAzAbgV5v/82oApj25ZuflUCqV Xl5eUqkU3kUXL14MDAys/CnUnsNXb6QWFvaICCuSSLHCrNTUzT98D02NOmlA0wdaVC3bxXTr288+ EIdUPGX0JtO1lIedQ1q+3S4aD9DR6MCnutFoLCws/PDDD3/88ceoqKgaq2m12v3798N+p7+/v4eH B5/Pf8MnEeBtrlKpiouLYccFSumkSZOecXfHxcWNHz++VatWrq6u3t7e2CIl+PTgcDhYhobanBEX YJzmhdRm9V4CwBWAHQD0rMNDw67unj17qFTqzz//PGHChMof3UxN23bq7KjuXRQarali1C7j4UMg KZ81a1YdtqEpc/78+S179nbq1ZtOp1PpdGs3v5LDZ05JaV5Z+Ud9egZ5PCXrME4DYjabNRrNtWvX Nm/e/MMPP0B9fVpNtVoNbeWSkhK48YaPSEPVpNFoUHrh5YJS+oyaUKGHDh3q6ekJa7q7u0MB9vHx cXNzwyxgMpmMx4LGeS1RVeQidDJbAowmq7/wmbt3j9+8DX/vUBO0BmuodwuKMqgUazoEBBAJRMSa NdS67gJWsGYGRNFQH8+xvXrC3ifUD0qFl0r//v0PHDig1+svXLjw/vvv2yP2SZWqk7fuDOvcAR7W VOkJZR2Jbdgv3+jIZVJxWSmXxwcIYl1uUamb7+4gNJpMB+OvfDr0HRo+pNnYwB82lIGIiIgOHTps 3br1iy++gG9rrMlkMkNsNHALmy8SiWTx4sVCodDBwYHL5QpswA1s8PmFwtniAozTvLgBVQD+r0zu fOpWxsP8eCqFrDcYe7UKJxFJUEoVGrXJgsKOPJVM0uj18DFEJZOhmQbFkkQk8tksg9EEVfNi0v3N x0+VyuVQkvtHR9FtczatW7eG/dnMzMy4uLiCggK7AOeWlbsKBR6Ojg9y86q05c0bPZJJpGXFxdaE wVQKhWp1SLEnEobPHU9np9vpmVnFxcGe1QMT4jQw9tQ9ffv2hUbwxIkTV69ezee/6qJ5HLlc/umn n2ZkZPj5+fF4PKjBjo6OUICxzEjwmr9QOGhcgHGaDXqDQW/agwV/jb/v9CC3EGpnqUxuMBnpVKrZ YtGbjJRK0WYpVbv8UGI1Or11zJRICPPxZtFo4T7ep27f2XM+js2gyzWaQdFR3gEBUICh+kIjODg4 GO5VLJHeTEv3dxU9zC+o1h4UvHEWsFIul4rFTBaLzeGYmWOPpPIAACAASURBVKxqHRAoyCw67cj1 BLFSxWMx4QWi2LzbTGYzrMlh0JUarW3OHiWTSKhtOAH2YeDDSsjhiAS4NtQx1tEdCgVqw+jRo9et W7do0aJly5ZBQ62x29WMkUql7777rkwm8/HxsasvfIXbWGCsF4rCAXABxmkWQHGVqdQnEm4MaHvc VoB0DJnmxGOLlUr4g6cTqfqaUnJWAyqBoSIAEJQKg8kE/6JbBMBtPot19MbNPXGXA3v1uX7jhkGr 3bJ164QJE+C99OfZ8zqj0YXPszxp775xBjDQqNUqhUKr1RqNJswpuloFHxfnqympf52/yKYzau+M BZV4eOeOviIXBFj9uuDDDPemfnWw7PHQLIMKMXXq1F27dk2ZMgXawVAzXjTrFw78tUOrd9asWQqF IiAgACquk5OTiw1sIJpOp9d+6tcOLsA4TRq1Tn83M6tEJruVntHSs5jLVMJCjc7t+kPUgtZNHAwo w/D4UQH+UAagmfvhoiXpKcnF6enxN2/6+fsXSSTDu3SSqzWw2hO7vnEKbDIa9Hq9yWi0WI1X9MlB eAaV2iW0ZYlU1i08FJq/9sVaoOJiYc8nbJAOISAEgJCIxNSCgoT0zBup6VDTyxRy2CtiUqlQP+BB GvTrvXZgRjA0zsxm83vvvXf27Nnx48f36tVr1KhRUIYbu3XNhrKysp07dx46dAj+kqH68vl8KLqu Npydne1xoV/U/AW4AOM0ZfZcjMstKdMaDH4il2GdOzrx1mPlRdLOFrTu10tAJQjycPdydCADlM5k /30twTU7TyQQAJtI1/npmiNm20Jn21LgGsxfDHgZhRx2emHR43wPTwiw/SPEJsbwuQX/iR25HFeB ILO4OCE9Q8Bi3c7MSszKhuV9IluRnwjnhFMb7DPB8B8LajCUXh8fnwsXLsCNMWPGTJ48GSpHY7ex SQMv2vbt23/99VcorlBuoeELjV3Yd4G6KxKJoPkrFAorz/6+6PHxnzVOU6RYKj1+81ZSdm6Qh1uH 4GAuk5Gcl+XMu2z7ECmV1XFCUztQCVgMRo/27Ut8ih7kFRSJJRQSKaOomMNooLSjTR0L+igcxzNr QTsAs3yf/OhRUcVHWDUspVJ+uRj+wQsO/8WduBzY9bmfk3srPSOjqCjA1bVLWCidSsEXGb8o9oFo qBxYzlq4ER4efurUqX379nXv3r1bt27Y+hkWi4VFW3wzB6itTgkmk9FoVCgUUqm0tLQ0Li5u9+7d 8IJ4eHhg1wdeOqi4ThXAQg6Hg6nvSyQDBrgA4zRBoPH075VrLDptTM9urkJoEpVkFBczaXkMWhH8 VGcQqLR1EP/52Ti7iBycnMtlco3BQGzM6ATWyFMI4SUfiBZ1cVK2OTTErYG/AOUVDFaDyVQgFsM/ Kpkc6e9XplBIFIqTt+5klZRGB/hFB7aow3a+IWBLkrBtxLZ+DL6F4pGXl5eamgrNO6g9UFqgJUel UjGRbtwGNwpYSDto8spkMqi+YrEYXpPg4GAosbBfgqkvvGgONuAGtIaxLos9McNLnBQXYJwmBLwH jt28dexmQq9WEd3Dw9IKi65b5wWt5hGLlk0lW6MNKzX+JktDjJtB3XV+ZddcbdHVoLbrjyftCOaC 8mtrJmxUbf1tIY9c23s15/LuwQOmZoOABSu/mvS//lzqi93k2Sd+HPO95njcOlEzXJerNxrhny3U Ja9tIFWuVu88d2FvXPyQDjEdWwY3duuaE5imYi5CmEEMhRaKB1RckUgks6FUKrVarV6vNxgMZhtY mNXGbnuDYr9QXl5e/v7+FAoFXigGg8FkMqEM82zw+Xz4Ci+dPfLzS6svwAUYp+mg1RtSCwpupqYN jmkX4O6akJ6h0ukqPkRZ9BwyUQHvEYXWz2yhNWZDXwBL4ok/y0v+/Pf6t8G9Xc78vCYxJ7K4XMsT VRnQRo1aPUqhUWowc8WyPHVEj8UDwo78sfDapRMbN/7sUGOiJtSikEmMCE3IY1U5vcmg19X20WAz tZui6QNlgEWnMek029AoevjqjbSCon5tIp34PHw8upbYpRdabPAyQmnB8gdALVEoFFB9VSoVFGCd TgcF2GQymStCfzd2wxsUbAmvdaEikYh1U+g24IWCigs1GL7CjguUXiwxA+Z19Soe+7gA4zQJxArl 8YRb93PyYoJacFnMpOxcc6Wc4QTExGUmIwh8JlCgBYyizWSOyqJPu6cwmcDly2nmGN22IzmFrj7F KnUQSkm/efK7X/40kYJnfjHZMW3tor9N4Xz1JUbEb1987Ex/rIJ8B+932qHjZs77ZNTg//3vk9h0 1UchLGXuteUzVySznQePm/Vhl4CsW2eW/Lg5L7/It/f4zV/+71rs+t92n/LrN2fuGOtMOQFxlibu +eIMY9P8QQR15ruj5yz5fZvy3I7Ve855BrWZu2A2rTT9wolUjerIwRTm1AWLege5NN71ehbwIYct BoN2x630zFKZrF90VJh3vU9GvDZgg892gcE0GCoK1GCNRqO1gVnAmACjFTR2wxuOygIM7WB4iWg2 4IWCoouJMZb3l2jjhWJu1AguwDiNj9Fk2hcXn5KXN3/YuwVisT3bgR0CYuQyUuCGyUJXaAMao40v g0mrvFSQT2LQi89dyuzudkLXpqc/p1yqKr57aWSn6T2WLShZtGR3cNRYfsmuP3eWD+kLjm2aRXfb vuAtkm3lDnwSlBY+yDDR9DqdXqFSqzUaC2KUPhwwYnx65MdfeyTOHfRZTPLPSz+brIqY9MW7wsO3 Ssvil3f+5M8RgzqumvE2x+lOf6AmB3QQkKlnVy25/cnbwiuHDh0jfXhi78KJ++ftnHN03aQfj3YZ Rj42YvZq1rCpQywn0rKmN1kBxoDmBofB6BYempKX/2vs0bnvDvZ0cnyVKec3Dcxiw7yjocZAdYEm HRRdTHqNNjD1feRt98YIMCaldgHGNBiTYQzsLWb1vqLhawf/4eI0Pqdv34W3/qdDB+eUlpUrFE9W oFGLmbRCYPXQ4TaAB1ZdoRYXFBQ6HTmzZcHHy7ZsdAqd/91A6r8Ps3K0V75tMXvpklkfHjfEpYk8 CHppm0Fr9v41wXDzu7G/XD+xJftKVo7BYB4wbhbVZIzbt2vY9dikO6mRH381KoSZfylODLgTPZUX 44v7Tv5IxKS6MHk3Ht684N7j46kfnpzrNGbasV8X9r3il/H33dy3vK3NELTsOLJ16YbdF7wuner+ y7Kyh8td3w7MunJIyouaHOEFHpA6Dpv17+aleVc7KZm8Rr5ktSbIw51OoW49cdrDyWFIhxgXPMhi rcFMYUxFsIFWzOSFwA2LjTfQ/MWwG8H260OswF5Yh1FicAHGaUxUWu2ZO4nn7t4b2rF9dkmpQqOp sZoLLw5BrFkQJIqI5jMBDMrzH4i5zq1COweCtA0HTRvudnE4H7fhdgrIzhH09qeSrHGfLMACAJFk YJFIiJmAoAjJq1Uk1asFmUwIcObk3qd06Nw7Uii5cCPRiU3mEECpyWxKz8gsZ4/98vvoQHcLkTFr 5ba0nOx/dm/4nUINKwTk4f40AiBbqMA+kk0WTpk3Jux/EykuoZe2RBybmZuRrxn+3tSfZkQ6sVhp D6jBPt5MOjm8x5DmlV3Cw1HozOclZefsOH2uU0hwB9wz60WwyzBUWbjxOLP1myq9diqbwvbXenIO xwUYpzFJSM+Af+2CA3U2l9enVXMRnMU2iqVdG6ppdUBJXpIo0JVBc+vSo+PflzwHBFBLc7yS18cN G9zl0plTN2JMpy/e1rS9bXTnZD1Ytmmj5PDEZb6zDwZHtwu3H4FKC4zuM2/GkFFDdnw8YWpfRuDW /nxHoSiiQ4QTUbKg46hz/Wd8RFK1eSva1cnhgdIQ3sX1rzWrLzC7T16VNO2wP00utB0G8ew++S3V T+a+swOZxPuR7T305H6dW8f//eWitcrlq2KQiiAZzWuRLXwg0iiEqAC/lLz8U7fvigQCHxfnxm5U M8MuLVViltW4gPu1luQnf/p2Ga7x07oCF2CcRqNYKr10P7lXqwiNXv8M9aWSy3nMVGCNGMwQKyMb sIGviotfm3eYAhIB6TL207W9OFx4v4XGvNs9P2LcCOnPm3f8cYjf5j1XLz5q1JsNrNSUvLaLt8yc 17tyBolWATEiBoWIgADfLju/nPsHwhIB/oZ5g/66HFuQyA2fuGhmvzD6rn0Hz58pIgbPJppbfZ7w CfjFOT55zLrdH7Z3ZW7ynjQ8xOqx9svBOTt+Ubv2BF9/3W/GZ3LC3w4bNz5APVbvHBl9cjehR2tr 3/6PP8DYsY1zpV4B+HD0dXHJLSuPvXZjfL8+dDwT4ktR30qDUyPI692vwWmy6AyG7/bsD3ATuTs6 qLS6Z9R0FZyKClgIrCkI211N+aWhGvh80h7cJ8hls2bNeloF1GK2oAiR+Mi8sD7dUItOb6LQKNYY dxaURCJaLJaH28Z8uCPw+OkvBVaprYrBABYuBDNngunTgYsL2LABTJ4MiostW7cSvvsO3LkD1q4F R4+CAwdMq1aT7iWC778HP6wEOj344QfrXp6e4KefQO/eICYGXbMGuLkj06eB5cutR4YHPHgQXLsG Zs9Gk5KQAwfA339bT/F0zp8/P3bcJ8EREf5BQZ5+fk4uIjaHQ24agmdB0cSs7OgA/75tmlMXDecN B7eAcRqBjKLinWcvUMikYA/3IqnsmXVRAfsOtlWmaNMAbatDkIqE9Y8NC4RAo9kUy5rNHvs/kcwm +HpFc59UXwiUNyilI0eCf/6xvu3eHZw7B/9PGDgQxMZaS8aPB5s2gblzSbNnW7V20iSwYgVYsAAM Hmy1aHv1At7e4NIlKMAILCwutr4dM8a6Y2goSEkBo0YBf38kP/+56tvEISCIp6PDiYTbqQWFn/Tt zaDWuFwa5zngM8HVQCqwzwTX8fHxS4zT8Px3/aZSq/N3dSmRyS2V1vs+CYmoig6Y58C9abbQrj9c Xa6IbrBGPpfnWsC1xKjIzyijB/oJm/jwX1O2gIFNPIql0pS8gj6RrfpEtcajRr8QmPMz5ghtd4p+ k2UY01rM7RmLy4FRt0qMW8A4DY1Crb6Vkdk1LKRcoXi2+kLolFI6tQRY8xK6aw2vp4sNmeMexGns RjR/4DNRJBAwabR7WdmdQluyaM3GW75xwUxeKLrYamAIFg/LviD4GZ5Zryt29cWkl0wmU6lUGo1G tYHJcJ04ReMCjNOgwK718r0H/FxFFgtqNJmfW59OKaFRyuCGSudpMOJrPXGeA5VM1hgMP/x9cO67 Q9gMemM3p6mDpQCCcqvVajUajdIG3LDHpHzTwnHYqRwSC0ovk8nEomfDDQaDAQvrJG0ULsA4Dcrd zGwLQDuFBGcUl9SmPpeZQiToUEBQavyMZtbzd8B5s6GQyaHeXolZ2Sdv3X63U4fGbk6TBhtzhiav SqWSy+UymUwikVROzGAX4MZuaSNQWYCxbEg8Hk8gEPD5fC6XC9/SbEMsr6jBuADjNBwKjebYzYR3 YtqmFxXX8q4WsG8DqzsxSa4Osmdzx7FiDVaJX5DqILZkiJH+fgmp6THBgW5CYWO3qOkCxRVTX6i7 ZWVlpaWl8FUqlUIBxizgNzMlA4bd98oesBMKMHZlYL8EXpPK/lkvfRZcgHEajvgHKUI222Ay1/KW JiAGHusBsC4yISk0eCLYx8ju3tXm5zv37k1oMj5QTQoCgkDpyC0txwX4aUBlNRqN0NLF0t8WFhaW lJRAAYZvNRpNNfP3DdRgu75ic8DQCMbUF140eFnsccTs1V7uLLgA4zQcdzIyQ7w8tQZDLesL2Hco JGtoaIXGV2dwrM+mNSdKz51LnD/fpNGEaLUe773X2M1povi4OJ9MuA1NYSoZf8pVBwoqNvgMRUUs FhcXF2MCDLfVajVm5L3J6otRWYOxeXHMMQ0rwdIz4PmAcZoHdzOzJUoVh8FQarW13MVVeBrbKJZ2 R0FTTFUrlUqzs7Mb8owmpTJp6VJiQQHcvjNrlhlFiW3bmhvkEQkf00QSkUQmEWDfH6nLkPT1gZDD zi0r23Xu/Md9ejV2W5ocUFOhlqhUqry8vPj4+MuXLxcUFMC3UHcbu2mNBvw9Y1l+4QaTycQ2sHJ4 WeDlwjol8K09mzJ8xVITvrQRjAswTkNgtlju5+SKBHzz89Yd2SEQ9I7cq3ADBUjTDAHNFQgvnjo1 YcZMhUwml8vUCoVOq8XuUlBNEFGUoDYjpselKAGxsIiA8DI3rROROIZGjUBRBEWvzJixU6eDl8lc bYIcnlFlRsyVzkhELMyXPCOEQCSQKRQPHx8Gg0mhUonWlRh1H5egDoGGiROXm1FUrNJqWfS6codG tVoDlU6toTNoNmiMBAateTxR4U+0vLx827Zt0Or19/dfuHAhfOXz+aQ3OLEj7JQoFIr8/PwrV67E xcVdunTJyckJSqw9OAmmvvASMRgMLI8yh8OBMkylUrEp4Zc46Zt7uXEaktT8wlsZmSO6dCx+Ttyr x3DoaVSytbJa66HWedRn614SvkAwdPQYcVlpUX5+cUFBaXGRQiY36LQmsxlYqigwUWygKHXALssI MLrSTM7Ul/YqO4qiZJk0BEoLgTCWwXDkcu8wq7uIE8sNlFzd45ZYgJFNM4leMkQUkUxiMJkCBwcO n8+w2QcEArGJe4G5CgUp+fmn7yS+E9O2DvoKqCnxxNpxc38es+HajM5O+fevHTt/gyxo0X9oXyeq 6dyPo8ZvSf5135m3wpt6QDGoFunp6RMnThw/fvzMmTO5XG5T7kg1GPAicG20bNly5MiRiYmJEyZM IBAImL5i4/A6nU6thj1thVwuh68ajQZzVXvpjgsuwDgNQV55eb82rWVqde134bPuI4h1QEyijGia /s/W7jCZRKczuHy+2WQikck8vgrekKi58pAwSio2MO9IEctj9TX4MjRRnJc2RjGS9HrH1IdOUgkN gKFyOd/JOcfZ2UKotCjCD6VTldQ0NcAGHVCAFiMaP54RavCLP3AJJAKNRmdzuXyhkM3hUGk0aAQ3 8Qc3mUTqFNIyr6xcZzS+epIGSe7Vzz+dmyr25DG1u78e/NHSWDLHwaxRaEe1v5wXS6PSFTkPFnz2 WeBfm7yFTTcGCBSSjIwMKC3z588fMGBAYzenKYINQbdv337jxo3wQkFJJpPJsBBbtYWtmYYybJ8V fhVHcVyAceodo8mUnJvfoWVg7c1fAmLiMh8SrEOoiFQV/vwdGgPEmq+bTGcyeRbYBSaz2Gy9Xg+V GN6OALshUUDJ0HBvlBJMTGwXFAHa1hxlXyGg1MGUdpa/H/nqFX5GBpTBTrk5zk5OZUGBVWr4o6zT YsZ1BYK1xwzQawT52476UNaLdmkQhECm2qa+WGwWl0Oj00lNXoAhTBrtYV6BQq15ZQFWH/h29tHS gJ+27HpbWDZ6T2y39z8dP2bAvW3Lv95z+sjlnKVTft2pA8Pmn9h67PY3o9vXTevrAalUunbt2pUr V8bExDR2W5o68BItWLBg4cKFbm5u2JRw5ZBh1eKFvdwpcAHGqXdMFguDSpGpXsD8JZNkTFouFCyD ka/Seddb014JbI0gSqdbx6loNA6Pa50ANlvsQ81EsdHhQjZZ7WiXKV0LpnisB59HftoxXxSFjw91 7x5GWhpFrw++dlXo460JDavSSDcvHlrIuC5/1AY9MF6giMNdjD6MFzoRYkstAb8vxRaUj1zhe1JX X6T+0Oj1co3Gmc97lYOYixOmb7vZbsgnI3q24jMIe69KyXQ22SS+87s1jaYjl42QON2mLO/3184V 649+Prp9kw3B9cUXX/Ts2bNdu3aN3ZBmAPx5jxo1CoruN998AzUY+7VjGmy0gTl82IOFvcTtgAsw Tr1zMP4KfH0hT10qWcqgFgJr1kInrb6JhoDG1uBjbpDwtfKtCD8lSo1OO3JoefBR/OhpbBJRSqb7 8nzr9OHs4GgaN960ayfpXiLBZHLetUvzv7FGaNyQKzTeAZAnCHiKbGqK5lFJOXDYrStdIDI5vYBR aIs4gNhCAz0CITR1R2gMbxcnje5Z+S5rg7IwU49wWgb1FzLJ8EuzmJQHl/9Z+9OPmw4lRfWYPCjG HdYh0x1b9Ri096c7+ToQ0CQHoc+fP19UVDR06NBm8Q/XFIAXasCAAfv27ZNIJBTbIAp2g5sreG40 +2eDCzBO/WIymxMzszuGBFtdk2oNk5ZDJUvgBlRfvbHpxlIg2HSISCKhFTcnVk6UGR1/z2bdhl/5 kaFpdKUWfRdADWDUfZ48LheZORNs2wYuxyMoyji430Imgbf6VqoAdF+xeV+kU7MqFoClAM7qspJv /F9Mg63/PU7b3lwe4vDfJLuktJWf76scRJqXD0gkmoMDEQGoWXfq15Uzv1lWQHL57IcN0ycM9+BY p94RAtFT4M4A+0oUpoCm5w4NLbY///xz9erVrx7B+I2Cx+P16tVr+/btlQW4Gi998Cb3K8F5zYh/ kKI3GYVstkSlqv1eQs5tBLF2LaXqEAtaZwO29cGTaoSYUN7Bcs4lBVKxdtnCIEqneZuD2PX15BMI wSfjgVwGkpIQpZK4ZTMQCEDM45lIiw9L8oW/6LNU2DPASsj3FGtGzUpxFDu5iBxdXBxFIif45+IC 3wqgzLxGy1GoZPKFe/cHd3jlKU8igrCs/8zq0pxNO39NkcScSDvax5/9uAKKmvRqCwhxZDXFq5ef nw+1xN/fv7Eb0swgEAhRUVFQgO0l9vgkrx6ipCn+UHBeJ4wmU6jnC0S/wnDg3MQ2JIrIemhUfWJG OQdL+LuK7G7PKAmRfCjSdKnnVE5cLpg6Dfy6Dmqw1ehb8xMYrwZdu4EKKdX5Eku6FoiOOiNGa8Oo gLTK9GFOe2Zuf4ZSpVDK5Qq57P6dO1dlFzRqlXW6l/IIsvWPSra+UGk0OpVOo9MZNAYdbtMYDPgG /pHJTbeTJGCz6NRXdYGmcKjAaFAVFRssQKcuExeXA1fO2e3LDktVBJZwwAdT+oQ5A4s5XyHWATah SVqYhYWFPj4+NX+GGsCNS0DYCvgJqpTLikFCAegeVTUKDgqKskABAto8cbSsFGDmAn/Ry7bRUFSa KTVaHHg+TswqMzWFxQklKCfCxR9L86yUpz8U55kQXpB7OI9c5XKjZl164W2iMNqXUUXdzCZtclGK myicT6pS32SUPSjK9REFs5/+G4bXjUqt+6Er0HgCbB1DJxCahxMHzktjMpvzyspRBOheRICZ1HyW 1QML7k6XaYLqrXX1AAo4h0uFG/IIuoqZIQSIJ7rLR7hAGa73szu7gDmfgQ3rwfVrAF7wHTsAkQS6 dXv0aewhzYP/SkfNdNoJsAAdVCMx4JCB7+QkHxVQ2SkaC5Nk1OutTp62P8OjV71GrdaoVGVFxWqV Em5ArBtqNQEh8ARCvlDAE1T8CYV8gZDFZiN1kTb1VbA+ZFCgNxqpr9BLcGnVPco4/3rciRLZ2wKG gOfsChIenDhSCIBWceehY6shUID1qsz4fXGg51z3JhmfW6FQODrWFM/VqAGbloDl28CHu8DSPo/L y1PBF3PBQRYo/AtU/kYFt8H/RgPt++Dy4irHufcveP8zMHkpmDb8JZpn1hfvODXjojhHbUa5LM+h 7db283J71EDZpYXHpxp57296ex6dRCzLOfxV/PICpdiCMAJc35rVa5lnpQH/uKRffru5vWfveF9P 7uOjWxRH4xftSMuaP3JPG9Jj90OTNnfjiU/OSty+GrwqTPDUqS4HB4dnxwirOycsVLppyQ+Rn3wR 5VGPqd/MmtKFM7/sMvvb/i2b+qJ1nFdBqlIVSSRvtYkqFItrv5cTLw5BrBPGJbLOFku9dDzrCfoN uXBTAUFbob4ERP6Oo3ykqCHUFwPawZ+Mh7YauH0bKBXgl7UA6l90NPj3ENi3F36u1MWRxg4XbC/E wnIheovwjwKLkKx8y8GuwViwPQiz1qeFGiwuKxOXlkrKykqKih7cvSsuLSsvK9VpNGwulyfg84UO j7VZIODyBRQqhUgkEYjQ2CZhXl2Yg1d9dMrhV5Wp1K/iCE3kt1n0ZfsRSzev3NppxYzRB28WVKug laf+NHXwSalp5dy+9CZpVsAOFJZBrzrXz4DFm4BYBpCqveT/s3cVgFEcXfjt7bl73IlAEiDF3V2K S5FSHEqhFNpSnBYrxYoVlx9pKQ4tlFLcXQIhgSTE/S53l3Pbf/YuQAgBEpJASvP1ukz2dmdn9nbn m/fmydZpsPcsqOvBC8YbKqjRGgxGqPbiilLmJej4OaiVSKJ8fTPsNqPOSuEV1knYbt5d+2dmTNta 6zq7W6fv7Xs2Zn8Try+4FCS5Zqw4NDbdmCe0GglythC/9MYSpb3u0gEL+Kp/Rv759eHItmPqtHJK taasPYuvrDfZ9S8GwoHUyPnrYo7ZbDKLreAXhiMnJx/LijMA3wavs6VC4q+TgMs8LPZLBGzJOrJp n6zbl+VKwGa9XpOeBRUyum8lyhA2O8FhMXO1eSU5iXARXXSW0pUty6NV5QR6gkH6cyKufD4A6eoL cj/zeHfs64RUCqPHwqaNcP0aqYveuB7OnYXIe/nfXrmsmduXliHh/5nj3EHJs4nXp1hd6IYI/ltf k83hoI+Xr2+h/TarFXGzjhSUHbJynhb9kZ2ZiaTnIs1HyWSCTCaHy3V8eBwel80hy2wer2jyKB4Q p5feE6nN+M2Tb3+67Lsh/nXbTGrq/uKX1rPLhs/4PaHv18uGNqmgbuuvJI/qjeDodqjXBbgveqb1 mgqCAJh898WjeXDsIPy6Ge69SBDiMNi+H06teGOMF2XSvrl3I0c2/a6auICECnhI4OAZvmNryOU2 Y5IrOQ1jUzAg7OYLd1efMnn3rNHwaqoJHZed+yBbRf+u75IALhW4Xb+tumOP5qrB1pKLk9dliFrM brps2735lBej3Ih8B02iNTx8bfmLjWM2qT1DqLy0t0HmbQAAIABJREFU4vJ5HHs/ywZFqKAJwOxl EHjInhEfC7IqYqpOqbPKpaJnZEsqnzEysiwqG1WZx87db9e1Vcl8EivxLwESfI1ms9FUAv0zg6bg sRLAoX9W5EWUV8vKGtQss+u3j+iJz91dTH6srCm+tpKYGZcZZDIYPQaNXnD9Omi1cOvm868sFlv0 TcXnHdB0gfkg3zOblmaSfx+XtiLE4lXG/qs4lYokYPQptN/pyGF1eFKS26cFMkGeTqdRqzRqdVZ6 Oto6F6fRFp3i0HJLxVKJWCoVSaXkViLlC4XFMeu12EqbZoAtDZqydU+3x6leodKXO9pwxJqzHYwh 1cIknAqpgH4NeGKIcEwaQrxf2O9bA/h7wUp7UVDCoU4jOPsHYC8ac9H40LwuHNOA9Q0yokAaDmmT F50xTWo1M1zw3DCCL/KvgWRSXdLqs5PvEvRPfVqzMNDm3dlze1fTur83EsdcS41Bh+UaMnPxmkFP zdzkLjWtSc5AVA7OokmruvnS75hs1hemd2xBaA27Yb/FQnuBmDGpa3h1RrqYG8Onvh+/sSIJuLA0 nhp9fmqP4ceUarF74Jw1O/rW99YkxxzZtWH9X1cI3Gfo5CmftA3Ne3j5668+O3hLLXKPmL18/YAm rFktWzzuNsx4YXdUzKPRSy/OHd5Ql3Z/1phxuy9E2gOrSlR5nXCKKunOmm8WBrVuFVrJwB8itEZj NW+vEmlt+Ow4Kk56rKq0oTbbv+OxIANuLEkoyL4WT2bm3Co2+fvTnwuFMHAwPEmAnOzCX926aWvd Jm1xsMf4aEas3hk1hJZudpkTnzG3itX1XbTZGdS+RBF0jQZDrkJBfnKylTk5D+7cUeZkqxRKrUaD hG+eENG8kC8Q8B18j8o8AZ/JdITrwvG83NxcpVIjFJKBRBx+22/XaK7Uq7a0yLDkGN8jrLHH29Ra IZD1hNzSC62RE2AjoF4dKPRE2GyQkwSMukXUozJBtcIWWIRVHa9Kdpa5nCAXXvVFn52csbv1lztS Noza4//sESAsmTkXlx77Ip7g9Wt+sk+QD2HN2vznZ7G0en2lkJoVqzNnxOckmu1WOp3//LmxF5YV bVa9zcqvJuEV2o8RNqAGeNELP3Ka7HsqCpndq4julD+K8wLoV06Zqmv02W+DwlbPmLhi35Xuocwl E4b+bQ0fNnmW4fLOzzp82yB1+cpx4xTVP908xm/BhEk/fnXk42u90Fz69OZ1vSfOGNZi647D/2j7 +83/pMc1r94bd019fHTXkiM5ngKGVFB33vbF/v+OYbYSbwOj2cIsSRRAHisOp5Duqg4HpH+Dlb6N EK9L5lx6HmXTJqTmfOFt9nuv0ZDQKHnxArkM/DJSUiA11R5QJfsrX9fZsdTMfP0E46FOsjo5a1bA u9aZFw9MFsvN0xN9Cu232+1GPYJOr9MZdHoDWdCrFIr05CSzxWJHcrbVmpiZZXkSK+JwUBlJ3gwG QyQSicVikQPOAtpyudz/qlmoY5nX90VDfcIKqVrAXn6MCfL4oJfVAAhMYBS2HLDq7v9ychVQaXSM Vv+j+Z3d8eM3N2bYPZuFdpMWYL3cjNPTDw9neH05p/7gamKycpsuPgkLCaAZdp2eobOk5RjS5xxl TWxan6a9qLSDi+Pc1JQbVLzWS7+aSEAvPMcyWpS59iJXeq1uPB7rPSWNfvmqL80NdbEnb+s7j87r 2XWAXhi0cVHD3PQHJy5yF12Y1yRQfEPxK5o4Jd07f/mRdcRI6bJPx9zWumz8tQfPcUOqh/Ve9u3Y 3K3/7IymmjJu/XIra///prXxYSsC+Sej56IbSGXx69ap+Q76WYn3AowAs9VafAKmUMx8diyG2Wx2 uloXTBAV0p+jIAhCujxR8EfOs6RDBAZZU/11TUTvOX/Ent9h314oMviJUgkx0VClirEmL3OGv/v4 aIfHNWkazTupAApkzg6o4GmOCoJCobC5XPR5+StnGjmLzXYt+lHfpo1CPD2c8fTVanWqAykpKVeu XEl9CoPB4Orq6u3t7fUUnp6eaOvu7l6R/azKABQHEaRroWoBOwCMBu6F5UjHfow8PrmouR2N+TKB 0Pj15/eo7QzjgmOmzf+M3ht/sVfj3weG1mY+J2BrbPKpFFu3be0mSDCwImEVByq/7oKeOwlHGpHH Kb/9dDN2WadpNN0DKevexpuPptUJMitPL4iN7FhrLAsv4IWPLoLhLzeDQZOJ8CIIj4bTlHq1CV2S 8R44uPAljakPLuKUsflW3YTNascpVkpSzN79/HbTVywc0p1t1GTFZ+Z4SmVCpt2ivXItG5p3lNHJ fK9Llx7o+dWaXRN7cU0KtTov3W4PGDrEnU3R0Fl5pvg8cw0rqtBMjghoWHaODCZV8oYNh3pOHOf2 bxB1KlFiOLi0+IdTKQZEwKhgtoj1psKyzmuAJJsbFy84syA4veQLZ+QtHzBidMIDz11+gTS8EuZZ tHCqeOdj4OXn5+ru4Yxq6QzuWFIhLDEuLj0l+VlYADSm+cc+lh879soTCMJy5vR1JsvZaG4zBfe0 Mv8r9FsdBzU70lD77Q2yiguMXCH+qH4DirPz5RDYkryVOE51JK1iMpkcTr5wJhQKfXx8Xj7eZDLl 5ORkO5CVlZWRkREZGYnKubm5dDodycccB7hPgcrsAmCxWM8K9FInX3p3iL0EEyeQha8Gwfr1IEuE Aykwsj8cmAMztkEiQH8trP8B/lgEigAY0Qm+7geHroDlLKQrYFUfWLwA3NpCJxkM/RIO/Q1HrgDl FPQMeF4/htOfu+ri7UPHR0SsriUvZBCHUXA0xfln1JZ6VrsRJ+xVq0yd3mIgh5a/NEsjjaSoLBqD LQ5tF9hxzfVWk9J6qhT/yKVNm1Wph9sVO06v8AseVIebPvHw13H6J3O21h3c6kgnedaqCwea1fnK VfHrpIubMvRZI7f1mt57pyFx1yWNbFzjzjcvz1n5cF+O2TRxP331wDmydz7tLMx7dpuJSQOGRRl9 6+H1SxcuXMmZtnaM1I0ia9nt60514s9tXbV2X6evZ3hbI38/fDKMEbvk4BWo3lUs8+Kh/5v16NGt +sN/dqzYfqzjJwOu2K0DxSLUI5eQ6nrjeQvLs7nBsGH5Ys7ANlf2zL2diJkIwqpXnzxwvOGYcW7l aHNdifcIwlaSWKlUXMthojceTFahwVQCd36DTnfuyOFhw4aVuIGlhDtAi4CCO0pkaJuUlHTx5Mn2 3bpTaTT0QSB5qIQrlCcOH2pap7ZEku/FSMOwYB9vtp9f5vHj2idPoEhj49hYjzw1N9iROmmwKwx+ 4dtS2QqXBJ+PG7d2zz5nx8nFWgcNl8uVCDKZxBuPYjAYHg4U2o/kZiQca51+z6RNd34BQalUGo1G Z24c59YJ1COxWCxxQOqAsywQCMqrj28NoTt8MgF6ktFGwFMCmvuQlUWu/tZoBbMdllbSKsCgkOu+ GRywU6FlH/jI4enrUQu935CRDhQNMEOg9yDo1p/cX71I7bQTuKdnvaJm1hR//z6TOGGAi1k4A0cc zPKiFfjFXCT1B9esSke3jsJuU+trDi8wUZtH9Z4c5tUtVMwFm1apTZeajRSGV88GE52nBEp4dltS ljZFa7FypbUGN3DOKVkeTOyOISdLg9uA4unVYqjYYYCGeRff6a4M8ZLgabNkxD1sXSPfwi2k2dDZ TL956yZ3H/rltkXknh6Tf+ndummViV17jOtj58sb8OS+bet6h4etXDi9ZtfRR5aQx3T6ek23dvXP Uul6nHzU2EJBikKfbvX+/eGRds3aN13zPZMMT+ubnKuPqBb6+9kDH7Z2578MNPbbS+I5J+HfpOLk AnCeIcBsLWw6+yqQikaCqFKlypAhQ96ike8Rd+7cubFgoSInG8lOLA6HcEhOJU1ygO5vz549fV9y Aao6ZUr22bOPV65UXr8OL/4KSChsbDLVfN+3a+znn+cqclhs0oUJmExq+QwEWkSeZjOH9fZmrogy nbKvi0ux8oKgB1Kj0SQ5kJiYGBUVlegA+hMJ025ubj4OeHt7+zyFp6dnafysSgWpL/Qf8vxP949h oaNQvQUU9Kj6Yn1+oVuBgxGWbsovDBhYikZgIlF4a1H4q74W8YJaP1WHU2jixqFDGxf8Gncd/3F+ 89qF+Bb4os68XnUchY/aiZ/H1GtXf1o7R4Hr1brg0e8ehQmYHdD5wrGDajtLLPfw8XWXiYVUCrh1 mfnwyXiFWsfiCYU8DgWDZkPmpfWdajLqFg/vd5+NXhtqjS7jLfrBWbl6Jk8g5qHJhP2X6zcoPPJ5 ZYZ9enN3aw8/IYva7tRjlTLPJBBLqJidRtpAYrT3tPpdiXcAjCjZYqKr6JyzkK2qU/yzSAJ+bZya igyVUpmenCwQi4V2OxmVgooXtVD1ShDPcg+/BCRJy1u2lDVrpo2NzTh+XHH5svrBA/PTiChojzEj g+n6PiPhIMkyMy1N6IhAhPruDMRR5lfRGAxeMqlcWNz5XOmB5k9I0g13oNBXFosFcXBOTo7iKW7c uHH8+HG0E53FdMCR7/F5gc1mP9N4Fyygb/+rJmMfDl561amCRu0/fvk4Jlfowc1XTeWmRm7ZeogX UNXw5PwvJ/O2r8hXwVFZQnfWM/UVRSh7pkLkVAkLyq+HI3DPF/UrvH1NJUoNZ56CYh5MoZiehYBW aGoX/yqkU6m9BKmWKhRylYr0lBSr1Uql0tBwS6fRCRq9pBLwa4BomBccjD6+gwfrk5Kyz59PPXhQ Ex1t0+mQfOzVt28p218aoB8OETDqgCPHMINGo0M5CMEYYD4uclbFWJSl0WhyBwrtd4b/NL4Ip05b q9WqVKrU1FS1A6js3KJTpFKpq6srksvRFtXpLKCdlfmO/i14G+mTsKqv/rHxShqBCVzGrVvW3qNC pr6sRAWAwyyouCpoMfeu0wNYrQs2WgqPUK+H3fpvJeA8tTo7MwMxEA8JTRbh26QXLZ6SnyYUCtCn evWAUaMUV68+2bxZHRXlYTZT3h8zoc7mZGexORy+SGi18Ms8zp8TWSpVmI/3m497r3gW/pPPL675 m16vT09Hk7cUpwn3zZs3nXbdSqVSKBQ+4+Nn26SkJG/vin4f/mt4GwIW+zTedSHOZrNhGE6jVU61 KvFKEMVlBxLPxN9MVePXH/nSZYgSrTRXKBgNhjwNmc/AbDLbrDY7Uar83sUBRqVKGzWSNmxoUirf c6YEgtBp8gwGg8VssdlLm9v8VdDo9a6lC0JZMcFmswMcKLTf6WflCD2idG6zs7NjYmJu3bo1aNCg 99LUSrwKb7n+ipfPak0lPjBgxc7aTsHMIu59ZzlT1ajkl/q3ErDFYjEbjWhrc8SIeHcTCQxjSF6Z /uXdAPXVbDJZHOEyCHu59BzdUxGHK+L9h7ws0MgsdqAQNx88ePB9NakSr0IFM4ivxIeF4q8Bc5jJ TEYWKuiNHiVyQPq3gyBDQ1hJBiJl31daVH2oQIIvQUq+ZZDb/GUg9r0YFS0V8DiMymWySlREVFog V6IcgRXbBIvLSmBQyXAQGkMVm/29BnF8t8i3Yn5HgUMqGAjCZjEpcxQimYpLhrIizEYTuaxFo7FY zNIb+GbkqrTKrMCaHzEKRzmuRCUqBCoJuBLlCFtxM2gSXGYCjUpmGM3T+9ts/yEC/o9DnZp079LV v/FnkbCcaxZY/4W/fVynZIZ4hYAevOzMxydnzYq59aja5nUuVPNfBw/wq7dqHFIsX95KvIxbF064 hTV2E7LArj++dTOt5dCWvm8Tx9+kuLth03G2u094nUYRwZ7/ZRIqVt/1+tRHOU+MVpXOZLTYgc2S VJF/JKLiFtL3A8MpaMJKR7NWNH9NzIxl833k7HIJKmLQZURnRxO40ENUxaWo0K+VqGjACKBS32wr QKFYhNwoIBWSTI0+kCjzMMp2/dlDf4d16Cohg88SeTlpMUkZSOSk0hlsNtfD25tDI9di1DnpOWoD kyeWSwWWrMjfj1w1EZgkpG7HBuFsWhFNMuly88xUqYhnM6quXX1SvWkEx3GU3WqKunkrz87gcKik ehXHWQy23N1TxH0PyZG0ypTYRFVYjTAq2UVbanRkqtZKwXEGgy2SyNzkYhwDm9mQmZ5hIKhiqUzE ZT66efzczXg7lR/RtNVHAa74y10nrGkpOVIvVzp6K7MenrxOtOtYzXmH9Flxp65muHtwcZykQDQ0 MNhiPz+3V0mgbLHEg8rAqFRlZmpODqV6w3C6I6y29GnCG9LADjBKUaYEVrPBaME5LKrVYqHQGDgl /wSb1YrOydUb1GZbp6aN6dVDWZhNmf5w1TcD0rpsuby4H508uNKDtmQwRG2v1WTykl37vurfWBV7 eeL3s7WH2NEHh7JLfiPjT23/7qddYUFemd+M84gYtHrdjOqeojef9rbQp935es720T8tCudXOLul YhFwQsqfi84szrVqhewwNmZM0uf0rzM1R3k516h2ONBTGTReo9BRDSW2ZcfHYMKgcK8+HYKauHPL koa1mtidF+ccTbhIUCW+0tBRbTaGcv/LM6d/B3CckqVSi940W6JgVj77MZAGnKw8g3/Zt8OWveTT IROi0lt5ItmaiL1yZNryZbEJNiqDyeUIpmw83Ls6+9LO+T/uuJSu1HHcAsfOX1Er+n/fzU4ePcRj 9dzV9yf8MnVS/ZecdXQ7Zg1OCRwwbWQ/Q+bjRdN+nHNib3WH6G416Y7vXHPgZho1Nz2dx3MX6FQK twmzfxrSpYi8IxSdlR6vZ+eoBA+zxFyajKnn07h4sZOj2YFgPVC/5oCs2Mtbtt6au3wej47qNBz/ edLqmwkqFc5kcsJa9Vrx/Tdca9L6JQsOn3mgs1NdOo45Mv2T45vXXtYF+bJStvxy9pe9P9X0KRzC IvPRhW+++mHktr+aSmlpl7aO+lJ9K3ati+N1VMZdXzhzI41hUKkURg83sTnHaG1++PxKj6JfVozB Ezeo3cAnwCf6xIEDx62jfljkRrchxlUn39u243TtYOHlY+fzIGjwd59IqObEm5fOHDun4sprN2nf oJbrpV+3nn2QHBLun/Awni9vP/iLppgy+o/duxMzzTYC47o37NjZO5fPE9RsFb93wdzdF24kguno qk+zz/YYNLFPp+qV9i8lQsw/B9DTFJOeCNAoLfqhLldju3tbbQX2S3Mru92UmaFGk7tXZdXiu7uF Ne2wbvEMTfTFObPmDPnU9dSJb4Sv+D3sVoveaMSpDAaTDiatCVgsBjm5s5jMVDIUSdFn6VQZF89c EoU2qu0v1irSDh3YGDHmu6phouLIA+8SxeIwJs6g0NptG7ZS7mi83Way2XVnbhrisMSzcftk8vYU tUqlsxEidY72cZ7xcWTKn7tu1J3ZbWszeZmZWV64O+/3+JgpPW9FQNTSf7blWWyV+vMKC53RdDUm RqMzaI0GpUYTkwK+LnLGq2MscJgJbEYGKphtPK2xiCj5pYRNlfEPwLh8LxdKROfRxzsPntoimPf5 /i+7BLMYjKRj8xsNnHvofnrnUJkOsRNbkHZfLW/Yc+q8PpN7Lu8y69TECfULJRKNPThv+JI/2n1e x+E6ZCds7sKninM6RzxpxfZJANf2zt+TELRwci+KzQav8BqgmAiqyUzPMbAgjwO5XCB4YMCLbR1J AEEHw2sOyFWmPHq+DMAd+svJFhd+6z7j9JnT67hk9A/q3qnDjqaE7z5xTkKzqfXkLSI4nK49R/dt 5v7TN9/EpCpfJuDdK2ftPHouLFrZtLELYTZRsBDm05vj2aDfhdv97Jon3brPmHd0RzjNTnorvkFI wigUXMjk4HAyOdfk5UlqNVVP4s6uWrwv/4CjIf07upxav2jLXr3j75O7N0/feyz3/r3r529edwRP o/PvBrbyTJk5aW96tlACmlxwD6d/1V/Wdu+Bj1mdvKucOvCn47j4m3vikwJrD+nTqZg3uBJOmC6d RAQMdx5kAWG7FRmVpbFwuIdTcpe4yekWbfamH3pPWHpW7tdt877lEfQL7iELx39W8/jOA3VnbV73 TW9WISqmAINFF8s8q/sN2Myz1uu67H7upMYS64VfvmkydgVA2ILfdn3TNxy9A+q4c726f/pPZALH u8baXftoq2vtCPj1wA8dTFlXenddOH/fznAZbP5iwJcbDtNkXst2HPu0Tag+O27+l90X/BqJrjNi 7ZG8Pza2+uoQWY6Qjag1IOPcZhd2hQjJ4kSxZ4EYN198R+8yRqfRxG3qj+hZo62YJhnVZdnyAVt6 BDuCrtEazu19b2WbVc2ltgV72+yOuW9xnJSaeeXYvbULD3wy98xGjfWV3n6anL+XnPolzWgstF+v +PvXqGsDmy9t4yqUujacP3BdfREDCGNk3OEHWYnX4w4fidz2QKFCI2162sXj0buPR//5SKlyDjo6 XeLFx/vQzmspDw02u8WSvv/W7uiUa4furjv66LyhyHxtlXgroHE+Kin5z2s3fj934Vr040yVKjdP K+bxSEeT195nd/FJZyEzt3F5pCC06JQv76RyKDiLymQw0GOTmZQGEPLg/LH/7fszNttEp1HsViTI ZqcnPtr86yncTYi/+KLkPj4+YtJfvb/7Dk9J0pFzQQt4MsUvXcIKptw8BeJ9DH8TB5UbTJrsQnsw HDARg4wfS8aCNaTGKYw5+kO/7dx/6rrJRr40drNJm6eMj7xy6VEqi11ommt/8vfMDWeZY9vX2H/k piP+p44SLCm0aO+w505PzjIDotZiOaJhFHqhnOjkKFGjzbhZi6ZU8fdl6DOO/XOME1Rv9tbd/Ts1 oEBtdyHD6bhU++MR82cMRtegAcZ0wYAh8GwwovPnX3w8uFOwJ5kVgBkk6zTztDYnYVjbqiHDftGb U36Y1KxS/C0RbHmPtx+GKtVCHt26qzTr79y81n5Ib6nFlpmlBXPuvOF9lp0gFm/YWg+7cejsHcxK EULy5URN3d5drq2d//utlEK15cQ+MhnMypysmLtXdmzZpWEBBzOd3vRD25U3Jy9aN7kO9fsRTc6m mZT39zYLbS9qMfTsqfW+NJxDszyMJcDxqJmyYhWkBGb5e+mwn65gy3b8b3Az8Y+/bNWbbbtXfrPg PCza/sfq5T/w6Zzg5iN+mvmViMcZOmP1zunDBfSKJbYVqzUmu9FiOrb+nLvdkJBmSMTprgMb/Bgq 4tgJclwlh9bnso0dA2q1oF6+ng39To7ce31+qHy9n/H4tOOzDJSgcAH1TvZdjdnCpxa9GEZne2en zJh5NOe79lMCnqs2zBcuzqZK27X1r4fea6NJozHoAWdJmKYDF6bfB4HJaqcZn1QL8xjqkTjn/HIz NZRlirULgqd22laFmfXLkQFXjcwAtigqb9fk9ivq8FMPXpu+j8HKtrnwMZNYdqC+6D17Q34YuBT1 8ErMI5VWH+7jZbPbq/l4CTgcq82GPuY3BWp2FZ1xFjJym5dL44oabmk408NF4iAHvGb/GUdEte49 iPnrxNXZc6zfLlrtERX15ORfXTqtpAS2X/lzf7sqO1mnNRptAhcPKdO+ccOmK0mJEyyZey9Fx2mt Ia+4rEjqTdFnOYKEvL8Vx5f6TtjA18/7qfEMa8CPOwXHTsXF3N615ed58q7n905OvHPq0J8Pf8b1 DYbPbxQiz0lLyjNZzWa7R0AVyLjRd8xSK6uaTm+I3v2PYn7HIq+JM3lVGOZElR68iidtYBShjInm A88yBTlswwMHfDuwCq6XedZhECn7knVNF4z7KMg1g8HBQI9bdfEmHYBHp0ED5PG7LXZbphFvO32O dcuvR/7YmuDiWq2H7FdeGtkYBosCFDqdzaBRo2PSbDR6JfuWFNn3rlwB+HnqlN3fr7sYeeP6A9bM 3yeu23v6zuOUVqyY7Zezf/rtSPf6fvj1IwaJC1NirhPRfN76zbU8qVO/6HP5YUo7Qez0yd/HkUaW LhPmzJVn5Nw7dW5At5smjYIm8Pv5f79WY6innLnSrO9QScbRLXEJrT+bGyYlzi9elykfc3juN97M JwHYesJufPQoX5VjyMtIR/+Y0jcvO15r8JQ/d2+PitI0/bwxg4qmziYwqA9vXNx/zPfTP24oZOIT POSrNm5rNXDwJ0EVznKoWASsNWvNhO7Sky1k4k6qzI3CZTnUiY5BxWgqLNuQww2b7TGw3aKTm4fG 5qRSUn9PtsrGNJ3WzN3fZDK4sp6zr8miyjXmgSMqgJAlZbJDJrdZ9NWx0RN+3T/t4/MNpI77ZU3/ IzPDo2qH9NgdC28ui9Er7ISVzfKf1e03GwZ0htf8Dmvu/d3ugTlj24O9Gsn0lY1D9pz44oIpy0pA /O3F12zCL9usZCl2z770px79NhQ72LQ6ztB9XYdv/GOcqVICLh0sVqvBbD4b+eDvm7dr+vt5SCRM Mqwv+RNr9Pri1MBhJHNZyY6quLl5r0yHUkpQkHTEe0FOM9qsmXqHroWw2xiizn0+6+zYf2Ba92Pn r7IytB0X/77+k3ARn4uBduPIz+eeuISe/0mrdvb0VW5adUzsKj4areHJk88/zg12wexFkTyNzWVA 1usbRlDAjgRuKm6jUa1UuhWnWykMotiqKTtqveb1OgOKmM2iFRThMXiiznMu4RA2M8et2pAxZNYb TfKDT3pMitZiNFnV5Uu3N6niLuIzwJY4omGzEw7r5N+v3DkzZW50LkfEsqo8/am3Nz/OWiCzFqEv x6g0LrVknj9IUkYNS3iirO/uDvkObHQmlUJlcr39uZqUTDoNFElpuUquVqsnQKXRmfRoKgFh3q5s W7zVbrLqkrNVAm6zEZPrNj85dfqq7GsnEv3IiC5WY7bNZstvo9Fayb4lh+nCH38DvUPrFg1PrVvU tU6riC4jQ3yrN2hmj7r6wBhipchFVYM9MQy9wmhIJhOw4HyuiM8CzIJhxMNYJat91dY9P2loZ7K4 ko9C5KnXKZhcpLEZNNnZEXXaNg91t6hSclK5UZmJAAAgAElEQVST/to3Wdmg4c8nbrat7mE0Km/c yKW3ruXCYxA6IzmUMMVNm1H+dKy3YJjjmcfMpmzNXxuWSrp8uuvojo+8eYh7Bk7Z5PXR4X2b5k/9 bCj74OEhbas6w+HabRXR0a9YBGwh7ELXCSs6DmPgNDr+/BRHx5jMgq8/TqNgT/+m8sXo3cTAK2Rg E/X2/ef67aY3GN18llsBgTMuYe/KawcAp3K41Yc3nhLEtz/MuKG308J9e3o+1dTbjSoFEEEc9q3s 265eHWsxKMdifiV4ff05dBNAsN/0KnyhrOWWcH3e+vM5fPrJOX/8LJbWHhryZSDH/kfiWYuRvePU cCvDq0e9CfVc/cGaBVS/MQ36MEmNqdahP6zEW0JrMJy8cy8qMdlgMYf6eHvKpG8Udl+GmHfXWcjR 1CLKJ0WHzWKlYHU4uEmRkf0oJhrj+XqITGqdXnf98llCEVKFvXnTzqa9x0R4CxSpD0/H5THqivFM EPHFYoFzyswdum77EDupSMYw+z8re3v0mrRx+Td+InzXtFFrDl7r1sessmWYLZacnIy4qJtWr2aN gkirTsQieRqj3Y669UoJ2CakGavwNVXk2SE+LD8/k1SmKknKWPQQ5y09+dq+0zh0D6tRk5iedC9G 1bBhYFp6ujku9uqVi3yRjyT76KK/dV+MGeLOxSLvXU+hCfg0oNHoYoGYZF8E3GdtXCzJjzgS5u/P T8mcsPn4tE7hTErmYO/gq7djg+9fBtcmBp02KyMxNj4xuE4rNyF5IhomUjPyILy4MSApNCaGCbi8 /IgZdoJkV+LpbWNL/Gu3CNi37tvoY56qhBQ7wIlDjwhyqDEQdhB4+6CxXxd/9+ctvyWpjS5ubLPF ViWseT0/8S8A0fcjz94LbVHFnXSL47HKUBdBxlAhgPby6j6ZWQHNpooynf8XgrDobieooFUvP7lL I3/XQxcfVwtvJOZxanVo/9uFqyZ7E2ua4vr1aFk4PT03LSc5BcDVkJJ04cKlNFbOpeuKjvMDBC7+ /YY8N65MBVurJkM2Lh5568iWuT+u7dJv3PIl37q6+2C+rZevmiTFVJvmrMiR1Q0MkesuHz57PZwd uSaGRZMJuAYpKB6fu33bLf1GNFkREtvcaI2bjV72/TBcG/PznF99+n6pv3jGr0HDr5cd0g+q8SAz CaCq86I376cNrBr8Xm7ga1A8hTgGVDqfR3/ZOxPR63MBGPExky3j0fIPi7u37RHO7cwSUQXNvm7X WG3I/ud40z+iq9Ryny6k5o8vgb795rp+DEiuptA4TPb18z0Xx2R3q7+iR0gTAT3/scboHD5gSgtj cqP5OE5/8GDFIYu5c+2BIho51uNUkqcF4moMPAqNjlkGn586fefN87BqoiLTUszoJaFgressaOJV jQ15kemPA/FHWo6/N9cFw0w41RSvyQO3/1DcpbLFrjPnopKSu9Sto9RqmXT6W7AvkJk+nxKwum6Z tu45jNkZOu25Lg3rgsWgNdna1Gtw587F+KRs+90vdlGrHrq6i5/+T4/2u2U8ukmX69vhi9WDW93/ 7vu8ArMBCpktz1m03Nl/sdPXC33EbPTIN25Vf3S/31Pad7XcO9K0dm2rQadWZn2xPdJJwBTAeWwG 9l49XvTpMfs2b7p8ZIlBl4cHtJiw7sqPN5QZucZe3U+36PPt8vERmUfatvltA4cGZow2ZMaKAJI9 MUsBnTn+dM6tTk3BPBqOaxPKJCPAu3w6oum2k1dlKkg/Mq3RtQUmvYYp893yexMHAWM0wDii4vtB YK41289c2cmnar47iku1OkPn+Hk8VWBTWaLuE5dWa/NApQOZm1ybHM/1D+c0ndh6AFdMA9yj9sSv xrhFNOnZtW58QrLeCkJXr8DgYB7DvHDNKpF36IX7D4JcxJ+Nn9+SH15mMbHMaXNHdEgImrh52hB1 VtzFizf1VH6DRk08xBx12r2vRwz2Hrpleq+P3lxPhYfdbEg0aJq1qcWk8jp1rj99z/U2nVszKeBb u3XST3uVgm+Ht/GeNKTLfB6kJZqJ0yfnfTpAG3f5y+H9GRSo2vzzwQ0L+zVQ2bjBnGaji9sOnFSj TuNpzbsuPfnpqgnjrzb/rE+Hv6hgVmWHbfhrdId+4bdHjR74cUdcn8ELaiDgc1sN+mpo+4XdLmw3 5SkgsLUJd5uxfcnQCVM7ttlFmLXy0KYbJlEWrBr/z3w5l0oYWbU21nCsDpHWl4RYXtwsF+8SxSJg Dl2qzDp78kmgN5urMebqzFDDt9apCz+eTr2mY9q+3uRCo4Z+3m5dSxmmy7v/MDNWoVAmpJw8mXox zLNfLZnlhwP9k7CIpjJhNrUag8YsaJRBo3EltOd6eV//ETOrVI/w8Cg4/8foLi3FHjsjv9hsGkho b/6deF7itWCQnxRsGYjy8acGnkyOe6A09MHjf04+ELOtTw7HHG5f7/suYSP2nt90JfaEXX3p4uP9 abTOK5u5kStODubm8aWxqiLMcyrxelhttoTMrMX7DgZ7evRp0kiRR7Lv21VFp6p4rARHnWy1vrzm p5KIHkf3Cq0ssbefn5+XD5tqVen0bA6f+TSVSINfLg/KSclSmbkimauETPwdtPZGF7xIJSpz4vFk jO5cR8S8W43MSR1BseYtXr8jV497BQb4e3vzWPkn+tXttbK8JhXFRcMBs/7nH8WUufv7+XnKZRRz Xn8rxudynznC7riel5WRqjOCzN1D4DC8+GHHcaAUMTK41mi7Z3vbpzMRvNXsw82smCmrPqt9lMTF 0yfAz9vNheb8ksKfevh1cvnLoLEEMg8x86m5rMA9sJl7YIHvMbYIMezTuXINZ6Z4F7/8k8Ut+jjz Krq7BIUVrLXaR3XRvNxiF649fmZ8104RImGZzIbsZuXSAVV/OGIZ+D2mvr85InxYFl/AAJPdrfa+ w3tqczB9dvLMPrV4R+O/aO/3b1d642zX+Yv/R3cPQreuWo/pT+qOd/V2QWX3Gr0O7Ar1k8u/23Bw 4JNEI8b28xIlJOdyIUHeuPum//3syWdwhWLGSwqC2qO3HRhM4bDJG+Ma0mBTRoYdyDWSc5rklKRM O43t4el0uIGl+85/n5d7bVXTKcebuPHpsuYzc5KGp6stEgke/zAt2JXP9R73z7XBaRnZNLZALpMi qW3brYwnTxLzzFRfP3+pgJQG6fKaJ46dFVetiIJWsQi4Rm7IBDf1gcsLh2ANVK7si0ZFyK0svqdL 7aAOza7n3mvsbqZIIg4dpo0dMLRu/7q7dhxsK882mBdFfqSa9hmfbpt/pfqOTzxQPd/8VSf668+4 r1bHuXh1KCpKDa9b+032yN/iFFEEzW1I45Wtg1uR4z3G+sinK1f2VMdFFQ5u+L2H5EBqnsLGkA9t uqpRQFMpE5uFu13PfJBj1tYNHVnbr6OYrelTlS5iMTDMHiRvaaW8uzTdHwxuPo7768at1hE1RFxu rlZXmqqY9EwmnVwl1Rp8TRZpGTXwJTAk7br1LvA3LhYWNgPkSz35Ba+Pv9JrCn9htuHI5kcXNmrZ oUxaWubguQR36lZgZkPlFwp5gFNpbp6+BfdQimJfcHoLFTqVClT3ar17VyuTppYTCIJwl4gVeXlr j/7Vv1mTqt5epa7S9uDY5tlH9CFdJs8e3tsQuaXp0NGtOnaU2BKnfv7FsduxLfvU/2Hx0qsdRq2Z NrtD7XVB0n95JGoM966Sn9AdKCx373wdJ5XJq9/QOcHEfYLyn7GgQK4uM4GG0/lcoaSwdfzT+jA2 5wXlyFMLBZzl6ef7wpEUCk/At2olzwx9eXJ3niNCmqSRp3MPg833838u3dJZwuBqLy58UBhB1cOg QqJ4KuiatZp+/H297VsZCxbBlStNVq+kPzzTau4WYs0ajBHj0/xrWL0a3LwgsH7bb7+FVl0/nfyN rUMHat+P2b27g7c3zJs34POxqBpswcLwpctg/vyStpLGCepTb5qN1CRQ8GceHRRBryazMex5Fxhs r44RX5BLbhg882moFvBxVf8uRH40HXSqqM9H3s5vG4YOa1DsiAeVcCI3T7v73IVq3l5cJlNvMpWy NsS+TDrpJ6M1+pgs5RgNpxL/ZVBxvIa/X2Jm1vZTZ7rWr1s/pFS6FsKs3XrkrM5k/eq7SeRKRJPR 62rrk+MeHvt1T5QSmlntgFH9mvaf0efLz45cOXc7KahN0Jsr/YBAAGRbwVxmNk84i57ErFlL8CHG 8y4e/aBJ/rFjjM+Gw5IlcPEiffUv8NVXEBmJ7d8Pw4dDbi4kJUGfPnD/PumT1LAhtmUr1d0DwsLg hx+gSxcQCrExY9GHJOOPPoLY2LdoKIbhVJxGfdGfEqdQX1pfwxxRZSkvnuvYl7+shT37Fk3oi+ek WIl8JGdnrz92PMTLI8jT/fWuvcWEmHufglkJgpJn8PtP5WB4v7g+bNgRDw/00Tx48L7b8o6Apt+e UimLTj955561dI+uzWzUqRUgHt62ukNnQsFvH1jTrFa98Qu3W+w12wY7ljwxxsfjfrArNRkJbzCD //DAkTc+cWxtoKys5H5K0zlxp5d3qUDhM8oOJfFKPnIkv7BhQ35h2bL8wpQp5JbLhXHjyEKVKuQH oebT2HuNn6ZY79Xr7RtbifeKbLV6x6mz3nKZi1Co1hXLxeiNEPNvA2nySlNrK7QasxIfAND8HcnB 5x9E/XrmfN9mjenUt4zJYDUadQolVAkWPq0gsHmnn7eK7139e+XK47+dje5Um9SOcrzDAiFXpSsc huKDB4ZhnDJOwIxTP1BN5QfarUqUA7acOEnFcTGXazCby6RCDLOIuKQERhBUtf6/paarxHsB4oZw X58HiUmn7kSWti5JviYtN+mO0u7Wa8CIGQs3fFwrLzlDkX+AXmUDHp9VqpxOlfiwUbHiclWiYsJm tx+7flNnNDUPD9OVet33GdxEZygYGatUmRdmthbXYbQSlSgNRFyut1x2/sGD2kEBUv7buKZgVAqV RYXY6GwT4U1TLKgXsVMY8cXY0Xxd3MWbULN3fpCxvIyEeMAplA9x6bISZYRKCbgSb8ajlNRz96Pa RNQwWizFy+9bLDwLAZ2ubFVWdVaiEm+EXCjQGYx34xPs9lfGpX8N6FxhDc8g6qNfd5xOAopo/J4N 3vrb340f9fl3SwQtR84e5Fhus6s2fbkeZCIZGQCkEpUoGpUEXIk3QG8yrTpytEX1cLVOX0rrlYLA KSYJ/yaQNpNYpqrxG4+vxAeJ92IDyaDRwnx99p6/eDXm8VucjlF5XXs35TONm7/tfSdZ49l4+Nlo bcKjmOjYpEsn1oW6iwi76fxvP868/TgsxLt1rbLP7vV6oFmF1Wo1mUwGg0Gr1arV6qSkpDNnzpw/ f748rlXwT4LMC0ZO0M0mo8nyclgewqjX5iFo0UjyqqkPYTbo9UbL80s4+mKxFo4kabdZdDrD81oI wmoxG41GyytrLgNgZW20W6mCLgQCbPZXZY77b+JiVHQNP182k67Rvy7tXUkh5NzHcVKbrdEFlokH cFRU1PLly0tfz7tEWloajU5jMBk0Bg3HqRiF8nZv+JYtW0SiEjhxucbFOf0wd+7caZK/t0VKjIzl TqeSzg34O44X5iIShnh5xqSkNnir8IT+LYauH3lnyrZt3y3bfGzpJDqL4xP43IghN+n23NkLXaq3 n7lscwC/HMdYxH8qlUrpQG5urnOr1+stL4JOp8tkMnMZmW48g0mT9dv/jnX8tJ+Ml+9Vf/PMrsd4 aO96fj+O73/HHNiiY6fOzRr4yPn5P60laUSTztd1eXrMteuwsZOH9/YVFnZ8UMRcmzbm87sh35xZ 04dBZp6+uGLNrpjkdL5LSI9PBnZsVM35mBA289HNs75d8WT/td+CyTqM1479tuX3vxIydd41mo0Z 81lNn3eaYgdz4C1OLN7DEXMdMpnQtLwC5ZcXsh7BwXMglUFQDajmA8V5w1PPQd+9cGolfJA27yXH /cSkP69e71inltZQOEdkKSHiRToXgBV5EaWtC8NYbE6Lbj0inyRmpKVmZ6SjMcloMFgtVuKtdIyF qzfaceXzKbnVvehcXm8BxL4u7u48gQC1n8FgIA4ufhToZ+jcu09acvLjzKzM1LSMtJRchUKn1VpM ZrvdBq9YLhgLhNM/Ycu2/yW/qX5q2vNVf5uQSrDLYHqK6JbBZFatUYPL4zNZLBqNjjj4LfpeGsiF wrvxTy5GPWxUrWqJT8b5PZasqTn8cwvH4+UvBW6hS3+/zJQH+7mXpWu7RqNJTEyMj49/8uRJggPp 6elisdjd3d3Nzc3V1RUVIiIi+Hw+k8lEj9OzLc0RVObgwYNl2BgEbea9lcv2RPTq8YyAL+9Zdztw dI9a4nuX/tp//69De3Ys8wj9dvXGka0dsxybRqHlzFm13gdSZ8z4dr2nz/x+zQrVuW/VnK2nbzLl ec4n9/6hn05G4VMnDbu0Z+OnM9bEHF0uZZGcpXi4d8S3P2fkNrA6jkv5e1n34aubfPL1twM8f542 eZ2n/y/jepRtZwsCK4BSVlU8Aj53DO66lAEB2yywewvU7gxB72BdhIBT22DifHANgOxMaD4CFk+H QPEbdF73LsJ9xauGrf8aNHr98Ru36lUNRu+xSVeqiFeFgKhXwH6MYTaCoKi0ZRCkhkqj+QUGcnhc NJqzOWyBUIQI2GK1EGWhj8IVFqZS++xPnX+Zjao0Oh21WSyVCUQiFoeNJJW3ICGxXI5GWZ5QgLrO ZLP4AiEiYLPJRKoHX7Fgz8rMAMcP6urpib0pjCgnLfdZ2STnWOVlMDl1EjBfIBDLZGj+wWCxqFRa mev3Xg8ui+kmEf1z+141by8Rt8RuMxiVHRBep8ivcAYvtGb94ldFEITJZDIajc6tEzk5OekOpKWl OQvoMB8fHz8HunXrhspeXl7Ut3WmKj3sdrOZBgUdhAgbKeXguNDdu/PvG1c1Yt2fMmXiuA6hqRtP Th3YlEFGtWT7BFar712r47lDR67HwwsEbI07/NPEP+O7dws+pssfp1tO/P38RBpmN/vS8k5N3acn l8CoRsX9iTWGuNWIoFBtzsOEwY2XrGn+8ccNWGCJ+mvNbWsZSwsFgRWFt66t+D9e8aa9FiMQVCgy 6TGaj5vMcPx/YK0C/jLAaa/jQrMZDU75Bxg0cOcq6ITQvDZQizpH8QTiKFD3pbUWiRvQwuD4n3Dv HPw8Az41woHF4Mouoob8Ftqh6PC//1HcjU/IMxgi/P0ep6WXbc0MmoLNJEUvk0WiM5Y2NCB6AZD8 5BzQrRYLlUZFBIwYyGazEfYymEzREg3ch4pnf+YGe5a+TidwGs5ksXl8vlAs5vL5pBBMpZb0fUac TRI5BxE5qcnncrmOyYdD+n9F7zk6rZOAPX19kQz6+vpFF557supcxebAV79BxQeGIemfzeHwhUKh RIIKtLeafJQSUj4/Pj3j3pOEZuHvLlShTqfLysrKzMx0bhEUCgXiUVoBoKkYEmRFIlGdOnXEDqAy m81+x3OUN8MKL2f5wzAqi02x2uzu1Tut+7VW7SXfzZoxLiL0zw6uiSoeXciGJ5GnTxy9V2/8kIJn 5Tw8/ekn3/eb/HN32uFjV55WRcUfHd27bt8f125e5dQbImXQ7EbFijkzDgS0P7Bk5LQxm52HcX2a 9PMBm0FxZO3MNX/GDF0cUH49djIuelbRT+ZU27wbAn4Jj0/BsGGQHAEnd4C/452MPwkth5J2FWN+ gsm9Sco+thxm/QzZwaT06R4N/X6A3Gz48xNY4g8/boL2AbDga1h/GPp9D/MGkZl6F3YD+WA4vwxO q+GL1fBVM9g1C37cAmlaqNMa6uyEIsORPTgOA+bD9nPQ3LfAXgzYPKD4goc3VPkEmgdD1RHwJBNc fODcTpi8EPIwmPQjfNaBJPWoM9BrDDBFEKwBqPH29+TDgkKjCfPxicvILPOa6bRcNoMkdaNZZrTI Slkb+T44CJjHF6A3g8VmIznCarHaEf2Whc0206IVwfPFqvSgwNccXCLgDu5kIhLmcpEoTGcwKCW0 P3COBagSVAPqKqrBIBJZLGYyUd6rO89+FA2Z5M/q4e0tlL3h/heMYa9ycTEElUFWGcwRSJpUkLLY qOMkAdNo756A+Wy2t1welZRcLySY+crg328PNAVEkmtsbGxcXBzaxsfHo4LFYvH09HTKr2jbvHlz Dw8PxLjPqBdt0eD+7u9GSUHYwJKotxifG2ZajBRfUb5O3tl6lsB13PTl8ZcD796Jb9kw8+r1c61r h9tNWu9a7Qe3e56oxKJJW7ho8SV9p/Vf9ItffhDtsKBpuuMrvc2YHbv/6l1d9+ZmHIP7R3ev23B0 6v771WWxNouaTEfvWBMxqrOmjBuydc/xTrN+G9K2Vnn0tyD1On+sghxcnmvAhUHArf3QfigEh4H3 QwhoC4rTQDyEoHbQfziEieHGAchpD4dmw+SdMHQAHP0frFkFS8fCJ/3h+CHwawGNqoEvGyZ1hU2x UMMLto0BmgDmtIVzR+D8RQhvA4GpoEyCC8th2BIY/AW09oCDD0BvKZqA6/eE8D0wvgNMXgUDWz21 7LZDcjTgDDBrIFcJZ08BDSc/j45A90kwbBxQE2HkT9CmERgiYdREkLaGhjTYuBWafAVltsb3LwYa ve/EPwnz9Xk7V43Xg8tMoFPVqKAzuZss4tJXiF4DNHKhVwC9GWg0t1mtqNkO8bcMCJiVpZHBc5NO 3Nu79HU6Qb7OOJ4/7jLo5FJoySfUJAHTaASLhW4Ck8W0Wix2m93xq72y7yxW/nxC7uZmcX/DepA3 qJ6VFRIPnXeZaOAdXXcMZHRH39FYhr0PygnycD93/0GGMtfXpWTGaIhH9U+BhFrnNicnJzs7O8cB VFCr1QKBALGst7d3w4YN+/bti8pI5q9wguxbgSXxqtIEI55pJa1pN64mNukuIgiryfjc4ItC54eG hN7LS0HTYbmHz/DhY2t+VKdls7p8xvOfOzbywuVzj318bO0jqhlyFBrjX+26X9+5abWvmFmny6Bf uwwavG32gDH/xMz4+q9Dy+2u7utGt15tQgcqm0dUm7Z2/6SmgqlDOuyP8tl8LrZHXb/y67KTfZ0r 684ldqpDZfXWP2gxCfjFF4Mww+4jULUHHPgFjHfBoz48yoAbK4DTB5YtBykDtDowPoHvt8O0DTCx C1RLgcOhUK0pzK0HRBx8NAD6NIKEs7DrKiz5B4bUgFW94a+LYG5DtqfTN7BpIjw4CJmeoIkhdcKp sZBdD5YPBtkz3ZcavvsSMhzF4L7wbXs48jt0DYZPl0DfVk/pEyObTbsLAz+BnFS4boTFMyBEAt98 Ax+1B0wLl+9Ak4YgYMKFY+DbFjYtAKoVjDEQ93Z38kPDtUePmTQ6i85APFbmlcuEV52F3LwaBFFa ox7ntBQcIzj5ejCZpDcElJnHModHlcLzdVCNpMyyNmHO2OUOCT5/Kl1yEnJ2n+4YCxCXkVI/8Ybe 0+j5LwlfILS9qTtSeJ4xjOCKaZKysS/F8kO0YxSHtOdEmdRcUkj5/NenskaCrEKhSC+AtLQ0k8mE 5jEcDof9FKiM6DYsLAxtEcuiLY/Ho5WDYF1BQGeKXfCcbUcja40g3QgfH1l9DfMYGeJht2nTkx49 +zGt2Td/OZLeZ2YABYsSewcMHjPGX1CYd/wj2mw6GGxEE2er+fLqb767G7xg5lcuHP1v46b4TZxV L0AUHlG7uuxQrtk+aPahtmpydUn95OYXkzZP2PhTxxo+aScXbrth2nx4fefqrmjqWU4PEnpineyL fmuuA+gBQG8cteTLRs9QPAJWJAG4FvjbDnortB4MYiZYHAqq3Fz4+wnM+Qmcibe4XNAbAQ3cfdoC nUKWMfz5iq/TGjkjnVzobRQEOBVq14PDF8FkQ/ILNGkEHDrU7eM4tB4cqQ4r5sKE7vD3Bjg4/GkV NPAMARc20FhQwxfUT6BjDXjsCicWFxZe1bEQFQvxqDQKhvcFrgUSHsFJ9KkJ+zZAt9rk1MJiAFc3 MiMWBQc5XknATmw9capr/Tr2slhDfRky/jVnQZFXNhnLncvACFAO4x2HbRPA84VP3luFTyo/YI7O k0MOlQqM4mlvnlrukGnh3tSdgn03sbhvPP5fBx6LFZmQiERh559Ilo2JiXn48GF0dLSzkJiYKJVK Q0JCgoOD0bZJkyZoK3uT6v6DB4MnbVKr9uiRTfJStvQOVvYZvrhBm9V1gqWEPtVm11y4E9k8iK94 fGlMl09zPaq271gTz40iNWtFKWYYbFFIuFOzYs0OFFJzGtSKqMaCrLOrf559N+bbUf3+XDvkUeDn H4kYPGZ+Xl8lR81muDRu2MSTDVGqTLMqfV7Xej1TUmzAH7pg86YpPcu8v072RdMsPp80XUCzK8TE iIBJJ7ryJWCbEQIF5PJteircuQuYO3Bp8Nd26OYNN/YAeEGgC3jR4PBW6CwDTAHXYiDCj/Ty++MK 9Asi2VobA1oL8By13UmBXgAe/sBgwt8XwSKGOashYA5wX2yM3QA7focqEbB0HwhqQeoh0H4GPKe0 xIbPv80/jDDC3Jkgbgd//Aj1/Au3vNl8ODAODq6DFeuhVgTs2AW+wRDhDmvXghsG25aDLhzQi3Tm DFztAAI1XEkAk6VwJf89xKalI9FELhSmKZRlXjmf9ZhJzwFyAViSZyhHfVElKlEQSDYyGgw6rVav 1eZvdVqDTqfSaBLT028drYqo12AwoMOcLj21atXq1KkTKsjlckYxZzYVGEgutJVdIB1HjYxBs3+S evN2nP5j833o1mvVT78M5WJgo/Hb9uqxa8f8Vmv0VAbbq2m7X6YurenKMtl9u7VtLWG9nnQo3kHN +1h8Hab28nnRp+d/v/bwvgO88Ek7xk/kMp+fy5Z6dehWi+sgBPd6vXv1wuRy/wHuQkKfxatSxk7A 6JFAFIvkXUS9EokEzcbQFnGwk4BLY5U1bPMAACAASURBVIdVPAK222HdAji0CnKyICYOPvsZxvaF zf2h3z3ISIQFv4G/C3w5Dnp0g77XAVSQFwx/rYehnWDmCNgrhztpgEngTjo0cSFtoUWOGADuYTCh J0wfAV4MiKoJUd1IYTQDIP2ZwtMEO6dDDI+UquP08GVPYBelWMAYMHYSjOOB6CXjTMSkOSY0T4O+ X0HdVvD1eDh1EyatJ8l75EBgWsHEgKnNoHFvOHAUhnwCDAM8igOXa2AZDR+s3qhYQAJBo9Cq2Wp1 eVTuIjrnLGSqGhNEZSiYSpQLzCZTTlaWMicbbRWOj0qpxGlUDofL4fHQls1FG67M1dXT14/p6v7Z J33R8OrUK34Ya7SFgPqVkZFRtnVSmOJOY5e3/kxvtQPpS+bQbuJ03tCpP3cakqbSGXEaurWeAg7J pwz3ljMnN6cW6clSoMrQHl+u6UZxjgvi4OYLtzYwGE00OpvJeGGsYEoDZ86fhjv2CYPabtnStmy7 VhA6nQ4RrcNgX+LiACoIBAIW6T5HLX8C7j4CWDeBJ4LwCAgPBp7DgiMtHu7Eg9gd/BwqgcDOcEcH 9yPR3YCwKqQJ9PdbYVg0qDCoEQxx0SCRoV8Gxi8Bjgt5PM6Gb9dD/2jIsUL1sPyGbPoHRCH5F6UI 4XgsPIqBXCO4VQHvV5nqYCBxKXp/72nQ0XlfKOAXAXsc4z4pl5+CpBSy7+4ewHTMtH47A/FxQBOC mwh0xH+cfTV6PZKA6wcHqso09NVTEHLhJWepMgR0Jd4OdgcI+3OoFIr01JT05JTMtNT0lJT0lGQk zrp5ebl7eHr4+Hh4+9Rt3NjF3YNelCBLEITmYUysStPemUT1A4VIJLp792551MxgsQvdVsS77j7+ L1n3YVRqMQw+KC8kH6TSGDxa0eqHYtVWFsjMzETCrpubm0yGJmyuqICEYB6Px2QyS7MADMUl4LBm 5KcQcBHUetHaG2dAjdov7PEJAad3bsBTWvV8UeXoHQIFTUrDG754DQYEVS9WC4sEkw0Fc0I/u01U FvgX8iShgv/TiHQC+I9DrdPTqVSifIQANiOdw0wD0gNYpKrMAVyJN8FqseTlabQajVatcRYccb5M VpvjP4vVRlruWFhstlAkEcukfkGBQpFYKBFzuLxijozoME+Z5GZsXPvaZWORUDHh6+sbExNjMpk+ AHX6O8b9+/eR1ItuIOJdxMFo63TLdvrOvSc/4Ep8oLATBJNexpGfn4HPjsUpZM252jAbUTkQVOIF qJSKrPT0zLS0jLQ0tM1MTzPq9UKxWCyViqUykUQqkkq8/PyYpPUpg0anOz5owyil4SuHwcjN0775 uH8zJBJJQEDA//73vxEjRrzvtvybYDQab9y4Ua9ePX9/f6EDTvMrR+zY0sZPrSTgShTG1ZiYsgph 8RIILisOp5CB4lTaMIL4b+v6/0uw22wWi8VsNlnM5D8IJoMhV6FAjKvMyXn6yUZiq9zN1cXdw8Xd vXrtOi5ubnyh8J24J2Hl8rxXJCBBbeTIke3atWvRokWVD1rZXraIiYlJSEho3749EnydXmfO8Npl Er28koArURgms1XE5ZVHzTjFxGfHYZjdZmflGfwIoqLH+qnE20Gn1WpUKscnV6NWowISZAsRHBq/ uHw+TyAICQ/nC0WIaNHnPXrNloe/e0WDWCz+8ccfly9fPmvWrEo3quIgPj5+3rx5vXv39vPzQyIv 3QHqU8/10tdfScCVeAkEYbVZoRzigeEUA58VC+QCsFhnKrOIypV4j0DibFZ6utMAitympGSkprDY HLmri9TFVe7qirbe/gECoZDqDN1HpTq3pfGeLA84A5hUqCaVB5o3b56amjpq1Kjt27cjee59N6dC A8m+gwYNmjZtWtOmTZ3+vk6USR4kJyoJuBIv4HFq+r0nCTWrvORRXRag03I5LDIHg9EsMZjc3nh8 JSoUTGCJjLkXj5nUapUmF4m2SMBVm4wGkUQqcyW5tk7jxnJXN5mLS5HGxhUZBBAGk1mZp5Xwy0X3 U3GA5DZEKjQaDW1HjBhRr149JBa/70ZVOGi12ocPH27cuHHhwoWNGzd2Rm0rqxSEBfGfJGCCsBst dqudwqRTaJVa0Bdgs9skfL6AzS6PFTG54IozB7BaF2y1Vc6+/2Wwgd1oM/MEAhcPDw6XSyaQ4HJZ FTBFz1uAAJPFkqJQfPAE7ES/fv3q1Knzxx9/7N+/39fXF0l4QUFBiIk/4MCZbwRBEGq1OjEx8eLF i5GRkXK5fNSoUdWrV8cd+VHK6SEvHgEb1OkzT+cdzwQpRzitpbzVc/8ue3Z68vCjJhWV1aem2+c1 qGDOWXRMsSMD2AzO2IYeg4Pe2aupPXQpY8F9CHGRTmoqCBcReYqstdfsfD6rph//IzecRjaEyI5/ 7HGCCMPst52xwnH2ug4+I33fVRv/JSg3exRX0VlnIVtT9/VHVqICgg2MOtWqahp9gGuHaHgVsFl+ JczH8K9GQEDAhAkTUOHvv//esGEDYp309HSDoVx8H/4VQESLSBcxbt++fZHgKxC8C4fUYhEwYdSb zuTi/r5MhknV45Dx2+aeU6pSKGCNS07pfcLMlXK8aKZ1N1Nlbj7dmfqdaoqrFzeIYvjpzJNbSq8f 69EY5czCNpN6yYn0RZnslt5YrjZn/g3m8mbU3BzNvFR6A71+6YMciUy2opmgtpiwmO12G03iw1kk wV0w6508kJRBdvEPC4TFWi7WKHSqSsS9D2QUBboyr2Z5XKISlXhLYGReW1s5JP6q+GjrQJFfIaEw KysrNjb28ePHycnJmZmZHA6nYcOGDRo0QFz1jtv5QaJYBGzXmAmDlf1DE9dATPXj0Zwd941jg9lC imbzFRNd4rWzDcuVZn6cY5cIweFhQv+shlsfV9OlSwmjEo3ja9D8Wa+pnLDYsWd6YJsNXpMPFZGn 2YYzCytJTNeisuYksb9r4j6pKmbWm1LNdBHVnmsHV758VQtMqVRMvZ4x6G/8XC+eUEih49xJdV3+ z951gEdRbeEzs73X9N4bKUDoEHqvKh1EaXZEpSgi0lQQARVQkKciWABROiJdeieU0EJ6r5vtfXbe nd0QQkgggSQQkv/DODv1zsyd+59z7il97FL8WBsJTSboCqgrg6JMeAHHKftziS7cYm306U7qH2mp kJVVulxcXLoQfwmys+7t4+ICQcH13bBnAzQcY9Ab5ZRcZVAoFEeOHDl69KhGo0G6ckhISN++fb29 veVy+bNfqLgBoXoasIEgzTacw0C7YxwCGDSciUFxcuGXSunPfbheXCQpsUJdKbul1UiSwAoS2svT AMbCcd79hEraTPHXMocft6SwxdsHunZn5768xzptgHcHIahyEt13SQ+PkHrpMl7bZThow6PEzr8O lvib0py20D6Psqy9bkq0yv5+wblfudyTFn3JilQC3F1nRVKJydgCjoC6uA3RiAUwPpcTIHX7nyUp 8ojugoobUUQlI8fApjeTVpJEdC7hANxHODexVTV9iOwYuV/8yJoe9WwCqzMGLstAmad4IKtaE+oB SiWsWkmVICuP3369t4wG1smvNVICJkkajnOZjdceZrPZzGazTqdDvLtp06aEhIQhQ4aMHz8+Ojq6 iXHrDtWU+BC30iwb4vMK89W/F7FmdGFySM36K3i0E7cDV3PopvmSjtCZSIzG6SokLGbT5oSCbVrl yiTOu21Y0vsUVtPFxMzBZ2g9Qnk9teqRuzi3htO9eaoZpy1Hexr/umGjsRgCbVb3A7bYYPkaRsn0 68o3rgr3BaPL6z+/zX8tFFt3jUhUkf1cyijCmqs0JZaIdg2BlCzlsWJLrsFmIvAwd1GYATw5pF6n v5yv25pCmjCak/3rMliU47eq3HBbrglwvtvRYaKAJm+geyCx2qujWw50mlbMuwV2+3ORulWtn78J j4Z/AISHw+XLVe7g4grNmtVjg54haPQG2tMrSPwUYbFY7ty5g+g2OTlZq9UaDIbAwMCPP/44MjKy MTtk1RuqpwFbAQirPuEOXNPZNDbLwSTDeG/DZQ2d66v57qJqQzJVndBC2JQgb9kB7W+6nEyGyuV/ DRJ2cqVps1K7nXSchzats7Aw3xrj57O6K92qMO7eobtqko90L/72giq+wLSzgPZyc3pmoanAyuvJ 0X15x6bCeB8G4hjF/9wZ7d2mBOqbYzY/UfGMfzQH1fZTiuXrQ6xFPHmAPrPLPkuOld6ba9mlZkzn 8Z2KiQs5Ob13k3ozIWJJNg6QxvAhB2nwdNHiroJgPo3DxHg0uvfDzOONESRZFzWAeewMJl2JFnRG T6P5OfTiaQAQCKBT54cRcFQUuD2QP78RAEmcuSUlnSIaV2by69evb9269cCBAyEhIZ06dRo0aJBU KpXJZMxGbAaof1SLgC0FekLN8vhzDI9GGOMvp7e6oN2aBRYSC+cKJwdwX4/le+F5L+3XpPCEbcQa AMnqEU6BpdITaRPwXvcGER2j0VmxfNtWGx7qwuDSwIADjpEEyYoN4bieL1l0FJL08rXN4Fw8SZg0 81K4L4T4nW1JR5exaikFPESC03H+YETwhLanOxEjx3A6zUnOwAjwodMkTs5/dGVHepJZSWmHzssG e4KuEGPQcDaDUBtBLOIG8TB0OeqOcXZ3P55Hk3BXOeooFQGfnc6go64BakMgYWsSep4G0Hvt0AG2 bIZKa9IhdadfP2h8KiBAaYH45nUT+/7sQK1WKxSKzMzM48ePHzt2jMfjvfjiizt37hSLxU+7aY0X 1Xc6sGqPJpnT1MbT6SBnMVtIIZ+l3pZmmuDOFmkL517TnlcKN/Vk4Dq0K0nlUSplOIwndn6jrMYR qRYxyd9ulxwXYzfSzApSFCkCOstllUfa0Ez6pBYiF5pZxsbYOGNiqHS4p+nMraK/s4Sv2Sel7lWS pvF7IWW2FJbETLygpHhjsqSnXL/3Rsnyc7RewdxwEdwS0Dr6eG/sZDpzR/HV1axeO52W9BTHkehr I0r0hJhFZTu22OhiLobfRzhO82ocIUNzeaAUcYMFGqVrnYExzCbgpNBwE0niGoOfzdbAsjQ8P0DK zeTX4IvP4cHC7K3bgJd3Zcc8/9Do9WaLVcR9fr7i8kCkGx8ff+nSJaWSMkFxudyYmJjx48e7uTVl wnn6qBYB4ywcY5hKhh4EA4F3dXP5d7AwSoxFxil3bi/o/w9GIwkWU7Kil3M3CZRQFUXogqqMGBj/ hSD2ssT8wfvAZOUu7SXxo8ZizqAOLNgu7O2LxG9Wq0D5J+l5H53PXhlPGs2MCc1YHhzS7ixd6RkZ /k6CYc5FM47ruHSb1ox18/da1Z4lYVhkIpLQkCSd16MZp7V3way/tFuSxAOCcJ2lqOffCsrvmgQb 7nT4JXEwv/wJ5XMbd4hqHYQAY5hFZJ8AJmxstT6QhIaft6HhIqY5tGgB58/ft5LFgqFDn1KDnj40 BqO/mwunoWXvejiMRuO///67adOm5OTk3r17DxgwwNfXl8/nI8X3eUic8rygWgTMbhfidc7FZsUZ cj6dxywdP0UePmfH667lEBYat5k7U2zvvjJPn4uv0LhVhhLhcmefGyP1t0uAx+V4ikt7AkPuoxyJ cSgJFGOwJe/0F72qMRWbaGI+U8RGyrfbke6MQHkVd8CWLxwoGJdjyNHTPeT8wNK0aoygYP+/Aug8 6gZxkcj1+4mkDTAc/HOHKg+lWtUERsdwuZTn1WQOrQDKNFC7Z0S6r4iXCBQBczT6OizDUjcVnMA+ K37vzHV0FXgy//MatKpnLywhAcqlXCAjo8DJGao4Q/l7dyRMfuxGVoWnSwlqvb5daMij93sAJk3+ ufOX5JFdw5yowuOkjchKumPkOAV5SdVZ149dyWnevpOHpJ5GGIvFkp+fn5ube+vWLaTv3r59OzY2 9r333mvVqhXtIbGdTXiqwOpuNGlCQ8TNzKytJ09H+fnW4jnlwrPtwqagBYUm8tTNtSRZ+8MBkvd/ +GqJvTPXfo+m55s4l9RlPzV9a9OJrH23btGxrRzFVfDHyvN+bP+++LNnS+8dHm3DwPX6vqkpwVar 46eRJPfJZCmeXlDFdQV7C8uWjZECiye7Rs17CJgs1sSp7zluvCzXbm2dvJqw2Wwnrt98a0BfP1eX R+99H0zrP+o1bdWxl//K/LoPVVkk/eiPQ1//Uhf4xsXd71/78d2ub33X7ZUPVy9b6CmsQ48Tq9V6 8+bNo0ePJiQkCIVCNzc3Pz+/4OBg9JfDadIunnU0BZ434T5g9oDI2j2nu+yQY6FA2b4u2Bdxj9lk 8nKSr1u3rtZPXqe4fPnyohUr/YOCHVXl0X+4vdxKjU5y+/r1H1et9PX1rf4h2Tt2XHrrLceyPCjo +61bmTJZjS5aK+Dx+SMnTER3jZiYKvH2NOojXU5JQz3HVSqp6YHKS6tf/fJY21Gzv7KzL1Fwol+X yTfQkmsxCXjrl2fP/HnDvB9/j2v34owJtT+rhfp8cnLyhg0bNm/e7OrqOmnSpC+//LJ+sic2oRbR RMBNuB9YLU8DYxjhLCqNQ8tXdqjNU98FZRVtsEkENSpVYX4ejypsIOAAyWSxHbpgDU5Rc5XfrU8f YXi4+gbFF55Dhz4V9gX7iysqLODzBej22VwO3V5zpj4boNBoi9XqDuGhnBrG3pDm3GmvfMrzavbB +6+hMdSkzv588ts3HNt09r8st7m7Dh4Ka7N+z473J7R+8nHWUSogIyMjJSUlMTExKYkq69mpU6eD Bw96eno2Tes2UDQRcBMqokCt8tTpRLVUK1TATuGwKBum3uSqMdTNBDBJEg+69TYQKBWK3KwsiVSG RlhHrVyoSULExzO44yxWswULzowaxRCLfV5++THOUCuw2WwFOTkWuRzDMXuF4PoejopUKhaD0aLm AUjW4tS/062BkV07NqPU371/rl5x6FaHiQtdUjZttdxNbyuLnTS51ysr4zMs4P8ERmilUnnixInD hw8rFAqHeblLly6vvPKKXC5vmtxt6Ggi4CbchyAPj3AvLytRawqlVBjvWChUtiXJOulvJJVE3FoX Z64HKBXFiIBtBMFksdhcLvrLYNYsFvvxDBaSFi2cunSRNG/OfHphoIiA83NykN7L5nBYbA6DyazP 8HyVTpddrBjSvo1UUOMShEXJyTYrIezcW87BjWm7507+XAXwwtB2Zz/9DoozziUktQoN4NBxl+Bm uOag0lgWlVktOLJCarXa06dPb968OT4+vkePHmPGjGnRogW9KVv184Wm19mE+0DDcTaDYaslMzSG EVL+NcdigaptrZyzUthqT2KoZ2g1muLCQg6XK5bKrBaL7TFs6Y+nBDOZ/q+9xqvJzHGtA6nviuJi vkhkNBgJq/XxbuSxL43Y11Muax8W+vgn0ZhQi69uWZzF54NWO71vD/vq34cPSdt2+N923nxnkZcz 5BbrrCB49EhrtVpTUlISEhKSkpJUKpXRaPT29p4yZUpUVFSTO9XziiYCbsKDIIuUagmf/+gdHwUW XcFjU8V2TBaJ1lBnmYbqJjamfmA0GHQajUGvN5tNhJWov8lsDJO1bfuU5w5JUq0oTCWsgDPQsk6r 4XD5DBaLwWILBLxaaZkuL93IkMhkwgrr7+TkZRYWDe/Ugf5YVlwbWCjTA5PqdTGvbT3Zr9CIhCeL YcWH49bnt9/597wod2oGR6HKKgRPCf8Rw+ytW7e2bdt2+PBhd3f3uLi4Xr16OTs7y2Qy1vMVmtyE B1G9VJQmvaJERdhIBpsvFQtoOOrW2ZkWQYiXqEYfCWlDIwwwGI/u8SRhyUxNk3j6CdhlLSRL0pKz GU4RHiKMJMxmG4PFeODqpDrjlobj4+7EbfJJeGy0Cw/bdPR4rZyKzSxkMwuASgHtZSEqDoK1ioZK wOiTsJhMSPuxEYStLtJwVw3saSeeJIEsTk85m5RuIv+usOnlr3cOa+f6pBfQpy8aMszcuc9H8+eJ cMOJnduY4d3bhbshaS2zoKBLZESb0Mcs/STzC+DR6UUnt2WqBweInENFVHFcm1nv7iIDvWdYqJ89 VMuSGn+d4Hg7P6C+GgwGrVZbUFCwf//+PXv2oPc+cuTIX3/91dX1iW+5CQ0K1SLgK//+OnHqKpug CPjRvafMWjS6/Zn/zR92MiT73+k1soykH/3fX0niN14dwX+QOu+HVaf48t0pfZeuHxB+NzjPpt0w 9Y25jLF5f72qu7Ljs18vvjt3gZ+wApeb17/VPD564/efvcBuYuDHBZNOr6lTaFXgsrOYjBK0oDX4 WKw1nmlrDCCRWEraqFwf9kDe+jTDPgvgyp2j5K4cHjczKSE1jd735d48DIn6EOZZ6gOIHo8Nw2mV aepmvUprYkhELJPeSOPwSgV7kkQCDWEDBptNY0l6jR2tC4jiYhZVfuqhn1eUdOZF+/VW6k0Wgmgd EsR63II/bNeYmXHuH586vHXP0RmjujtW4gxW33HvYQWu9pyW5oT933717b/NX1voeXeU0mg0ly5d io+PLyyk3BKRghsVFfXzzz97ezfSJKBNqBYBqwvy3bq/+tP8F67sWz/xw1Ed2t5xdWXiFsOjj7wf OJNuJR7FvQ6g7w1n4eVzFtrHKaATGHUemt7IpOEPnokKRzEri602gCb3wMcFh8XUm0wlOp3kiR2h pfxrOGYlSZpaH2QjmwpgVAK8xMK+rBYmFMgZbDe62ZmWL6JqaFdXN7UBKVAXwpI6bWOdgcQYHEFg SIhvoG/qYUtWmmHg+Dc82JQMknftwOwfr/Vt47zjf3+XQOyCTXPcmYbr+7b/8cOmfIlP3+GTh/Ty 37Ns0Y5z18Nbht26dFPiMnbe6hF47pnvFy26lU0ZEpq1efetKYFnDxwU+nS+9dvcb7ddVivA9u93 75zaGNz9pZlThnk5PUFCFZrorZ/X7XaJW/DmcEbQzfdiKQ0YMFrHPiM6UoMXeXXbZwNfW6L0jlg3 cSxJELv37t28efOVK1d69+7dv3//kJAQgUDA5XIbYQHEJpRHtQgY0RlLKvHw9Hd7aZTLsl/OX8kZ hKHOBqqirGuJaUzngHBv4e0bKe5hzWQsihSV+cnZGjw0wE+Ve+fqtWsn/t2ZRW82f/4HstAeL/iK uIiCSaIw5dbF68l0kTwiKtpNwrMYtUkJN/J1BpGrX0SAZyUkbS9KKGJRWhTPs9Wrb7dy51mOb9pi ie4iLLmdmqeJ7dTLzwkvi2ItTLmy43TqsBcHiDhN89w1g1woDPHyyFMoa4GABZQLtI2kK3WP7+ry fAOzAW6y4SaCBlY6mO3/6NUnYKQy49BQQ7DuAsMwnEVn4nA8Q2Hw9KTmjwxFqtx9fy49IHTz5Clz dl1OefPWP8tXbzkoDQjF829umDc1IOZvXK1SFOZfOGF0lrDS0zdcuBGbPnfh8QJVUHQgw2gi6QqT Ku94fkHbhGxGtJOLu5vNpDexxGyRuEVoWN/Y2Cec/2Y5d/rl3NbZ874hFKbydwKUO5WloMigszLi +r506q/v13xyOTY29o033mjbtu2zHDhEVoan3ainBserdGRnKwvNr3WfiWqRU76qwMM7zGpSIyku N5vWsbkbHARI2fbK8F1nzlzh+rb6Y+OyJVPeYfRd/NfH3Zmg+eGdIec9hqyZ2nPUmNezjYLYUPGR pJzJJW+adi34IaPXD5+NNKTFfzR41G33YEyRHj1h/qq3Bvy2eMznK5N8WsmyUnhrt69r71XJAIS6 eeu2YSyApP9+GLbQFH/0/c0ffbhL7ms16+WWhIg+a/+3bBTQaDx3N+2Ng+MmTlF6DRk8pP+D5zlx 4sRPP/1U0yf13XffcZ/TeikPItzL67+r132cnZ6kw7GZBQJOKlqwElyNPqj2Wvc4sFgsNSwwblUV K80kLpFJ6I9+CEjJIWm0Z1GbcQyjNdK0rGaDSq0mcZ5Myq/G67dZrUCnP9m9YxiLR8fLcZONpLTY 3m/P6xFq+OWH7WJrzt5Dxz26jH1/ytCjPy36+x/SWUBPsc+Ytx/x/kCfjI+W7qLjTKcQDAppNty/ 96t9I8JD2MR1tAPTUxba74MFnYr+N2fKGUbnsRO7zXzpBSa9FojQq9UL63YMot09FXrOiYmJR48e vXjxokDA/2j2XF9f3+Dg4KD5859lN2ZHDyEI4ubNmwkJCenp6Xl5eTqdzmg0Ql1mPn82wWQy0cuS SqUeHh6BgYHh4eE8Ho9WDrWbM7VaBKw1qX/6dPzGOXSTUT9uyeZePtwLaG1ufI7k/bOXv5sc0vpC gWRiR/nLX405PPxOW82fn/6nnrb2xYJjaw+mY1//9uub7b3vXL/j50L+759NhFd79D5Pbvz8il/X 7euW8Umt0sIoOrH8zTWJi37ZOKG9fNKIscCgmQxFOSl3HmyJXdQ0XTm6iyxoSQAVVZqRUbj81y3d s5a/tz2XsjxjkJVxcuCYTSmFvrv//EjOq2TMTUpK+uWXX2r6pL7++utGRMDeXjaCQJ8g/wkGDlfx URy3oIVidXOr7ak+Okv6CP+46RcS27sg+c1268TOZX/sRXojT+rs7RU4ZPRofzHVT66d+Od4QrZ7 UGy3TtHKI19EDl+GVuLt37q8+TOfit4GFArTLt0u4neIDTbkJrwxecOC7V/52r8ns6Zw/ptvJpqc /PwEZrMZ2Gx3F59ug16KDXCu39umkHpp+9rNCZ98/ond8UK/bfHH25J1LBbLydm7ebvOA7q25tAx vSLrwD/7si28tnFdWwS4/DL3pWnfnwQ6e8S8X1a82YdNf2CssWp2bT3RYXhfKUDO4aU93iNPXf5Q bKfg9MNrOo75Z9CLgSwWFc/KFYnkXq0nTer/KAc8XChl0ehQlgYVw0gMonoP7eDHsM1ZEWfIvfib whQ3uL+Pu8yDK6GBGkzaW0YtgH/vl3oJEn41EdZMrW34/PWsn75ft2H3qoTDbaYsn9LRfirKnIDh NAYaPFXpuS917Szh106SGQQHG1oDDwAAIABJREFU+2ZmZm7atGnz5s1oiBg5cuQnn3ziqGz/7Ift oneUk5Pzww8/bNiwISAgoGvXrpGRkYMGDRIKhYKah0c/B9Dr9Wq1Gr3Qa9eurV69Oj4+Pi4ubtSo Uc2aNWOz2eidIjmeSptqx5PTcHX7R9wLL4/q3rFZmw4twnzo9sL2IAn5bvvnofJ8NpIagD3ovQXB 6zr8OH91vOEnz4i2E3pEOmX26OJ3ccWY1j8FDV6wYGEYneqqgvBQJuTv3XRh0Jvb3OUCHARiIHZ9 8Ufz5h1H9YrmWHPoDJyBPj4grQwWg1FRrLZfGKcRBL19nNjuJ9Sq2+Tx3aNz11sIm4ly3rAaD/2+ Usy0cPq+HuRcO5EMjRCoY/WJbXE5JTXSz5fxuEYzD9l+x0KuonvtNe1xQFpMBSqV1mQFoOI66DRM zinYumEf3b9tgMuVwLiBbqaMWZOGnNGHuQpZxOGjOqdv26gKPcK+2LGu7W8fvD55XOC2bRMrdCZd 7rnxPdtwX1rcuvlMi1GvKk5RW0u/JxqT13VAD9O5xMyjey6wvPo05506mhvQLK5SAiaZmJXHsPBY Rj7PwBPqmWI6g0fDqm2CJklL8sOqI1gM2kKNzl7hCt0Axka8qLi85VhRx44xShuzS7sWmfEbps// zsr1YmLknizrnjlj9Rrp4u/3xXnkTJ288kD7qIEtPSqc88Tf37z92qfzIzXjw/jaohyV2mxCsq+9 yULf2Klv5GWmJ+3YctR/xAtemVduXIExr/R/dD0C++NNTlG0cXe/u4pALIyYk82mWVk8Ph9uHT95 gxualJljA01esZ6gxoMAmZAOSLYwEabUjLNaPS+625RZkmXLfi84tlXVqh91GvS+y3nJ6/Q1dl6p APTM0RidkZGBlEWk8t65c8dkMnXq1Omvv/6qUUbupwuNRnPy5MkjR44gAu7Vq9eVK1fETy8ly7MD 9BDc3d1DQ0N79uz5wQcfaLVa9Ih27Njx559/xsTEtG3b1svLCzExy569vEwhfuzLVZeAw7oNnDCh 391f9s4cMjrWgwMmHKk2SVkFtJ4t1n31aucpnx82GN/d+o+/gG7x7bN1W9uMlNvbP+u++At2m1Zf g+MjtWoy8xjePnzc4TRFWnQ6DYsuYaHPxIITZpsNSMrTytnVlf8wX1xCqzhDWFoOHiCmQ7HASW28 pUbDAM7sPW7+Bz2JXqM++7ZDzJw3ejOfRbtgA8CANq2OX7+h1ullwscRhJkMhVhAGQAJG7NA1a62 W1czmIszL937hQe2G7yoXU/GjWDOxOUzX4yi4bYTXy//drfgfP7Wls5swmLBaIzUW0ZGqJNfWMu3 pvc/9k2mhbj/WzHlfTV1xhF2i06pRUj0wxBVyHzLqgTRWNweI9/oMRJO//XZn3cCln40ioY+mSq+ UoJPNwfydIFSZahrkZ+PTe6kF4mqbzFGZKBf/rBxs6QgJefeL07f978Ja7vpuurQb9v+JyIRvxnX LZ7Hjfjgx2VTeTTS4phNFoLMyyWsfXTn7rs0JmPFM6oT5i35nU2T/Xc2dXxYJA5Gumcr4d2HI/GP nT43llCnpqRPn7twRaz9GtUZn+hsPoa7eLqVqspW0kblNrt7JFce0GVAm5+3rLrzn9igUCK6P/zn TZJKXWkCG4g8vcFq0efc+eePzTdKNAIB02whouIGiBj2kcpS+qjQwwYn17PXb3R+3OgjRFqnT58+ fPgwIi0/P7/AwMB27dohldfFxeVZntytANRnjh49irTeli1bjhgxAul2zMqiHhzG50Y+E8zhcPr1 69e7d+/k5GQkryxduhRx8IABA/h8PpfLRTSMFGLaExQRqb6FpFx+ANKSfkVrNDlRq1iiDjFwKbfA CrTIl74YumbPH+rJ7/UPwM35kyJbnO04fkZH14QUAF8lGoEsenQWDJh+vQcWrPrigxDWtAtbV+wz tNsyaNA70/b8vrWLU9pff/93veXNvJg2NMBo98Ue2KuSOlZQ/teUlkwUAkjtE3uekVF6w2293oxG P6+I1p1e6HhkRXKXNWtHD+8YJq9obkK97TFkvcaW7hyJdh3Dw3IVJQCPQ8AS3g0co4ZQpTbcStRC To8nAUmaH1xJ0NgcN6nd5omHdeonEm7v4ie3eoZMnfLph5MG6NVW7amj23/NmzhlRZ/Pd/FoNkeg kN0fg7yw/dufDrD2H1uwZM7X+SarHPVrDu3BMQzDTRmKNKuNpNGeWuex2UwV1pAEYIFe/NIuzWnR f9BnH33q8uNspw6Dv104f1CbIGN6/tXTJ1SHjnxxtuTobGnpnVOmJxrYDL+829HqMmPluFMjNh/V vRpJsRqfWYF8EOnSsJTzmcpYsbh6d455tH7pf7snc+/6/fm06jFnfQe/u4kocCa/33vftB6aVqIF Ny83dept3CNMYGtdQnCd0XP36rD8m0XC4ObO747ISs3QW0Dq5S8XUgdv2reXzpNR75gjGjbli34c J8Kmr8nTs1ksSEPQnT17FulA58+fb9++/dixYxHv1tCl4FkBUtbXrVu3c+fOVatW+ftXnhvH8caJ u7DXOrE1Whp2zPgixXf06NGIid9+++34+PjJkyejNQ4aRoTiUIUf4+TVIuDwlt18ncs70eDecT1e jwuzT+vx414fQxIGKhWgWaVSiBZ+OZoiN6b4nbkTGYeS9x9M4rV9Y+bkmW5cVuc33/H28MSB9vJn J/UrV/7x41o222fG2P6+3Ty/SbTs3fEbiyeZ8f64AoWWxvTp3K6HmF2ui2MMv249nZo7I2qIGTF2 YmEER+g9ffhIkT91NZo0sG10C5LEQ1uPlzdzQ998y5GfLE37odIMhaPteIyH1dgg4vHO3r7j6SR/ jGPF/ATHgkLTvFYb9ZigqIZxX29n4rjo7hgqix2Zk9Y5JS0z5daltSvmLLBisYkXMc/QA6dg4dqd E4a2Orfxl3+uJ5pMRK8xr3fwJBZ9vT1LeWvGNFP6udzL+YYelPtVJZ+f3L2ZO6TUx+09FCw0Otwv PjqzWWXN7fb6N4n938vOzzuz/+/3Jn8cdfGnrPzraVcOK2TSXb/MbekBf8z9JMFCWCy2t+Z+XrDz u3c26dmSFQtzhESaLlP7Fr2yNMd0riSSU+MCf+XBEbkEVaytR5N7Bjj6Ir+Zo1Ox7wrXrMC27R1L nsFh5Y/hiu4WesJwmW+AkCBuZigeeXWr1ZqWlpaQkID0HqVSqdfrPT090Zi7YsWKBj0zWlJSMm/e PKSvb9q0SSisZF7ewbvo9s13geQP9NNBw2U6cb03/OmgzPPZXrGahkQuxLXr16//7bff1qxZM2TI kIiICIlEgmjYoQo/BgdXi4A79Bp3n/6HMdoOHXs3ix2t9YQ1UTYWF4e0ixtvcUI/a+GgalabcfOi h+qNFhuTjXR16kItX1rS0r5N6B79/oLvdAYjncHhcijNYfT0lUP0BhqTw8AIkw3nsOjvzH4L3e+9 i+KcYW9+AAxKqg3qNuNTahU54bPFGJPyEqK7dFj5eQxPLAqb9TVJo6aO2UKPt+d/SnvmnSCeZUT4 eJ+5dTs9v8DHpWbeQzTcIOBQxGMPQAp75P71AByPcpeU11FxAiwlxRoAN8KovpxU1LKZfzOJW7Pm rXk55zYXFlhNWMdXPl01JoxBuS4QXs2iO8t96HQswEOWc3PjddJ37aYvwwJcdn89/9ilnI7NivS2 4squWl+39zBwnIROjHIqOE7H87OLHJO2psKkS4X8duFBrj5BYd4uh/bNKDLR+PLg9+d+1TFAyqDj QBoiu3R1JXE6nSYF5dLte6LGzf9kZHs3keb1zmNuZyid8m6A4IEpBgzg2TQYOTx+bbaqil4j3t27 d++RI0fQqNrCDqTouLq68ni8hm4DKyoqmj59etu2bceNG1epPylScx3UazAYkMyB9H60YDQa0Roq U1tjVYId7Eun09lsNofDQY9u0KBBbm5u6GEuWbIkJCSkTDR5DA6uFj89eNLyfRFn8h2ZXw6vmx/R Yam3W5mEiLO5/Kr8Q+gMlohxL9MpTqPzS0XLUs58YFoCY1TMjIqxOGXdiC6UihytKdtKb5g2omcH zmJRp4jwjUePIxlPyKuBGzOLUeJIAW00OxlMbnXWwOrCpNGSNkby1fjk3Bu7d+8S+vaKdFefTywx rP0sYUvglKld5k8a6jF69cSOXnfObp289MSsH95i7QIa6kClESY076iW3lGOk5nXfPBhj4Ebxg4b xMGttjYBfb7+c9ySUI1BdePGjZLb8fv+XMt58cfPh1FiKA2w3CyVlbCxnt4EoVGtURfREy6cvHHp +B8HChd80PnYzj1F125Nm/q2X/TAHqy/R885OGvpzy3dsM3rlp9g+QTwKTM7g7p3+1ePcaK793Sc qjBxf1KKeenKqR3cUGdQDY1h7Nl3tvONEgtPeencmbTLxw4cOzdp3o/tAimjFJKLz1/JfTPy2fLr QUOZQqO5lpYe4+/nWGMymTQaTUFBwaFDh/bs2YN+Is1m2bJliHefblNrF4hEV61a1alTp4kTJ1a6 g8PYjuhWq9Wq1WqkK6O/6MkgJjY5UqXaUc/Nfupw2J8RASM+QgSMxDKBQCAWi2NiYhYtWrR69epJ kyaFh4c7ngza0+EgXf3z16KCiId0nCmNHsJrML4ITXg0OkSEZRcXp+UXhHG9qq8BsBjFXFYuUATs bDA/hdibCmBw5H27cn746kup3MnFq3lzL9qVm7kth021c4xc5hf7xaKvfvv3+LpfLCyucN3GvwbF RaSSk8G/0kxJeESnOS379uBQXxm95YsTP1beEDr5d3YnFn8yT+rs5OQf169F6S2LPZq9NtGDXY3k 53UHZzdPS/6hJStuOcnl3fq3M1w4lY+5Txjhh4YJJxkvsOfiFZpvDh/desUKcv9uhz4ZKwVm1xde dpdWIjmzeH6T5i2MdXJsEr28bPWpApm3dFCLLfu/+fa8zEke1q6Pr5NdUMPYnUa90qtHQL3eajWA FF83mVRroGjm8uXLV65cycmhfNTQ2BoREbFmzRrEuw3InaqaIAjiq6++Qt/vmDFjKt3Bwb5I30Wk W1xcXGSHQqFwELDDEN04NeAyAkbaLeokPB4Psa9UKpXJZNHR0SNHjty6dSuiZNLua+ig3hpxMFaL z5Qq5ILhDdxO04SK0BgMs37eEOXn5yar7qyer8ufkb5L0UJGwaArqbPr2hxJWK2F+Xmndu1ct25d 5XuQhE6nB4zSaSkzEfpN2nDsPic/qlCIjcRwGr00nwZZpePy/VvsKZxtRiPlBkFVtEWsXu1vAHFA 1+49fAMD/QKD/ENDvP38kIggqKEX9P+WL1u55MuqAmBsVrPeaMbtt06nnMFsBAn3GWBJ0kpY0V3Q aGjgcLScrOYrQ0eRhFlnMNHodEd8ZI3eNDqoTefOgSGhfsFBbp5eaGDjPnHytYcDUdH+gwcTz58r SE/r0aNH7969IyMj0QCKBtbnOCvkjh07fvvttw0bNlSaD4SKZLOzr0qlKiwszMvLy83NRQtICUZi isME7ZgDhsY0AeyAQ+twmKAdOTqEQiFiXycnJ1dXV8TEa9euRVILkmy8vb3RStSXWCxW9f2ia3OK 9KkXV2lCXYDHYg1p33bvhYt8LltQvbwccuF5x4JCE/1MTAZiNB5fcN9vrKKWgygKv29d1R/Q/Vuo XxjO4dYtczw2MMBVBw9aNRpJy5Y8Pz8ah1PRI5uymzEqHlTNk2OA0ZkCQe2U7qgLIMJQKhQlxUU5 GZnJt2+lJyfz5fKRw4dPGDmigbox1xSISnfu3Il4oqpsXIhcEcXqdDqk8ubn52dnZyMCRhqwoyax g30dJtbGxr4OlGWjRLSKyBU9KL1ej56M1UpFeYwfP/6tt966dOmSI02HIzjYoTRX5+RNPkpNeARQ z4uLjMgpVlxLTW8R6M9+VKEkDLNKBVccywptVN03sAkPg1mpzNi0qej4cUFISPNvvhFFNZY3kp+b c/vataRbt5Baz+ZypXKntp27DHvl1RKTKcrPr5GwL8KpU6eaN28ukVRuvnK4PSM6QWqcg4CRBlxQ UKBUKhHTlOm+jXD2tzzKONhisTgM8uixOGZ8EekiAt6yZYuvry+Xy3XQcPXzZDURcG0i/9Ch+Hfe qelR7bdtE4Y+07UKkFw3umvcp7/+cSc7J8LH++HGOgkvgcVQogWt0UtnbKqz9pRhLCgouUSlIUHj B+tJ6v80EKiUJccPHDjyzx6ksHTq2XPA8BEisZhOWd9Lx7pcjdZCWJ9uI+sNiDh37NgxY8aMh+yA 6ASpdFevXkUsgv4iDjYYDI3T4OwAGt94PJ7ADplMVqbLIkJ1xGg5TAJoN8S1iHQDAgKkUmlKSopY LEYHIg526MHVUYKbCLgmoOq2AlZ1zn1qLkWtrvFpiQZQzQZ1qDf69Vm7d3+aPSqpqigOBBfJUcdC dnGvZ8L+3LiR9++/hE6HFkSRkaznsd670WAozMvNz83NzsjIyczQabQRzZtPX/i5m6dnpftTJZdt jYJXEH1euHAB/Q0JCalqH6Tm/vvvvwcOHEC8MmLEiMWLF3t6erIqxps0LiByLSkpQYS6f//+M2fO pKamIiZGtAp2c71DKEFkzGAwHDwtFArDwsISEhJ8fHwQBzumgR2uWI9UgmtAwOqrJ0j35iI5D0hC GX9GLw5195c9+rAHYcpL3noElzvzfEPkQZ4NaN5YG38scUd29Pwxz5uXZPXg5SR/sUPbjf8dsxBE sId7pX0Lw6zO4rOO5ZyiXvXbwCZUBGmzZf39t2PZfdCghh7JWh4mo/FWwrWrFy7k5+S4uLu7e3kF h4V37NZdIpPhD9U8MBJsjUOxQ1SxatWqiRMnVmWyQorvzJkzvby8pk2bFvpsG+HqE+hxyexo1aqV QqE4duwYeoxowZE/0REtbTKZkOyiskOr1UZEROzZs6e4uBgdJZFIHFkqq6MEV5eAycJzR/uOdZ+w OGbBSNDmp674NCt/oPPe9x5Dg9ac2HhjxnIcCRRWEyt0XMtfP5I41WmqQnP+/p1K5w4hMY8TkGrJ Pp2wNTPsreFsGliNBYpTFyzQSAkYDd8tAgPkIuFXW7ahISzUq5KyzXx2BptBpaTQm9y0Rr/6b2QT ykNx/rw+LQ0tMGUyp7i4p92cJwKiEys1A2dKvn37xMGDCZcuhTRrFter96iJk2oW8Y+B1R5R8zyJ I5VCrVZfunSpqspviH2nTp2KRJfZs2fXb7saEqRS6ZAhQ8LDwwcOHIg4FenBqNuUcbDBYNDZ4evr i37m5OQ4OzsjPkZKMIfDQSryI7tZdQlUde4QIiNtyRWLaRhWUqS7nQEZpzWm9ySV2SosJfk2lpTF rfyrYHt70T38gld8x8g8nvXzb/HvQoffP2NVpQiTNsJkJjEajcXAwGbVW+hc+yWtFhtGx6tIsUsY taqbCTa2uzTUG8wG5ZHDqVxxUJQzht2zCZCEyaQxsUTChzwfkiA053blbz7j/lJ/pisPpzMx+sOy G3F9ff0nTap6e+VAg2NND3mK8HZyGtyuzf5L8WkMhq+Lc4XuJeAm02hUtZkSbeRTamADA045d9g7 Zq2njyLJzC1bHIveo0Zhz2B4KwZU4JM9319Vu9gIorAgPyMlJTsjQ6tWI8VXLJV26tnr1XemPF7M EovOgMahAd+8eTMuLq4q9ffHH38MCQl5991367lVDRHBwcEbNmyYMWMGklp49l5XxsEOWCyW9u3b JyYmBgQEOGK3HJHTj7RCV5OACeXVa+h/xjwtokAy97omWw9wWV1skrhTdFiwZ03a5oOExc1tylve 7fzvzJigd4nFdCUE6Ro8612x6/0KLg4Yk8H1DXZrEyn29Y1/96tcBeErp5myLyZMXWRChNRqSNjU sTw2EtKyEhYuUt7MQsc4vb3Ux/PWxXl/hP7wi0wMKZ9PwJvP8hkUXrz35+Sf/iEAZK/OCujbkgaW zN++ytp1Wp+Vx+49LnZCxMX3vjWkpxK0W6cv/+b5/oc+HUszIxrv7D8/ba+8t7f69G3J8NeCBrfD cUJ98ciNRWtsbLFw0MTwgeHJ38zOO3zRmlt487XRSa1fi+iDxAfQp528tvh/hFdc5EcTOPePacLQ 0Ij586v7VhssOjULF3G5Px84pDEYwry87qaLQoOoTcBOoeFU9n+ltr4zUP77779du3at54s+IdC3 SmcyWEhYZjLpDCRQ4hj+OBw8atQoxxxVeYhwfFhmphAJxCQ5beNGw/79tdHk2gS6VaRTUPdOp1UY qZDqUJifH3/2TMKli0g8CQgJ8QsMdHJxFctkHC73SZRXCxLprZbqRjo3WKAHmJmZGR0dXenW+Pj4 ffv2/fHHH5XWQWrCg2jTps3cuXORvIJUW0SrDs9wgiAsdiAyjoyMvHjxokMhdgQpVSd1SfUI2KJQ nCvGBCJrdrZJrdUf34V5e+A5BdoMNbhJCjbPOv/JTkGvHsR/e1J/E7k0/8iQfTnvvzssqYTUqy7x Rd0+f7v8yUyF+ZQjhNli0RrNRXlmdaZZbyWKkuLfnKkuFom6uRSum6N3btHxRebJ7i/pBF4eYzpn Lf6ep7UaMxKUlxMIAn045pLLl7j+OsPp1WffXi0e2BfXn05aukgS9hM76dsrc9fzB4xx6WQpSNQA zYnl46QvyrGRIjzAlca9FwlnLc5WX96jy5YzGKCYNovTcrcoZ+eFd+aS7HacEE36h5+59NqMS11J tgBoatw9gBPkgkEWJP15vMMOlpvUuv+/m90Gtmj3/LuVPggWg9EqJEjE424+fvLYtYT24aF0Go1B DaJGITeJ8kUj+FpDPdqfMYzHF8xe/nVuZlZmWmpOZkZxQYFep0MfBllZNY7av76JoBdaMNO9a5E0 zOrMJLmPUDqZLKaXr69ILOZR+dzZdDoDx2usp7785ltqpTI/JycrLS0zPbUwL0+jUiOpPNRsopso YSibRkunYherrIOLGQhGnhnuuibZuDSrCxMeSxSoJjB7aFCrTp0EQpG9ngyLRqNbrYRGpVKVlCTE X7p46pROq23dsdOoSa+5eXrWormY8vu1NgC3xycEGvpzcnJatGjx4Cb0BJYsWTJr1iyRqGK9iyY8 BK1bt46NjU1JSXFEJZVxsMMpOigoqKSkhPrMDAaHTozW0x9VjKBaBGzOS9cpC6Wzv8Y3LlKkXS/a ds3z1dnKtV9qzicSgexL0/5wmbU6cvIA5drRadk+dCYONL7zy7NjZo3R/vfz+ZW3raDO/v5He11R nN+8FzM/01qYm7xwVpohW3U+UTpqjp83S3XgrCrXKWjpOM2Ov0AY7BwmUxz6XVfiEfH7L15BppJl P2IMqrAvhkdzBKjNZsqqQqhuLviJ03aEc0tp8faTbK9QtohtzE4DoZtQyOQF9m89NpwlE8Qu/zbx 05l3Mtu0XjKu/NjGcPZh+nSIXP+Ns9xw9YM3chLyjEe30Du+22bpFMPx3y/kJIjEfKfXP/Hp+vvB ievCvvjSSc5Qn6PyGwtHzms1p/f18S/rbhVCoyRgB4I9PSb36bn77IXjCTcQGccE+LO4RiEPETCY LFKdqXIf1LoAZq+Ux2Kx+AKBVCYnrFY2m2M0GJAQStZX/CLuaWUnaHHt3ZGdALIYN8m4VreHOZQi 9ZfH4yOtDv3j8vmOCMKaUg06hMFkcHk8kVRiMhnpDIZIorOaTJF5uZzCQkSqxVKZs7OzrSoOs5Ks 2zpGuaqFxiCB1bluFSM0fjHZbIFQIHVyRkycm511/XK8VqOh2VNqefr4jJ/yrouHx/OXFbLegOgB qWKVUiyiENRnOnbsWP+tatAQCASIg+Pj42X2ScMy7dZRjEEoFDryZiP1tyx79iPPWS0C1ly/ps9k hvftqL8qTZryNrCknh06084sLzhx2jCohQXAaWAPFgu3Gq0YTqc+c4LO5DvTGTSmiw/DcAm1QqdR ak1sOpvH4TJwGp206JSn94FCxwqLCZj8AgMJZUadrfDi7Xeu8ga+0XbzF0JvScayXGtAV9cQOVgy bOUnbezDCHVnNqNJYdPf+TUxO8Rn6uLorjFsMYs3/ItwbGPG7+tz/9ruN2152OtxGNUmBplZXNEW gIRwT0+xixjHLTQuU301CTsVL57yBptOGuynv5eUr/zcnFvvFl+M5dKVOJWxvjoP73mGq0TSLSbq wp0kNpNpJQgOM49jTwFtMssMpnqMeLHnnWGhAV0kIggrUisRn5lNJiSd1mfACRZuFW0vpClK678D UimTaVpficW3yjoWNDqNxeEguUEoFvOFAiaLRdXvqqG2RxEwg4n4WyqXo2WBUIiGANJoDMnJQSey oFcTGOjn7lFlG4rNotMF2N2C34h6VR1c67yOE3pldJqisPDS6dN5OdlB4eFI2e0YHi4Uidls9sPd mJ8UJPaQILrnBogSkCpWac3BW7dude7cuf6b9BygQ4cOK1asKPtZnoMRPaMHbjajgcfkqB9VFrP0 EFSLgI152VbnOGcZOz+gmU15lhXdTRLgxu/bOX3NMW1RNPrIdTfSTBIXG4tn0uZYzehLNhrzb6vT g1WHDprpfByE4R8uKDtbSaaZ49sn9u9Fqp0rU9buujB5ess1SykPEZub///W+QSLzHkJCZ+dpLO5 eH6CIimTU3zMYLE4S3lgYJPWs4qbGSDUW7VAjTwcYPv3jV77oYBHKk5u1/GCRIRW2nmYW/+Rye/F KtJOWS2dmAwmx5+Lna1kUCNVCnVqmsGUpkvXyF4KZtwOIJQms15vzCu2qfONZpLBpI6y6kzGXBXI 5KTZigQdJGoAgdMYuOHYFWJseCMX0fNLSph0eoinB+JgF/Fxxziu0MTYyPqbW6ISv9HpLDZHICTR sI6oCH0E9tTO9Z0+niHxlWzMY+Tc1SYNQJykK3zdzUHcSqcckRiHlFcmCymBXA6Ph0SHmup8VIIe Go3BYvH4fCRSoodgMhqsQV0jAAAgAElEQVSsFiutqEiqLEE7EEIhv2VL36qq2JIgPpvDM5ZelGRg Ra/4SLyqqmH2RCBtNqTjalSq4sLCgtzc4oJ8pP627hQX2aIF0t0pCzyDUQ8qL4mRtJqbGRocHAbS Sk33+fn5/v7+lR9WkgPLPgG3EfBW73s99uIBWL4f1n9VkS6sOjh+ALb+A1YB9HkB+rUHRplkY4Os RNi9E87fBq9oGDkMQtzundBmhJMHYee/oMSg+yAY0hXYNY2nISHrDmzbApeSwTcSRo+GIJdyDdPD icOwdz8oSOjSFwZ2B2E5Q5SuGA7vhV0Hge0GA4ZCj5blxE0C0m7A31vhRib4tYLRL1aoyOLt7Y3U 3Eob5DBKW+1w2KXJu3jIBEq1btuiysJbtGRiuDAimCliCga+zGUB2aozMfesSSHx7tc8c/50TZST 8r9zVqHFkKdGBFy0+6eL13aZM0u8P1tV4RoYg0lYk00Wvs8rc6XRcddnzju//Gi3aW2d49anzZ1W 7MrX3zxLbzc+4vV++qtz4ie9xcJzCaOZ6ynk8TpyjMtuT3uDQTPoEkkBiALfH3d16ZobHxWiNdr0 LK+5CxI/mqyTxHDlTN01rkvPZjS7m7QNPTF9JblvyIRD8e+m0Swa3D0uoqWXPr/Tle+WWq7t19+8 YM4qSTya17KnG9gIoOEYk7oJc4nSzBLYk3NzBf7MgkvnzcSoMj8sm9Wa9ddfupQUUbNmbv37l3c6 tVksyqtXzYWFklatWA/4PJtLqIGSWUWuuGccrUOC91+8TLerFM6Sk46VRepKZp7qDo4scQwGA+Nx 0SDO4XIR+9rHn3p3dnUjmWJX+feZjNy7HFwCHhstJeN5+jaiB1VbO33idDpV/Y8q42CvJ1rT+U4q JR7qbGy2PVctm7DbvjgXL+D2BC9kcLA0OKQqrZqZone9UoxBaZ/UNxfZ2tT+5H1JcVHSrVupdxLR 7XJ5PLFU2q5LF3cvL75QREc3T1WwsBdyqJe4ICaNzmoEeSgfInoiCqk8M6U6Fxa+B6vTYOtH98jy 9j54fTp4jqrEKLL/O/jgN+g1AJg5MPV18DsCUXdLn+Vdhynj4boMRraGQ6vg9DX4ezXw71LB0bXw 1lpo1wtczPDJFPD6BzpUIRBUBaMS3nkZciUwoD38+wvszYTjy6H0rdpgyyoY/SGMexfcTTBpDKzc DhM737uj37+AL4/CyEFQcA0mjIfT56BM4kw/B+PGgTkaeofC9vmQlA1r5gH73p2LRCKk5kLVj5e4 i7IiwQ9HtQhYPmhqLDhhgInavRD7Zyt+cDDVIu+eUfM1/PAg7++2eF2/qtPTopYE6pPTuHIuAEs+ YELYa/0xvpzvVLEgqKjftHYxJoETpSEJYrq02r7bCiwWl9H8x/269CSd1sZ18+bKRXQmTfbTdkNB btGeLxK+dBXJWTRui05XTxffyqJLnczJp7DAYHlQ246dRqszMgmMI/D2YYs4tiPnim/cNmgIvm+o 1M/Fzgs0af+x0XGSB28Vi+3TcvF7lOrk4sbiMQTDZrWLebGkQCnynUPmJVs9qZYz/PvHLA2W+VFT KbJeY7p3Ie1vmen97kJmOpNVTl6/8803SatWIRpGVECYzV5Dh5ZtyvjjjxsLF5IEIWnRovm333Lu 5uhBazK3bLm1eDF6nyEzZ1KxIg3NOIaUCSrrGk5jMwpEvNtAuXgwkAZcz81wTJ1iVMJ09D7ZTzN7 bXup2ctJ+kkSI+suBxeD7Gd1gbPM0LKiPRC7C6r91c4f++BJKCXYniwekZm94jzBPlUqDGHduouk 0sqPJMF1exHXXBqkQHJwywA/kaTWKvjqddqThw+fPHTIoNO179590MhREqmMZs/SV9psKvaKarzj xuunHpFDXnnug4DhoSRRuaVh9wZYkQqJR8Hv7qSJPgMGvwbi4bB+ZiUELHaHr3+Cni1BmQw3XgBV OdWQxoC4d+CXkSBgQhc2fPgvmMt9jwIZLFoL/dqApQQyLoFKU+U9mHVw5DR0iAP+/RY1jAFDJkOv l8BVCO5GeOc8WOAuAWMg9oSt52FADOBmOPQbpObed6xXDGx+E1r4Q/YFODsUNCYquMUBOhN6z4ap o4DLgNYGWJsEVhuUu3P03IiqExc6SNfh/Oz4WzsmaL5fmOMbxeg8SfjdrGYYy2voKMeipHkbh0DF aYlGXj0JdIbMnR8QVGmYLsaQCH3u/ULKpKMv4GyeICS6vKUMZ3N53v5G10AMUzvCMxgSD9d29tms kFKJiSl1lkvvVZzFha4ubSvOPnJ8wyv1CMJZAr6HH1tY+moxOksYFiV0hM/43DVoMGUecbK7+3PK crQx3CK97k/skfnnn0jTRQs2s7n49Gmvl14qUztuL19O2OWmkosXFefPe9wlYFNRUeLy5abCQrSM FtwHDWJUZSp8hoE6Gho/ncSnMWrGHApUbW1kfaeycxTtdFTjrOdLV4IQnu5TpvOiVGbqXcdjBXCX 5+XP5RljhLUe/uKgcLCPDqWrrl0FR0pUVzd2THOogtjYlzWymzYalL4sQ4gAb+3C5T3+AzQZjYV5 eYX5ednp6TmZmcoSRURM8ykfz/bye4ZSspgtlkfv1AhhK4avPoKBE2DvWuB4Qu8e4MGHv76DjAwY 5g4bfgCPaOjbFjjlukf7sdRfpIxuXQsZGnAuJ186hcL7oUDaIPE0fPk1uA+5z8gcOwZiUXdRwz8/ QnwqvF+1zGc1w/r5sCEOFr0P3vJ761l8eNWecSHtEmw/DqE94N60CQZ9R9sbpoadv8BVNkzyu++j 6/sy9deggI1rQM8GWTkXDY+WMLslEGZIOAgLlkPzT6CGxbzLOLia+9fFaIXTmDii51o6G2ktySXd o9i1bTRCXEHYoBZtlNI2bbK3bnUs8wMCyhv96Fyu2b6A0elYOfMXabWaFQrHMrXQMEuOEPZ4c2fx acfPPEWj9+/AwBgpyJsb4DoviZlmdKxj5JndZicVzPTVdZbWbQgqErrPlmYDhS6dq2JfjCD5hxU0 1T02Ur3oTIgfZ0CwWq2J1xMunzuHeNfF3d3N09MvKLh1XJzc2eUZLLJLPqzSZCOG6jZcRkNVCtxm wP6V8MNYODUTbhQDkiFvX4XbWbBlHsz5FRb0ue+otCsw82M4fQXm/ACBD/DozjXw8RJw6g8rPgfu /T0h6yYsmAfb98K0HyCqSg9B4Irg4y/ho0HwwjWY8xkMKVfLizTCjtXw2WpgBcKmNysq6EQhfPI2 /PgPzF4Jox+YEUv4D6Z9CsmFsOhncHmAWn76EpZ8B/5vw0fvAavGfaVGdSzqgoDZ0RtPW0FQRZaq mgJ3mfBN73E4vbadM9h+Pbr81I5Ze6VMY5YvR38VZ8649u3rP3ly+U3NFi68Mm2aVa937tFD3qFD 2XqGSOTap0/u7t1o2bVXL1r1qu0+a0CaJ4epEnKTgSJjZrG65dNu0TMADMyhvJwlwe4zEpnppRxM U1iclqYhkqP04LqDohiSqGAwYLGgdduq9sJVVsG+oru+z2AK4mh7Vjcjm8PZxGI2p95JPHHw4MXT pwLDwrr16z98/IRHBj4+dWgMBgx75sSCp4/0y9ChD2zfBnI2nNkCL4yH5NdAlQd/nIVRrakd5nWC U9+Drifw7o7FRXdg3Atw2R/OXoCw++2OpBlWTIbpO+H1L2DZZGDd3yt0uTB+MJxxhuM3IKaCddIA 04fD94eoRbwfqP6CoAhoFQWLbkBmOUs1ScB3i2DaVzB5KSx+7d7ssgOaOyAMhuD2sAfdVGDFO722 D4a9Anmt4OJWCJDft8lmhAVDYPF1mP0tzBlRg6f3uKiTrwXnSmrVBRavi4+aym4pqs1xEGcwWqxc Wekml+7dO+7ejXRcYVgYXi71DJ3Pj/j0U1nbtqTN5tq7N94ws9IwaDSDOYFBoz4PrcHfaqvTzN4N CVYvTuF0X+fFqYzs0vlgepHFZWFK/mx/Y/Pat0WXIjMT8vOoBV8/EFdh3CNBsi6bpir1TCSZePHr Xo9UDG02m1KhyM3KzMnMLMrPVyqKeXxBbPv2Y19/g9dApk6sBKHUaOXChtHaegWDDTozaM0UAduU QAoo4QynQVpJ6Q6WJLD1vM9muOdbMMfAjQ3gwaPsLuX7T8YFWLEPPv4JZr8ADxov/10GRf5wej1E OFc8EFgwbg70mkLN8orcQJ0Ob7wCN83w048w8p7qYrd7/wVz1sMnwx5ILGqD378GiISNf0Jzd3gw 59lfP0LgSLj4DXAfUFITD8HSo/DNXsppq2LDHhO14AXdhCcFhnG9vNC/B7ewnJ19xo6t/xbVIga0 jk1I38OgUwSs1gdabQ1Sj68TYGCIFeUuCnL9tJwtOtvksiC56H0fXVzd2KJv36YmgNE3HxgIVfAi M1kv2llY9tMQLXi4Uq4oKrp87uzlc+cQB/sFBfkFBYdFRUlkci6P17C8mdBoyGGxZE0E/CACOoHq A/hzN7zZA7YdAefBlHbo7wOrPoBu/wDjOvxhhMG9KfU38zKoZBDhBem3waqBCS+BGcmXTvDVN9BC Bucugl9LUBaD2QiZB6CXPWo2uCd8OR04JXA2A9q0hJQbQOTDzImg1wJIYP5X0LlMT8UhqjWUWZqL kyBmIMwbAWH3K8o2AygUcGUbdP2eYsqIwbD8fTBlw+lc6B4DRZkAMvj2fUgvACYf3p0P/dFF44F0 h0AXyM0AiwEGdLVTrDus+R4CaHDsAkS2h6JcKuzl+C+waR51lbYjYM4k4NWhz3wTATfhSRHk4Vyk TscxC0niaoO/zdYg9fi6AgbmYF7u50FusxEHl/pkMfLMTsvSrWKGKUpQ+xwcH0+NLAwGRDSDSp1d CVK8Jb8scaaNjWt7SG38+/a0WiwGg0GtLLlx+XL82TPFhYUt2rUf/up4Dx+fhsW4FWF3gabqMTSh AthBsHAWTP8AltqAGQ6bFgODBZOmwpbjMLAVpQqzX4H5owAzwdieEPQqrFwMkZ1g3S7w9gBnHty4 CNkqCDbC59Og51oY5gn+wXAqE9qEg8gKty+AwQpZ22HGbvj9d4jqDJrNgEkh2B8yrkOOospWyQJh 1rRK1tO4EOkL6SoIDQK6DQ5fB6MFflsBn/4EF9IgqAX4bgCtJ0RGUqLAtSzoFwZje0H32TB/KkS0 hgPx0DYMxCy4cAoK9CDKhJlvwjvbIS4I/Pzhpgqim4HIBBlXKeftxyn5UV00EXATnhR0GuHnSiXp JGwcjT7oaTfnWYTFn1vwkZ/L5ymMzFI9mF5gdvs0qWC6r76jpDY5ODcHUqjJeOByIbzyehjMFAPn vKrsp9mfq+tUGhVqMhozUlJS7yQW5uUhZZfOYLh7e1PZmL28nv3J3eqAytfGYqJ/T7shzyRGfQAd h4HOCC5eILMbCUQBcPwYJGZQXsdIG6amzlnwx0FQS4BNgxc+pf6VB2GChSvAIxCcuXD0XMXzS1+C Va3Bmw9BH0Lqh0/UVLYUfj1dceW4qRA+FLz44DcfRjxQFGfjASDdgIbB1JUw9f5NVhGs/AmCfUAW CtdvPVHDaojn4aNqwtMFDTd7yikCthIctf4Bl4cmgN0vOkaQtSrU491bZT5Z9Hyz85epBTRM3/4J Qm8tZsjNBTd3cHjX//MPWO0zu61ag7DyVPv8o4p7eUIAlCNdzCL8TsK1EwcP3rxyxT84uHnbtjGt 2/AEAjaH85xlY76eniHichtDIo7HAc4AnwcSYjAEEBFx3xqPaKjKbZnGguatqzw/2wla12XyfIE7 dHWvcqtv1ckJ6Dxo16HKrXWJJgJuwpPjPxpOxeDrjN4mS0OqbVzPIFxYBR/7u3xWTg8uovyicxcF mYN5j6kHW6yUTe/GdYpx27YDPtJU/EGlgp49K90d1xLCHYUkCVowKEGXJlEdSbuSOO26UCRu07nz qEmTefzn2YfOYDIPbtvmabeiCU0oRRMBN+HJUVr1Pbek0UcAPwrGKEH+LD+XL1LK8mQxckxuMxOL PnhcnywWC6QS0OngvyNw9D+QycDDA+RyKCkBpfJBL2jZ6gx6ofkmZO2G8xwGhzY4JKpVq/7DhgnF 4oY9uVs9kCTpKW+SEZvwrKCJgJvwhLAA7HYs5Srinm5TGgAwMLYQ5iwLcZuRyMy46xedb3Zakmbj 0Ayta16flUYDuRP1lyAo36uiIuofotL4eGCxITwcunWHqChgU4mCKOfn7ZTzcxC4vQ39rJHSopEh NnFjsceaLVaCtEn4delU04Qm1ARNAelNeEKcA6BKUym1Pv9d1VqslRS9aEIFWLw5BZ/4m/3uxWvR iy3OX6Sw49WPk5vNxQUqTGoiJrZYQKuBc2dh8RcwYzqkp2NWUrijAAjqAnSgcWhsYze5TdRY2Bch u7hYwGYzngtvsiY8H2gi4CY8IY45/sdlvUDD8BKt7um2pmHgbq5Ks++9DLaOXJW8o4oac7AzIuCq 3XpFIhg+HDw96dlG3ql7zs9WJ6a2h6xuk2I+SyBsNqVOF+Xv+7Qb0oQm3EMTATfhSUDYNWAKTEYf mUiorqJYZhMqwp6rMndxsMXtXtZ0KlflsnTm7RoKMc7OwKhCq0Pa3vQZ0CkOaDTeCSUjy1i2pWS8 e+MxPgPlrEbojMYIb++n3ZAmNOEemgi4CU+CbIB0+4InQMDQDu0UGo3OaHrEQU24C4sPp+BjP4vH PQ6mFyI9+A7nnKoGejDScSuNOPL0gk/nUek4ELWXWMSb88q2mIK4mv51GRDy7AHHMTepRF6r2Wcb LdSF2YnZ5bNnkEa9TmGHUqk2GE3EfaW4SYvZZC2tNGPLuXN5B8LufRdvZVbo46Sh4L9//kEb/zt7 TWWo3mSWzXL2xN6rOSWP3vOZRNN0SBOeBJkAWfaFUAAJGuCaB/irdDoeu77LET47IMuhOvtrYrim hX4u85NZ6aV5srBsq2z+7YJpvvpOkmpmo8V9ffC01PuaIZcTb7xJZaO0z8qL1mdAgd4xpJF0rOhF uQUIqN4QV1rs8G7p4mod8+zBZiOREow3lWGoBRDnt6//sTB848dDHL9Jc8mXC2btPnQJqG6CM5is roPf+Pj9UVw6KNKufPP+nCNFJRhO7/f2VzNfCt36xfz/s3cWgE1dXRw/cZcmqbsLNdyd4c6Gy7Ah Y8jYGPZhg+Fug8GAMRyGDBvuTikUaEtpSy31SOP+3eS1pS0FSmlpC/ktC7dPkpv37rv/e66cM/NI nA0/DUgujWb9sWdYo0IRUied/XbUdLbBkEFitPt60KqF/3NgvsdlismgPrFvI7mbc6iTzbuPfHr9 FMmzqb9LhYW7rhCsAmzlY3gJkGNJ+ANw8Xi8LZdzL/aFUqN1s/uyDCyMi6dOHvhjK5VKff+hJUC6 5lF8y1bLq2y0wuF6F34SHq/gcJbI5ZIF84odVPTzD1he7yMvL++nhYs8fP0ICCIRveGRAle/CINl IS03h0GlUt7WV2/lQ1BKxQrx644uHJHRs0tv79pt/lkyRhXQP8zO5Ghnh5pqkrTbA/t8FZXdcMKP faUJ/24/93zK1355udLOq/buHeJ54Y+f+s/od6dtbDOX/OdFq5Z71Rt19OgC+fMzg3t8f6bzgOHt g0r7fpPRYELlEH2FCSX1+Qa3yahXa41UKrmURqJJfnD2UG23vQt/bE/EV6NGpLU4WvkYrlniq5IA agOYXSbV9/UVSWV3Yl84C/iEmllTlxssEPe+fftatWr1ib9aHBFxo1s3LG3bqlXLOXP6+VaAT9A1 a9YIRWKuKJdKpVFoNDKZTCR9YIDy6gEqo5liSfs64YxytI2slEaxuR54SljzDmGgfbBlsnvv4VO+ yXd18vDY7zfIPSMitvkJaAATl6BNBnMELh6PhqewWnXroV9wSiJRQoEACyPvgckP3S17nyYN/Kk6 gx6JqjD2wd9Hz+sJtMbte7QM88YZlHf27z3+JI7l6PX1gP5+fDyBaOlvM2jvHN656XTaiu3z2XkJ x9fvjgVwDWzSp1fbnGtnD1y9fO5lnuHkJoLo+pBpcwK41cUX6ZdVRVqpaG5a3jEBNkMlkzrWq4N0 KFsqfcdpnyXoV5uMxvcfVwmwAgIww5TfqFHosmUsnwpzCJqTmZmdkSERi1UKhU6nM1bRD/xIxDK5 Rqf3sLev6ox83uh0Csu8zAKY9k6aZ//1HjHg51/m7Th+RaE3GlTSpyqpjyMtNzVy5sQlNIqPj0uR UXmDVm9QqqTZp3Ys2BnLFthyRTEXh3fuM/PkrVtn9w+YvkGk1r288u/k8ZNfSuQX9q7bfP4+dh6R Qku5f3TC+GmZfB+6Mu2nKRPGztsT+zJi4YzRC/5NkKmyb92OSBfqJVlxNy9EyDTlWOpXWVgtYCvl JhHghSXBBXjtLZZCJvVo0vD47bssGp1OIdfcUcMPxmIBV8k3E+l0ho8Py9e3zubN+Ar13pwhTKVQ KXqdjkDAE8kkEolYcs1xTUAslws4bA97u6rOyGdD6Q81Dkmo4fXMgpAe8y7u9Dlw/v75s0f2/7lq ZO3xyXtHq4yGeZ1Cl9HoHBubDacvBXBfa5DRQLl3aUNYre00lm3fvgs7hPE29uikaPRT9h+/Rv67 8KejGjrBtPPvdR4TNx1YOFQtz1OayCaTFj11l7fMPnDoiO3g6f8sGZh+8+8rF3TH4i+r7x+6fzuK AvjwrsNOdh12cFqPh/ajfpvarVp14VgF2Eq52QP5U3W7mGOkFCHcy/N5UvKdmNhmtQK/HMf3xqoT YITfpEn8Jk0qVn0RyPxF7SgiiURnMOlMpoFa84I9G4zGTLG4bXjoF9QWrFSMpixlnqrUPUAgE15r CoFEbdF7FHoZ9aqo0+ub9Z99/ol5rsLYFX/1CnH28ve359KLnK2Pj7xXv+ec3yY2tXfz9nYRELQJ 92/we+/5lssgkQhUXycKwZgW8UA3ZGxbdDSVyaYio1uhkGdnXTkSHejjIMeT0eMnyRZJDGnLR3WN I/kNm7l2fJf88BJ4ojnUr7nGqk6lwNoFbaXc7ClIfFNiB51CGfZVW6PJKMzNLeNk4M+DKvyxTt27 U+0q3sKTiESSXJFCJtOo1Xq93tzHXtNuaJ5SqdJomwSWHpzRyodiMhlylbnhIQ75fxuUcrnWkiLg QV84tz730R7/WhNf5ZmbpHgiGbWD0NNBM4smeDZs3rhh7eLqa/4gqTiN4xvYqElDP6S+5g26PINR qjIvXufY2EtTpDqtQphn1JEsU64Mer3RYJ6DpaJtuXju5MHNuLO/Tdvz2Ig2ZtqMWnUy4vjuWcNb 3DpwIEtZfcdNrBawlfKRDIAFzuQAlOICmkQgjO3ccd+VayqtNugL8X6AlKnqxKmSJierVSr00mo0 er3OZJ5saqpmJsT7SczICnJ3o3/BS+MqHpMp/urJTTm3o6Mizh34173LtGHtWMdPXbhyL0cxoNm6 IdT2a08ubcugak707iTu36t2dvSVUzciGw79o50Pcw+YaKXP5MOZqIDTm16XLprbNwNcfl85lS3s ePXg5kuv7J4oZvbtpV3w45iXPVtdPXGE1PKng1Ob44Dh7MD28v9q1qQx/UeP6XZpQZMGS9f8OudJ sN3TK3+9JDbc2bWXHZ1sMuksjuurF1YBtlI+7hYkGpbofy4kyM21X4tmh67fTBeJHHm8T5YzKxWI QY8MDZ3BYLFfyrq2uRqBcqzWauv6eld1Rj4fcHhCnXrN7++7futRjrNb8ITV7es3aWtIe9K4LaVN t2/4JIICT/RrHGTjKziwh3n+5sMskYjj0/zXPlPbtmnOIcjHTZod6lpqPAxiqzGrBYZaRcSZ1m/h PsKe40l5mi7fzvgqN5dEIA6cvp/xz78x6dLmXUd91bMlgcL4+rsR7g5MINA6fTdpBd07MLTl8i1/ n7n6RKI0NO8/f3q7bsE885znwJa9mUzf6jYKYRVgK+WjUIDfFYLQzc7OwcbmUXwCi0Zn0qwrQGoe 5mHt19pb0+QX4HlyCplIdOZbQxBWHDhiu28moVexjSGeTTuWPDCgYTv0Kr6N3bl7yRGrAvBujYaX 6CtjOQQMnxpQfFvQsO+LLQ5u3aMvlqAIvCdMtuQqvMP48A4lPj2446jgt3xxFWIdA7ZSDqSoZrMk 6IULkEqFTaeN7dKxnq9vZEKiWCb/NJmzYgUDtRwyROIgN9eKC0Fo0mp1pTdDjDqN1lDqHitW3obV ArZSDjIBEiwJZ2TlvvtQHA43sHWLM/cf3o6Jbejv9+VMirZS5bzKzNLodCEebhVT6kyG2Bu7pi3c 0XXGDh/Z41wDgWTu0DQoMnMC2vfUnp8/40DCgo27m/sLKuC7rHwZWAXYSjlIL4jB4GoJw/AeaGRy 90YNUnNybzx77ufs7Gr7hdZQ6dd/HbaecmD3z2yjZOGP49g9ZkzpGPYhH2CUizKunTt1Ozrd1iOs W+9Onpzq4tCnGqLSatNycuv7+/m7vr+IlgVJ2sPp40eeTxE0THn4x9D+kTQWk0Y0W9k4/EBJwDe4 jIhrZ3+c+vM/f//uyrVO+LJSJqwCbKUc3AXAAtsFApQpvAyRQBjQqvnt6Ng7MS+oZLLtlxiURnl8 +Zx4UY8MsZKEz3xx64zEtv+bAqxRKQlkGpFQylwRecq9sYN757l39eLTRI8uOTRo7skpbWqbyWQ0 mYP/lCFLJoPBRCB8nuNQKo0WGagd69WpIJeo6jPrZhxLcZ23fvfIerizHOCHDP3fQG9ZntEtuF7r Zg0d6Fv/yFKOWHF+38Vn0/rUqYhvtPL5YxVgK+XgQkGiednXpNhyOJ3q15UqFHdj44I93BxtbPBf lLNoVc7l85Bim5OWI7NR378TnZflHYNaMVR1zp5181bsi6jbbuS65SN3LxidSvNMO3HO/off5g5u S32txIbHx7bvueYcmbM+jE82GgxmzwKgPrxs1qJ9lzwafr166c+qq1t2y/zJD/4+dpm0eWvbE+cJ c6f3U6Xc37Tz3N1X52YAACAASURBVNifp8X/u3bm0j25Pi3XLJ4bqrrS5S/lYNrdnSeujf/j3Lf1 P0MXUfHp6QGuro42FRP9xpgdOWndpfCvho3o3oggukfiQ8aDg8uSKToDcHiCoAt3HTj8HjPXtzvl +9vm0xP71LFOOLRSFr6kGtBKxaAEuGVJEACafdCZJAJhSNvW/Vo0ixemx6YJ85RKvaEq563oDOYg 7Z/mu6SvHh1U87kaaVJ6+tMz//Drt2IkJYvUeZsmjJ/7Z8qYob0itu2OV0JOWsrOnUfc+3W7tGzZ zbhMnUajVquUShWyVIPb9Q0Jkveq62cf1mDknC0vs/Our/5+ztHIqT9+d/vIiqX/xWcn3l08ePCz HDcf8v3LGbgLt04Ixaqnt/+5kqqRPtrUZsGx9lN/rPNq7aLpe4XJsXdXDTv5QtpSI74ZJ/k0V+BT kpydrTcYW4UEV5T3K0VmfLaOFRbY2Y5NkWcLUxKAwWYGdho1uHFYdFTkbytPakxAZrk27NBNevFB qjUitpWyYbWArXwol1B1ZEnUA3Aqx/lNawXacdinH0Q8jIvnMOh+zs5VtUJJIlc8TkxsEhBQ+V4a DM8vXYTgKbMHZ93+b//lC3d6z9qyZ86vt57E/Jeat+fCoRB84n+3cz3pAGz3VTt3fd3UiZIhzMpN XL/0l0eokWKA/23+KzDwq/t3bqSlZ6Ylxe5ZPf+3VQbjqRscz4b/HjjfqNPwYQ0d1YfAp+e6Hbt6 PToeate0XdahAxExT5/+fr7ld+sjDwxgM4Oentif6TBs2PhOdM0+hk//3//YZniwL875czN/xXJ5 THJqy5BaTvz3xIgtOznxiUAi012ciDhgOfj1Gvt98IBJA1r44qXPLh4+JXn1XKnrRSHinWwcqXA6 R6b3oVirVivvx2oBW/lQjhUkBpbPJxIeh/NzcZ7QrfPsAd8o1JqIly+Ts7IrMH9lR8BmkQlEiUJR 6d+kk/9362WzYR1bhvhe3bX6kqhZ968ad6TIDlx8JjOx3LlkwJmDm5r99MhJBJM5zKnJoDfi+COW L1u1as2mTRu8yPKbD55SWHwvv6DmX/Ua06eJKi3hnl6b+ow9acWafduWBbJ0WgO4tAxg4inNe/b1 53HahfhN7Nh6b45bz65hSrWJIML3mrjy6OE/etfn63QqvKCVPYvk2Xpoe793ddLK8qRZ6cKM1FRR To5eXwOW2Wj1+piUVCKBEOzhXsFT7vGAo5lLPN81fNH6NYNb+BLNc6CzowBIJCbBMliA12tx4M6h fYnqK02OTZcU6U8y5D68/0xpBPGzAxN/Xh6XlVf8cNW5rXObItr1XLH/5tsKVs6zf8eNmZ4myfc8 rREl/7t7x479p4UlH1nxhl+Gbzxyp9DnZPTRJb+sPKaqNB+UFdWz8iUWFCsfgdISAxgsJaf3e459 O6j4kohEHos1o1+fcw8jnyenZIglLBrN28mBTPx0ZRJlg8NgpObk2NtwKzV6sUEjfykXDWrv50HX 8AQCu25Dvbk2bTo5/HDiYWuuZsnGnQHExGc39u+NnAnG6DVr5j87Sz59NG/DD7ZcQb4Np86K2T+v 1yqfkd3C7VOeXdl4Mnbmmo1dqcIlL7WPr529tvXqiVeUEW4GrQf2w9D/hEad27I3bAv+YVogh6Zv 09wtMjvx6Y1tN7YfPpn23WAeyAxlcatBIpPxeHxudvb969fuXbtKZ7LYXI45MAODYXmZE1QajUqn 0Wh0LEE1Rw6usmnAqDGHfleXhvV8ncvTPfM2iEwSGHTK7GydCbLuH+3ccGbfzXOb+XBPb5+rBfAK CKbgwWQwpublqoBT0RExagJG6dauDa62339sRSfsAc64teOr/uv/ffgkYc209duS1+/4vV+/wYO+ 6dW2SSidjEdN0qt/n840BDVzytk/p9fBiPlnfh3DpxR7BuWpt4cEdz/r1WW8Ru8MIIk+7V6/j294 Y7ZJMn7UtL9uXvk6TIAzL82W/jFryA8rbkxd2sdkAoMqe+fKaaPm7Ow2eNMnazCWW4+tAmzlg4hF jU1LwrcsC5Deiw2T2a9ls5TsnISMjDsxLyJexrNpdF8XJ1Ll12HIVHopTFeo1Tq9XqPT0SmVqBl4 Mqt3/zEh3kwWKWj63GVOzdpQgNhw8I/fcsTdmvW6dO2ujOQ0ZfpEhlEnAYaTg4ONo+uCv9uGer62 TakCn58XbTl55WFaWjrDtdHff89uUdsX12gV+/CJeLGM7tt69ehOrNibWsfXN4Xv12DughV1e9Ul AC687+aljAP34yQmhs+M5SPqsBOn5tmU5eGnUmkCewdvf38vf38nV1eksngCXqVQKhVypUKhlCvy pJKczEyNRq3RaLRq9K7WajQ4PJ5rw7fh82x4fC6Px+WjNB8JcyVc2mKge4oEuI6vd6inR8W2qBxC m9XSyiNuXciWdmE7+4Y3xM8bNxD9NJFI1GP8wh8nNKfgQKNMeXDqHjT6zukLXIVkkL5INpkdwxcg S8vCmeeJ4O2dfTz96/0wps7V/b8OO3JgyuI1/xve0dz3ioPGY3/aMcQ/4fKaFpN2RY4a2Nbv9fkG ZebC2fOuhDf0oABWF1BsvFav39KqYzeuKXt8u9rHTz/tHdaKAIZn//w1e9OzAE/0eWYV1CpECUrO 6B4BGSZtpbpuw1ko+mc5PsQqwFY+iCjUMLUkGlfgh7raCtCrtrfXnZjYuzEvbj6L1up0wZ4eTrwK G8MrSlJmVkxqGhnZ4HiCn7NzWm5ulkRaqcFicWR27wHDLUlur/6DsY28Wt1nW8IohzVrW3jkIuB2 6DV0ePs3QvfgiW5hbcaHtSm2kePSY+T4138G9i3qow9Hthnw7Yj8PwisZt1HFZkyF/i/WvCh4HE4 GoPBZLFwdu+pa5A2C1NShMnJr+Jfpl9NFSYnpaWkIEsaSbiji4uzm7uTm5uzqxt6r1hVFsvlVAq5 cUCALYfz/qM/BJJt09mTfAes3bTpWLffvu24++rNCbciVCSGg6tfgDu2GEyyc1qPf15mzl3RkVnN HA5/MnBFms04PCYuJA9vL56d3ZAfZk2ZMmvT/JHfj+jkVE88MgCUJqgbYI8jkAV2AjKZwKAXFSPj w/1/7dl1btfDu4fnLcB0lOYQMGJ4gFqWdfPUPwcScEPd2EjENZLs1VtWNZm7cbDu8F0w9zjTbP0X LV65e9Dag5XvOhWJLirVBAJq7OGtAmylstFZBFhjmf9cv8I/nU2nt69TO9DVNV0kiktLj3qV9DJN SCISPO3taRQyHodHDVzWh9fXMpUKc2Ws1GhfZWQiI8kEJiT2znyen7OTl6NDfHrGXxcuV5No7Y4+ /n6CGh+4gs5g+AQEoFfRjSqlQiwSSUUicW4ueiXHJ4hFuWg7hUIhU9EbFXtHLxqDnt/LzTSnkOrT 6PR3V3Do/krkiqjEpObBQR72tpWhgF1/OfD93QGrR3Wy8xNObuLYsHXbIjv1/83vPn7bi87jF45r XbcSvrzaYzKHITQKtYWjrka9Go+zo1sCH+EKZht9N3VxckL0j/0Xd7486KFamntmz5ormVuXbGg6 cqmv7evohOLEews2bm+38GgnJ/puldFQqKT6V2PqNT+SnMqgBE3+Kginkx5cMP4/WfjFkc0fL91g 5OkLPkCnlAPV3Y5UOcNKmO2LSS+RSCRYKFxU+UFKbBVgK2VHAvDE0qxEhqlfJX0HZg2He3uhmlSt 0z2Me3kvNs5oMqECjirZAFcXLoOOSr7RZASzuwk8SqASTyOTVRotUlYCDqc3Gs0O4/HmhEypep6S gj7WaDSh58LXySnIzdXFlu/CFyBRx77RWcDnMhkimYzHYlXSjyo730z6mUhlVnUuKgUaklI6w8nF tehGnU5n6bjWaDVqSze2WqNSy2Wy7Iz0PKlUJpXK8xBSjVJpIxAI7Ox5trboXWBvL7CzY3M4hUEY RTJ5xMt4P2fHrg3qEStn/ILpELLwyPHeT+K9/d/smCHUG7z838by8HqN7NhfYAc0UhJOrVBcNquw 318b9/AumVDflkmSwes1DkSm3eg+X2049nearB/6M/rKWbxfwM/bDnbp2I5PKdAtffrPPQacisoM 0P/W+ZThefSr4X26zPv9WNcQPhCcfv33dL97J7t9++vODddNAYd/XH3U6Og6qnfXnPgncnLSQxPx 3IxuZNBplUBxtidVWlcEqnOQ6JJIJDKZbG5BksnEck1esQqwlbIjAnhqSdgDVG58N1Sc3exsUQIZ qZ0b1ItLFYoV8pdp6dEpqVjY+/z4PDjzhGGD0Whnw80QiVHNi8eanzgwW8xgwgHO19nRx8kJ6bcT n+flYP/mzFgqiRTk7nrs5p3WYaGFqlxVsDgV4ziipkCywHhf00ev02VlZGQKhVnpwtinUdfO/YfS KpWSy+MhPUbaLNLp6wQHN2pQFx2GPhDVhqQCULpiXL7g8Fwn3zZOvqXu43s37PwlxzzEM3zCWUcj 74nVXWypeENe2v6zGewekwUU7a37JwDyh13AqItPzMDjmvEtHc4Ttx4f4v/GEkQis8+kacEypU6n lKQLsyKjHd39GXSiUpQjJzDd/ELc/PxW/T33QkI0o3f/WasDDQaDQqF4Zsp9pOM153PMn6sR37oF +C6V1QWNqS8SXfPMQ7p5/iGVSkXFrMSocFmwCrCVshNr8QINlgAMjp/sWzl0ej0/H7VWV9/XJydP hvnuUGm1er0BWcFanU6qUEanprUKqeXp4EAmmVu9BAKOQiIjbUaKzGOyKGQS2dJV9LavaB0S/CI1 LTY1NaSiJ+9YqRCQnDq5uqJX0Y06rRZZyalCYdSLF446nR2ZePSfI0qlsqj0Ygkmk2ljY8O1gCXQ O+FLnKxceRBbDJz1Y68VW/+qN6xbwztH/jibwlz+bRvU2lWqQK2ViPNkNIop9vaZGZtON+ix1hKi F3QGDcCbPgBYnUaO62RJybJinjxPWbpqdZA96eSUKXNe0lfO/Y4uf3A2geDU0MsjrPXk8NbYOUd0 T9zYw+aNbmFS592PiAEvSLtzJzopJMTdtsJ/KmrPoUKFdBeVKzabzWKxaOaZ/+Vpu1sF2ErZOVsw raEZslE/8XdTyST04jKLdc8aTeZ4tSjRMjSYQiSSy7vuE504on27FUeOaXX6KjeCrZQREpnMt7WN zsp2DQia0rOrs8Ac5APZQ5oC1Gq1VqtF72KxOCMj4/nz55kWUDorK0sgELi6uroXwdHRkfQFROuq qDWsJeDVH7Z6RvS0hSN2rhCIsmiTlv8+sDYfQM+393yxZ2+nZlcoeJBkp7s3/3bvpu50dRSqTOxZ 75vSYTTiZAazc3Mcpcl3gx0adO0bcZyoy7XrPmfdpK8oRX4HiU4ymszzQ9W5Sb/N+unYUyDFbjjY tWVlCDDSWmT4cjgc1Izj8Xgogf7EBNhqAVupJJDO/VeQbvuuAz8heBwOb7FjyjE5qwQMKpVOobxI Sw10dS23kH/G8KKjnf7cbqxXHzd2HFSP62MymZ4lJaMbN6xdG0x9wdz5QaBbeO+56enpKSkpSRbu 3LmTnJycnZ2NDBoHBwd7e3sHC3Z2dra2thQLVCoVG/BD1GidRvlXKpUV/7kEeo+J69oPmZur1lLJ NB6PawkIQuy88ErMNzcu3Xmi0Oj9wlu0aBRCJxOAEX72ShSSrXd/JMs+8MjF40RLm5gX1Oa0XJKe mqYDpptLSVntMm13ewMQcMBwDjl6+UnF/zoLKpUKFQNk+HK5XPOcBDs7Pp+PBJjBYJSvSFgF2EoZ iQVItCTsAcKrOC+VQ78WzY7fufc0KbmOz5c8mlc6Do8eEWQy/O1bMHJUNRHglOzc5Oyc8V06lSPA JbJUnCw0bNiwcCOynvPy8iQSCbKYsXekzVFRUboC9Ho99o6UGNW/tkVAdTGt8hc6VwjIbktNTa2k D6fZ8N/0D+AZ1mxkWAm/8Tg6vQwOaHE4ErWoSJMdXTxLPZBAqKS5d8VAjTYktwILqPCgJhpKoEYb NgZcjg+0CrCVMnKmoP+5A2pDV3FeKgc3O9tBrVv8uu+QwWi0jgRjEMwDqQQ8AZ/euAnz0gVj4yak co11VTixqWkvhemD27QK9nCrqD5VZD3bWPD0LFbLI2E2Go3YO5aQSqWJiYlInu/du5doISEhAamy t7e3j49P4buHhweTWe3mtKNcHT9+vG/fvlWdkZoHao0h0XVxcUFNLkdHR5Tm8XjoFqNbX74pBVYB tlIWjAAXC9JdqjIjlQybTmfTaEmZWS62gg92ionDsW1sRo0dZ15LozY7hELmEqqzsRnblZPfygWP x7t6etIZDAqVpvDyymjThsuzMTspQz8qLQ2yMsHLG9lTnzJL6EqqtNrcPFmWRNqtYf1mtd7wWFIJ YAs9i/YxIjPIzc2txGHIaEaWZUpKCnp/+PAhErmMjAzUfkF1NL8ALM1gMGgWsDm06J1CoVTS0Oyb BAUF/e9//xOJRCgzn+YbPw/0ev3NmzebNm3q7u6ObiKyfTH1ReYvKhvlm2lvFWArZSEdIM6SsKkM FxzVByKBMLhNyx3nL4rk8jreXh/0UKEKNKROXWc3t/SUVGFqSqYwTSISq1Uqg15vMlaaV/jKA4ej UCksDofL57NYLCqVRiSRcGZ3KDjIyoKN6yEuDjp3hiHD4FPZxEaTKUeaF2NZija4TesQj5ISWLVg s6yDg4MLt5jdvyiVecVBCq20oLKAJZBhjep0hwKwQWgk85Whyuhufv3114sXL162bNknU/3PgLS0 NKFQ2KdPH2T+ohuN7g6mvtg6N6snLCuVR6xlETCiFqpnqjgvlYyvs9PMft8sO3w0IT3Tx/kDVlvh zKtliFQajW3D1Wq16Jlkc7gajcZoMNRQC5hMIdPpDI7FmTO9aD+bTgtyOZIXkEjhE/40c7dzmrCB v9/Qtq3JpBpQd6FKmWHB0fE9BQlpcGJi4gsL58+fj4uLi42NRdrs7e3t5+fn6+uL3n18fFAC1f4f n7HRo0d369bt9u3bTZo0+fhP+0L4/fffQ0JC0F3A1h0hKBTKx6gvWAXYShlANWw0gNSSDgFgVHF2 Kh8mjTqkTcvdl648ik8I8/Qoqx2MwxGJJBqNzuHaoFMYTIZapdbptKYa2wWNKhcKhUpnMFhcDoNl FmBszjk4OcPwERATA81bABbEQqs1W8YkEjJSY1PSiAR8xQYjQoZvQmamUq3u1qh+81pBNUJ9PwhU mwdZKLpRrVZji6aw94sXL+7duxdtxDqui/Zgsyyw2WxklrEtUN4ZXAQJxpo1a+bPn4/uab169Sr5 x9V4cnJyVq9enZubO2zYMHSFsfnwZEugsI9RX7AKsJUyoAeItLzTAII//QrgKgHpx+iO7fddvZ6Q kenjVCY7GD2KZsWi0QCPI1MoqDrU6fRm8xdMn9JMrEDMzm5JRDLZvAKHQqNioQmxHVC3nvmFIZXC 5k2gUcP3P6SaTK8yM5sHB73jYz8IkUyeIRal5uQ68Xj9WjTzdXKs4Ci/1Rh02bEFykU36nS6wo5r LIGQSCRIpJ8/f45EQiQSIcEQi8XJycljxox524cj2/r777+fNWvWL7/80rp1a2tf9NuQy+VLlixh MpmTJk1CrRzM6yRm+H6k+oJVgK2UAR3AI0uCYxHgLwVXW0GrkFo7L1xGD5wzn08gvMcOxvyzY/20 6N2gZxiNBsxrZunH63V4AxgoxeQEj0xJItH4ps1tMuH1ehz6LALR+EZOcEYDXm8AHN7wpmmITjTo ccbSTyzLLyJgLufNsaMIpXcGPHkM9+6if0WnTr0Mrx3k5sqsiAU5RqMxJTsnMSNTpVE783iTenar 1JCRNQXMtxeycd99GDKUZ8yY8Y4D0M1t1KjRzp07R4wYce3atSlTpmDrmz9eVD4DsLnuWq321q1b 06dPb968eYcOHfR6PRJjtAt7orGrZLWArVQ2uZYuaATfMgb8BVHPzzdbmhf1KilTInbi8997PM7y OOItgmUqcFpd6pHkvEyffVttc2rdm9NbVfD8shLvh2w5nT7su8TAEja31un6Wdcr9xgSjcy//sve XcSCwoEAE1MY63L2vH3MK6ALMht1SegQqn1dIegcb59zvnKflStXuYfG9+qW7fIhk5axqgVXjFIO 8/QEHx+VQpFow7PncjU6XVya0MHGhkUvpwwr1BohsuTkcq1Wp8hMf3r9apzJNLJtK7qDQ/k+8AsE lURkQL/3MEdHx0OHDp08eXLmzJk8Ho/BYJTlrM8ejUYjlUpfvnyJZLhfv35ubm5CoRA1UOh0OjKF kR2M3rFrhZoshLc1TMuAVYCtvJdzAJjfnLoAX9a6BaSmXRrUc7ez3XvlWmqOyMGGi4WIeBuvJeqd DyReK/c7uNn7SMbLTRONFDJmAjNe3Wo8bZ7RvfcLT4cSa215d/fVW/2PpNvQuG68oI1rQj39bnVp gO0iynOC/lzn/IwXN2Ug9dHJoJWzDY2Ov7LLtxRtHv5Tb/luRcsBCR1dfLetCbnucH1Y13Jfjbeh 4NtG9fxaqVLVqhPeuX69mNTUpDv3ngiFODoDb3aGhGsQ4Id/n5WAZPtxQqLZvTeY1Fodi0Z14fPr uLsOH7Ay+tkzVMetXbsWG7Os8Px/4SAt6du3b5cuXZDGZGZmYt3XSH5kMplCoUCWtE6nM1gmEtbQ qQwfSmGkIw8PDxqNplKpkBKjP5HcItFls9mYL3EESmNLyMDS4inHd1kF2Mp7OVSQ6GiZ6vvFEejm 2qNRA4lCcTEyikmj2jCZH9dHZ+JE/ON1JDFhw/KEQBusSsOrcvw2/UnGt3m4cKScWXKMU+Ueljiz QXzjQB3o+UH7eEZd4S4jhS7uMjppWriISWZzM932nMcXqSRVrrWSf14S3yJEg9PTHh9zNvu+r0iM JnMwjIcv4zkO9j58/oBWLahkUs7KFYpduzi+foQlS8gE4r3YuOtRz0xmd6FUuUoNlv49d3u7DLFE p9ejOp1KIWvM7qUMdCrF1VZgDmiFxzcNDPCwt6ORydN++mnChAlyuXzDhg0tWrTo1KlTxf4EK+gW GCwBTpBhp9Wi+6lDooukF9tVSGHX65cA1v+MLgL2pGODMJgLaHSVeDweap2gq6TX6zFf9O+e8vYO rAJs5d1IAK5bEuTq4wL6E0PA4xsG+KOEWKa49+KFI4/nLOAzqdRyyrBBGrJqA7DdOUe31vmXmduq W0KzQFb8Y9tHT/QhTu5rfnOmeWaM7C/kvX6kVQ7hMQ6AV0t8Dm5weZSV9NXrnlgjif7K4kyRmRgR tG03BLQXc17rt9ou5LkdMrhlHif+9LoQnfHdkHJfhDdRqDXpIpEwV0Qg4Ls2rF/LzZVkcV0ijYpC 74zcnA6NzBkL8/ZMyswyGI0kAlGjN3smUajUN59HuwgEPDZTq9Oj7VQKiUWlIVUWIJOCQqGSX/+E 3r173717d/PmzUiDR48efejQocaNG1fgr7CCJASJLhIbkUiUkZGB7GD0juxgZAQj409rDjumL1Tf L0eDMQpHXrAISEhokRGMiqJSqURXBlPfj5mNZRVgK+/mfkH/c20AuyrOS1XTq2mjBv5+m06dTsnO qe/ny2WWa0WWOoeRDDhPOnh50R+dF8xPlx1fqhPnkmRg4NnhBSr743sED0G6f5iiyEkUSWbI0gX2 1+/nTliRGFrSHa793X/C5m8mOdd/sGamhFqsK4wkFwVtWOJ85ppi0NyXLcLKk+HSUGo0N549JxOJ YZ4eLUOD3WwFhV1w4atXx2/ebNeqFfanE4/nVNzjEqq2mgfXIhPNs7uwCh01cQhvqcKQwfHbb7/d vHnzyZMnaWlpP/zww4kTJ5yc3r3GSQ2XTsPTDAhvAS3emDYoS4WjZ0BBga49wJVTfJ8Gbl+Ce/EQ 2BDa1jO79i+KKgOOnwYRHjp2B6/PZCwGM3+RMYdMOiTAmZmZ6enp6B2lkSSXUN8vGUxlkQYj6cWi bKHLgm3B5kVbXVFaqQyuFSSsXX9AIZG8HO0XDh109NadiJcJYV4eaAv1A0clKWIhnmcfvWRjgjuT 0rV1vWnfuSTnpYvT1IOmXPxhADrA2UUbvnqXjXiQwib/8cSrs2ovmMROd4v76/QLr+KBB4w617N/ hqw/JW06PGpS7zxWsRk0eHV27V8n2sQLXq3Z/7y2x8f89kJ0er1MpX6RmiZgs1qFhtT29uIwioUe Yvn4hK9ciaVR1Z55/rwkKsr1669Zvr5QMHG0xCnvhsvl7t+/v3Pnzq9evYqMjFy+fPmyZcveGnxG lglD+0NEBjixYe50GLQV1vWH/LaBCW4dgNbDITAYSEpYsR7+PgiNC1ozKgl8NwguxYC7HSTMhe7L 4PeRr0+8fxSa9Af/EKBrYe48OPAftPEv+0+otiBl1Wg0CQkJt27devz4cVZWFtazWtX5qkowexfz +I3ElUajYY1LtB2LyWGwgP7E9mIeOazxgK1UOHKACEsCVXZtqjgv1QakuJ3r15UpVcgOlqvULgK+ y4dE4zGQKDi9gSxSgDvTMkmaoyOT0EZytgw7wGjSAbgZiK/NL5v7/9ikkp4tnZHqzjGvRCpiKRIV YofzVxX9JkcMbqPBl3R4yY08JYjWvlg8OzHQtsSJ5QB9QLY0LzkrS6HRcBmMPs2aeNjZvTt8ct7z 59GLFilTU3ViccjChfjyDpX5+fnNnj174sSJyP7Yvn17aGjo8OHDSz9UJgXv2jBjLNSyhR+/gY37 YGX/gughRrjzAOauhuF9gZoDoS3hSWIRAVaAvQ/8vRAa+sDSCbDoCKwbWRAt3ggPImH2ShjeH9gy qFMHHryA1v6fwYwIJCe7du2KioqqX7/+2LFj3d3dbWxsanSwxY8HmbaomGVnZ6PLcu7cuZMnT9rb 2zMYjKLD4WBxU4Okl8lkstls9I7FwvrQrgKrAFt5B0kAyZaEO4BrFeelOsFhML7r3AGp75/nLj6K T0jLzfV1nmwBLAAAIABJREFUduaxyhT3Rm9fS2KT47ZrY67LRLvjf/KlHs+daCZtsGHVTy3Otor2 kwb9/cAYPlzEIlCyov2f62Obh1DkIoJYGDxhYFhuLgBb8tPC630a2MY85hKdkmwNBK2KcWNP29+n W+TA5/mhrfH2mtAzd4Wt2hEVIrws12/2mMB0IQBN9u20K2PLGUtDplTGp2ek5YpIBELfls0a+PmW xSEGicMhWComlMCVK14bBoFAwJar/vXXXzKZbOTIkbVq1WrQoEEphzr5wYpV5oQiHRLl5oVzr7NJ gB9X5Cdf3YZUOpCK3DKeM6xYa05opZAiBoNbsRPHLchPpj6FRDIQ2Z+B+iIzbtSoURwOZ82aNTUl luInANm7TAuenp7du3f/7rvvUHnTarXIxsV67M0RQVQq1ExBJrJEIsnLy+NyuSwWqxzfZRVgK+8g AdU3lkSAJQyDlWIwadSJPbrECYWXH0fFpKZyaHQ+h2WLJOc9CxKYD5dtCt64N3jubAPd/vnE0VIq GXzrxYwa43liVTCeqPD7+skvvTRgcD9zyPapQVg3UFqrbWoLnEngbOCxcMpsvT0TTAbWoyuuhkbx /UIyW3VVx6gNrTqYaDjC82gFEUeSJtkfO6zyaZQW0DK1jdrEdTLask16qdH2g2+iyTz1TJYhlmSI xXwWq0v9uvX8fB1suGWccsL09q7/55/yhAR+gwY4AsGk1yNrGJ1LL+7dqSygszZt2pSbm3v69GlU A06aNGnfvn0eHh6lZVoL98/D4t8g3QQP50CJuyHPgD2bYNISmDALeoSVPPHJDVi1BG5lwI2NUGJQ T5UDh7fDT0tg4BAY3BBqOEhCFi9ejJRj3bp1Vs8b7yA0NHTbtm29e/e2tbWl081DJ6j46fV6jUaj UCjkcnnhYq1yjJTjrKPrVt7OUgDMmc6PAMugZE1mJR+tXh8vzLj+7FlMahqdTHG3s3XgvVvqTCSF nKZUG6kMJYue33Fs1LNyxTg8Qc3maEnmup+ozGWJjXlOtoZSqkcTVZxDwTGk3FIGU3EGDTclXeXo qqZ8VIzy3Ly8pKwcqULOZTJ9nZwaBfo78Ww+xhOk+OHDp3PmmIzGsOXLOcHl8ar29OnTAQMGoHdk fyDTZMOGDSWPMGrhj7WwbAnUGwbTx0Ntn2J7NenQvS8IdTBhInzTC3hFzD6THvZsgUWLwLM7/O97 aBgM+CLXXZsJPfvBKzGMmABDB4JddfeIjiy2uXPnjhkzpvQ2CsCePXuio6NnzZpltX3LwqVLlyZP nozFkYQCPyd8Pt/V1dXbAkrUrVsXFU4sZgaynh0cHJAZ/e5IhVYL2Mo7uGMxgciWKdBW9X0rZCIx 0M0FvaJeJZ28+yAiPoGRSgn19GAz6G+xhnE6Bgu9im3DE2XFA93o6XzxW+cq4dQ2tuq37DMRKOK3 VLtlwWgyKTWaBy/iVBqtgMMO8fCo4+tdy82VWK55nkURR0RIHj9GFkTOzZvlE+Dg4ODp06ePGjUK 2RwbN24MDw8fMWJEsQouMwn+3ABDdsG8N12OmGDbTIgSwYn/oJ5LyZ3SbPhjFbT/FdaOLOWLdy+E O4lw6CK09Sllb00jLS1t5cqVSFSs6ltG2rRps2LFiokTJ1IoFFTesL5oZAdjK6exmVnl+FirAFt5 G6g83bMkSBYfWFbeT4iHu7ejQ2RCYlya8MmrVyQi0cPOjstk4HE4ijmYbrXu6NPoLIt01eqkzGyp UuHI4/k6Ofq5ODvYcPksVoVk3q51ayTARp3OsWPHcn9Iv379kAW8bNkyo9H4/fffOzk5derU6XX2 lJmQyQevbFizBowAbvWhVxPIfAV4ATiQ4dlDoDSFx6fgmgLofPiqE3jbgTAFWLagyYE0GnTTWE40 gWsd6NUSdGJIkEGgA8REArENpFyB1f8CiQHtukJARYZ7+pQgqZg3bx7W/1zVealJNGjQADX4UlNT sUlq2GwsbEZ00ZVaH9SpbBVgK28jAiDdknAG+Bxa/Z8GOoXSJDCgvq9PrkwWm5p24s59vcGABNjT wR69qjp3byVDLHmelIxqEZRbfxfnbg3r+zg70slk1IaowHYD09s7dOlSc9xGy1iaOiMj5fBhu1at PsgaJhKJc+fOffXq1f79+5H98b///S8gIMDLyyt/N4UJnFRY+QcIaOZ1vfduQ7sAmPIDZPjDpaXg 7A6ZR2B7LHAZIFQCzhW8G0G/1jDuD+jgBjY5sO1P8/olgh7u34KOTeDPhbDyONyKBCdXkB6F3xOA SwOxDFRO4O9UQ+dhoUunVqvbtWtX1RmpYXA4nKZNm27dulUgMK96KOEmDJsa/aFYBdjK29hn6X9G 9LSWkw8F6ZaDjQ16ITHWG40P416ej3j8IjUtyN2Vy2Si64pUjYrU7aM7dcsHarErNRqc5QarNNqY lFSdwRDs7hbi6e4m4NvzeO913VxOkPQyXo+e3hs2TPr0adKuXe3u3/+gj6FSqXPmzHlqISIiYv78 +Vu2bMmPIuASDo+zih+uh7GjwBQKBCLM+hdmvfFx81eAey3g28H9jJK7+g0FXEOwY8KUvTDlg/JY fYmJiWnWrFn5HEd8yaBnFl23otMOPt47mLVitVIqBoCjBeleVZmRGg5SYhJA01pBfs7OMamp92Lj cvLS1VotsjUZFCqfzSIS8AI2m/QRS3TKDlLZDJGYgMeL5XJhrsgSNNBEJhLr+HgFurn6OTvRyORP 2U9OsnSBEpA1bDLBW77XqNGAxeFQie3+/v6zZ88eNmyYRqPZs2dPYGDg1KlTzUGoSqkTcdCim/nf t43StczfWxj8Kf80lHAIg4kV5j6smpCRkeHr61vKDpMeHl2HPE9o5VFsu0IClyOgY5uScqHIgpux 0KIxUIvvyHoBj0XQuiEQy1eWdEJhVLJSxeP6+gmKed8TZ969I8pr7N2Ka3FWqsxLuJ10Xw3sYM8W 7m+4pUsR3s4iuNa1LznYH51wBWdTK8CmeFQVk/JhzEWOQwsfmxLO0Yrh6emJeckuQbk12CrAVkol zrIIGGEPUL+K81LzQfWQHZeDXvV8fczjRUbzLKf9V68nZmQazD1XaW52tsgaJhMJWr2BTaPZlG1J 8XsRyWRKjRZVD5ZYNsa0HJFcpaJTqeiL+rds5izgs+kMIh5PpZBJVWEP1d28WXT/Psvf/23qazIY Xu3axfTzK3RsWQgS5a+//lokEo0fP95gMCxdutTPz69z587GAsqRn9fxjy0B5j7XyLhIQmxsSpul f3Y7jJ8O3suh1ajXGw0S+N+3sE0KWcUFWPQC+rSG5PpwYzc4FplO+OIitB4I7fpBs/pA/OBCZdRL jlyeeiDppsZgIBLpjcL3/FI3f3hCL4+acna0GO/vYNuwtoAky4n47eKkx6IkIxAZD3x/7nWsEff1 hLLU+B2TLy+uV2dTMQE2KS/fmLk2+na/1puLCrBBk7nnwneHU4UDmm33tgl9xy3ncDhKpfJDf9Q7 sAqwlVK5U9D/3AxKLoe0Un4KQ8pzGPQpvbqjBFLEg9duShQKrdGo0miQML8Upge6OiORtsiSyfKf xRozmfAEvMEcsA8YVCoSTplKZTQZLSJhqTQs7fD8I/F4ZO/GpQmZNCqJQCQRCRQi0dPB/qvaYQ42 NjQqpToIC5nHc+jQAUtrJZLoRYsUCQm+kyfbNmuGSXLuvXuxq1Yxvb35DRoQ6CVnhCOZHDdu3N27 d//++2+JRLJo0SJkoNjZ2RWGz0PHKLVavdGk0Kiz5UqjJZ4eumIGi5GMLiDagi6LgEFnUCgkAp5h iUiPeffFVo+8qcGFrvkL3z/FlapQUOuktGxnw6SlkKOF4OJ+KM+tghNRYLKFYptVMHwiJOHBpAFc EeNPmQbz1wGNCIb3OLM06pU5Kq0ti1siH8L0u7ezElqE/dHPz3n3+RF3n27ICPvdwfx54mN3Vkj0 eCJJb147a1Sffbo6Qee7YtBZN2P8vFNDfj+/NqDPL1zLyjG99NbPlzej58aIK2aYitPO/Jn4kITT GoxFs2d4HL3venaK2qg3wnvabei6VWxQCqsAW3kTY8H8Z0SLqszIFwCTRhvRwTwdBj3QWp0OaWpU YlKeUqnW6VBFqdXrkYmsN8+zNOmRcOgNGr1ZXmJSUslEIpfFpBJJZsEFsIQFN0c0QNvxlgFmVF24 hoWGerojtcZCDFXVkHNZkEZFCf/9Vy+TMU+fFjRujCMS5fHxkZMnoy2SyMiE7dt9f/ih1BNnzpwZ GRn5+PHjR48eTZs2bd68eahy1Gq1eWq1TKc3kcgUsy9fAoVMxpW2JAwdnC5XGPNkeq0Wr9fzaVQB h02j0bBY65jEFu2URluIRCKm0yiBiXQlXpdPBw+O74MJk8Gu+NToRiNgczD8sLb4wVRYux7irsOP J4FQ5OdT7WDeaojdA/vT3/1l8tz7m2/vCA39tZdXMRd7dnaNJnfa58ZzMOpy6AQiDmdDsnx83KuD R5IyRraYd/L2LlQ96fU50a/iB7XcHsRmAIRODus2JfKsUPkjl2l2jEpkhs3vsPPOy+Wpxb+Uadti evvQ0xcHFt9MCPDpP92+1rzj0/DEcrpKLTdWAa7WmIrzqb42FyDGkrABCATQvefwT0Wh8QFFBuo+ G3CWYA/o1Tos5B2HIaNNo9MJc3JTcnICXV0pZBLVclZNvyCcWrVoLi6qlBSbOnWQ+hpUquiFC1Wp +VVo4rZtjp06MX1KmY3v6+u7fv36Fi1aoAfkwoULqHgMHDQoRSbnCOzd3VxKFd2ioOtGw2ZvWSzs eGF6dGqar4DHZDCQxKJWTVEBxuLCInmm0+kMBjKYzRZz0QNqMgTwDwAGDZoUH/O28QDHaFAai2sF Djx8QRMH7o5ALSJaeBL4esGleDDQ4J3VFVsQ7GZM33y+vaLN4YG+tQpvEpnCcaNwjAbNnmtTjwij erfczUf7DAmb/5vjFTq/g6f/idtmjwR6XdpLPa8TIz8mFU8QaDTdQI3Ugp/C8HMNuvsk08gqlgkS xbaWA/0fjZqEL9YSpTMdvKlSKoluy7D7xDfSKsDVkaIrzLBwYFiXWvlGtj6cl6gisiRQ45RlCQlc 9WDSi9kfWD34GY/SvQP0g2lksreTI3pVdV4qEjKP1+LMGWTvki3Dk6lHjmTfuFG4VysWJ+/bFzB9 +puzsdBzUbdu3aVLl86fP1+pVD5LSHyemRNepzaTWZ5xdFcnR5WGF5+RTszIYhBw2GBw4V4kt0h9 sZDsltgW+Qd8JoVQLgaFGEhvNFlQtePnC9Q3jk96bI7Y+OZPl4uA0wbIxUTOqMu6nHhNbzTPg6Nx 2rdw5A/vuVdzsO6OcxO8+Ycb8/j5x5l0CSln/rgyPYHgN6LVsUG1HE26zM0nv31OcmoFxgtPj0m1 GXcTLzkEOtFwRAIuP6t6tebNX2PQ47y4b0ZJMeDwPAGZX2KrKve5EId+zae+j1YBrl5gli4SXZ1O p9FotFotesc8rRROLal8U/hpwQpgbJ7Ce3qTPgGYkYHpLhb5C+shxGyUz6cG/LJB4kq2RA6WJyS8 WLPGUGS2i8lgSDt+3HXQILq7e4nyj8WT79q1640bNx7FxXft17d2vbqMNwaMyw6NQnFxdsnIzH4Z F0tUK4v2P6OCh3QdWwaK0lhR/IzW85jMr6A3wn7nikBW6vF68wIt0ps/H0kZs4TrPJNOfO/5FTUO 6TvF3a+pSYC7GLH6npJS17evD/P1HC65JGbXjflJrJGzmg8I4pubmEa9Qk0KDbeR5aReO23IlGkS zj090jJoocCULdLIsDpKKHyAtJNEKNF0oNAIb3Qp6zKTddCwlNrCQCUR+czyF5vyYRXgagTm3gzV Jmq1GrXlMU/fWPxntBGpMubtrPIF+GJBt7NddVBfKDL2hgXgZDAYqB6kW0BKjNnEVg3+PNDJ5fdH jlSnlyx4aEv0smU+v/1mwh4By9C3ZZqaCT0j6Ono2q9f3Tx5nTp1Pj4PJCLR1dnRhDM9vX5NK83v AUIFDCkuh8NB34VafoVlD2WmqAbjilNzRohNoNWaJTgyGcLY5hVEOgMy+ZHpCkwOMPQgV4I5irMB dCYgE0GrNk/LSpeAVGmWYYMeTHjzWRoNGMhgUINWX3R5EoHuP6Nn4Qpaw+XIpZsi94UE/TGzeZui IinKi03K81389Xc8o0GuziMRqXSa149dC040RI/YO2t8p01+VGKQA/Pwk8tNHVyMssh5sZc4rGnu DJLBoDXhSEScSaNXG4CgNSq1BiOZgEMWDY6ATHujGviuJNRkU+lNQECZNponT6C/DUaDWqvNkIqD OY6f8oZZBbi6gKkvsndRbZKXlyeRSMRisVQqxTQYmcJYX/QnGQkunIFFt6xHqnoK14egGhBVfGw2 m1sAi8VCWzBDxKrBNQ5sYKXQl5BeqXy1ebMiPr7UgzNPnkzy9jE1aICaokQ8AZ1FxOPpRHP9alCr gEYP96pIl22OdnZZvn7xERE4y9xak9Gk1Rv0ShVBIsWagEiG0TOLZLho2Ss6UQtrGtaQHppcGDsQ HsbCy55g+hO6UmDeYZg6F9J2w9hV8EIMtXvBtePwcBcceQGr58G6CbDnLKSrYIg9nJ4JOzZAJBWW fgMzp8K6w8C9AL4+MPVtDkcJdTwHLXT8Nsi+pDtPPIGKJ0RM+quDCTRkkxbo3df3XehAKrh6Br3B ZA6ijSdSm4ZPuH5+2rgjN+m6aAK1wbfNetOMkp0XZ4Fdj75edr8cnfhcHkvPeJbe4NREf+OGK2sF fjO7Mp7+dH5+oiLx7vmx+l5nfDWXDkXHjv9qijB259q769Sa3A0XZnoN+t2nvFGry4FVgKsLmPoi qxdJb3YBSIORAKtUKswC/iQCrC4IQYg5Skqs5K8rE4UCjIQWyS02CMfn89VqNXZZsBkxVg2uWWC6 iw24YE7txdevp+zZY3qbxwyTiXriOISGQYETY3NkVr1BZ4Sk7Fw7W7uKNTeRfgYFBvl6++AKFnkh 1EpVdnZWslJDzMxEmUcPLOadv9CJh8VriHmoGJurhUosNl+h2pdMNizYDrPRb8CDowcQEoFFBQoe 6vSBA80sB9CATwY7G6BxgESDoTOgu8U3GFUA6LJzWOBgB1QbmPg/GD7VvN3e4x1fxuG4c0rzeGFv 33J+72NaoJDwBGSw6k0kXlFvHiTfmV8tcuYykVK7O3dc0MM9NiuFQGG7CcJcWGwwKQQEhozAJ9F9 JnfZhJ3BoDuZ8FlUE4lBxDP59WZ2+d1ShRJ5HKosk0Yn2lNwOA/3rjNsG1vm1zCcPyLYVzmwCnC1 AKuGkNAi9c3MzBQKhRkZGTk5OehPZP5iw8CF6lvJGpwM+YvhbKvJ9CsoMv8Z1WXI4EByK5PJUN2H am1sXLxwQlZNqOms5IP1+mADLua4qhJJ+vr16DEwV+hvm2+YkgJ370D7DlAgeMjORK/AUl07fTR0 GhVoxWcfcbkOTo7oUUxITs4RZgjIObQiE6Et+TH3TnM4HCzUAdZwrIy8VTRkCAov8mcYrMCmQ7Mg vMh0vwZ9oYElwQgodvY33+UnvP0+JhMkEsuVH/TW3Tiqv2P+XnSl7Xih6FVkL6Nr22X5uRAU9S7u OrbLSizlxX+9yMrGpe0UzEsH3dGTXjVTGq0CXC3AzF9UB+Xm5iIBTk9PRwIsEomQzGDqW+hYoPIp XDtnB1CRPl8+HmwelsoCNkMNqW+J7r7PZU3IFwE23xAJMGpootIuTk1VNGmiDw42yWQmhRIpM49K wckVIJeBTAZyuXl8UaeDC+eheQv4iGlWHw9q5fm4uyuUypTkJFVaEsmYb7Kj0ogMYjabjYooWGZN Y0uVrO1CK6ViFeCqp9D8lUqlSICzsrKQBmdnZ+fl5aGN2NyrT7UOWFdg9eLMC/NBW/nf+AFg4lrY XYmuDFhi41AtFPVeVNU5tVImUJFG97Gw4ydLLJZyuRoaTc/n6/EEz+AQnK2t2YFz4QspcVY25KBX Dri5VXX2gUGn+/j6RWp0aU8iQWd+WFDZo9FoPMtcbmQHMy18qtWDVmoeVgGueswOj7Ta5OTkmzdv RkZGIlMAVUnlC+/80RAAGhXNWlXkIR9kzqIKGjVKUBpVakhcsSYItioa65BHxyDpRXUcsjkYDEbh YVZro0aA3UpkActkMlTssV4fc+E3Gl3r1LN1coISnbcCAXh4lvwUkz7u6pl78RKcJisxMSlPqiJS WC6B4Q0aNmJTjah1RqOSkf1pNKHCjLMsZCOSqRT5i6dJCj1KMDkCW0cHNpNavhJDJBDqhoZczc1J evQQtaNRgaRbTHNUJpVKZdGRIytW3sQqwFUMNgx25MgRpL7169cfN26ch4eHQCAgfpLwONUW8+Qa lQpVx3FxcXfu3Pnrr7+Q0HI4HGRhYFcMHYMOQBW3xALSabSXxWJhK0OsAlxTwFbxYuMv2OR/pFsE nsDX17esQ6cmVeSBIwcePS+6Ler+jYdHLgIIdahxxqDhiXijwWgOhkgik0lkmrOX+OLJRK3ZewOT 7+zpF/LVwCGt6pdzFBkVtqDQ0OTo54rMDKx8Ig3+5CNHVmokX3QtX034+eefs7Kytm7disy4qs5L dQFVatgyXxcXl9atW0+ePHnQoEExMTH29vaYuGIVN9JgbLU0tlgLq/KwgeGq/gVW3k9hMHO9Xq/V atUYWm2gfyCn1Dmyb/kUjVnkaA07jes/vAWPRlJK0+JjU/RgPLFtY0J6mvjNU1S6wkle8ty0qNvo dTZ56eGhLcvZrc234XmGhj04nYIaDXoLWDksd1wmK18IVgGuSpB+rF69OjEx8fjx41bNeAc0Gm3d unU//PBDfHw8j8fD7AysAxOZGti0LGxg2NrjVxPBhArzvUpkssJDg99/zmtMejABlezRJNzLzQlM RpYN1849hEQitOncVafTKtKeLvhlToaCOGvL3x4cQI00nCp+zJAfbcOaTVu8lK/LPrN385Gjl88s +76O/8FgB9r7v/ANCAS8rZNT4WrmT+683UpNxSrAVcnevXvRU3ro0CGr+r4XZAqvX7/+559/jo2N ReYRFhes6BLSQl8lVZ3TT4lRLtcwmLQ3O9xNWoXGRKVSasQCGDOFS+xYPB79g2Y443B0HA60yqfn //rzOWSkaszWJ+D7TlsU5EAjkWlMvoDMoBvyNAo1MFzMhrU+N8USwdG8bI3Od2rfrevNa3eSpcas HCWUS4DBPOWqZEB4K1bei7XerzKQ4btly5aJEydSqW+6ObdSCkiDly9fXji0VtiBWRiyoioiR1UZ BnX25nFBHiH1LsWZ56lpZZlb5oyfsu2BZad6Y09mg84D4rPkVZvJcsBkMj9oCN+gkD7SKMGoi755 5fTha4/u3Yt69Cg68lGmWI0dgCeQiHgCKh0adfGQtuLsZ7eunNy1cd4PP7xMkdIYdFvbqlzaVFMw aJRnT5/KkZlH0E16yd4lcy+8LN1V9HsRv7r26+zZazdvuxrxQqau/KhrJqNara1WVYNVgKsGpBkr VqxYvHgxi8V6/9FWCrCzs+vYsaNGkx/8pFCDC/kSpNeMSX/mr4WzdsWGNuvkaUszyBLnjxk85dfd L+IlFpEhhX7VT3L30IgpO+Q17XoQCET4sDl0RnQ5CDRWq29/nLpg8exV65ds27F275EWgTbYbjyN HUqmmcBkMBXrHclMiNk4d8bWzbvisoEX0HD8wjW17Mtp/uoNhtyc7PKdW+NIv7u1U5fRpx+ZfeTl PrsybeWquYv+VZWrmL28/s+6vf/cuHhsTK82X3Ubcz+5cj3/5CXcGNh/xFOJ/v2HfiqsAlw1JCcn I0uudevWVZ2RGgaZTG7SpImyaJycL8nqLUSjTNm5dqc4aMT2db96cdX7eg9asS+i/y+b9sxrYxlV IjT7fstPw3ve3Tt313VhVWf2wzCY3fp/wK20mMs4Iolat3HrJq2bh9cN9/b2cnDgleh812l16em5 xRSY5+BfPz8avDIz6VWGqNyjFwq1+sX9e+8/7rPgxeVTSIWfJGeipk9CRIRKrtTExyhLWzWp18pf JQkNb7+ZDDt+7bbdNvyx+/jhHXbquz3brsp9+z3Q69QSsViu0qBD9EqJQmXWUdT61qo07yguOSnR 29ZtvBkvNuq1KoX44oXDz1PFOn2VLPIsBasAVw0JCQlhYWGlDf2aQKsCiQTkqtKqISMoZCDNA21p BUirNp8oU4Dx7SdqPqL1p1aARFZKnG25BPLe9JllBFEWyN9w5WHUQ2YW6MsvliEhIdYh87wXF488 V/085VtPG1rSpYPTHj7WClg6k3DP0bOvMmXo/uPJnE692jry87Zsu6yu6tyWFTyBwuEAnaHVf0Ap RVUwwTKTOidLmJGWnJaclBwfl5CYpCvyFFgc+IO++Lp2L2+/KYsP7d63rkkATy/L2rdg0vZ/H+jK VTCTkpOlX4gFbFLcuXIB/XvjQYpJr74TFac2EfJUl7PyzB3IopSnc74NY7K5AWF9rsZlvHq0x9Oj w/dDerkzbMcsPaLQlVRXdNsIRDyNwfGv327lzJF5qYfiJAadMuPPX76hMNhMUtg8VHqRgBu1D49v aR4e7Ovr4RLe9urztD/6OY1Zfw1Vgtkv/uvee3JmnlaRkzi3eysel+vhH77rUjT6cGHs7ZEdPDyC m0ycPvXgo8TTK/t5NugnU2i+beAp6DqzlADCVcGXXpFVFSKRyNXVtZQdkddg4hjo1QuGjoLjd4rt 0ohhyXwY2h96fwOTfoF4UbG9CY9g8jjo3QsGDYe954rt0slg0yoYNsB84vdT4XlWeXIsjIIxQ2HR Jij6FJkMEHUFhvaBlaeKCbNBA2d3QecWsLH4T9Br4OBmaNISksvv5NLBwaGwC/qLJTv2CdjUbhvm AyZd1PU7SpkS8jLP7lo4YUCX9l/PiEzJQ8e412rK4jtoHz+TVv7g2kdiMJp0NLpn/QYte/Zp07Il 7UP7YvCJAAAgAElEQVTC0RDovLquTJ1cvGPmyO/6fD2u7zcTBg2aPOCbp1mFjT8i24FAIhHsbFgF EYsIyHC2jFgYOZ6NJq3ZPnRQF9CoxXFxmnI1DTksFt/NHfcFrN3Xi5/vv0GqWz/4+cW7mQrRk8fR gyaP5sq1uWIlqNNnDf32fFatHbt3BOif3IhOJ+MoAsgWEl0Gj+t/deOvx2JLrgjLeflCnifPSEu6 efbIuvV/qx2cbQiKA7/99P11worft48P0m2YN/yZSJ96ff2QkfPrD5lx8b/NfiQiFS9/ghTWUkYU WS8lZhnTHPp1zH/KwJ2H/27rq1u75yzatXfD3D9TvLccOL5+5WIPDrN21ymbl02nUck/Lt9xcPaQ Txpy4e18/iWmeqJUKm1tbd/cDN/2ArsusHIN/L0Uhs6DzP8gf1jKCH8uh/8thV93QUMitBkAJn/Y OBryO9pUMLA9UFvCkhVw9U8YuwB6d4D8CSUm+PcvmD4TftoKLZjQfwxk2MOxmR9256UvoP9guP4E xhZ3VpD+DCaNg8vx4DTQLMCFI3f3LkK/7yFPBW2lxY6/+yeM/sVs3H/EXGUGg4EJ8BfV51wCaVo6 EGl0ErqL+swctU7vte/GyeaezGcH5nSYdunOw6Q6biEkrmMTCv2c/qJIYbDnVuvp0MkqtVdwCPsD p1/lQ2R3mbqIH3z26q37eXIiDY8jcmkC1zA3G3L+AXham6nLw0dr+fb22KcTuf5LN27QU/mODPNj QOM6dx/1c+Mu31I4AgapPC5c3F1cbHv0vMq3fXHlYjlOr0EI71+No9K2TBr360+7Lt+59UjotOP7 72b9v72zgI/iaOPwnLvl4u4GBE1CcAgetBS3QpEKboWiKRSnxdpCoVBosaIfVpziriGEECdul+Tc 95u7geOSAIU29JIwD/kte3u7e7O7s/Ofd+add7acTcwsaKS9dKqIvW3f2mY+7Pu7dvjZC5gCx/C2 MWtXLvNglmYk3b4Wn9NUdnrsmFkpJtfAoO92/Mguld08eLj1uX0apdyrYfuTJzf5gOKvrsT17Tst 6ejKHYkpvRbsDhZrd6/+kRsyc/6UT8REgiOZbDSoMp6ZIuUC00jOUlO/sSp994640NEtZo6flCOn TlvTCm4zzf+bcSt2yoSJCzd81jaARQ0caEeeOGd5VNeunXyqi8s6FmDb8BrxYIBVu0CDFkDMAWkR YNNhq69IoPVH4OpoEO4DdKWgAaz76V4KHjzwm82gfjvgxAPGdMC4Xe7ARu3AqQegaQjQlYFGHCB9 vUFEyMGihaBRf9CpIbCeBYzlDMYvAV0PgGflm0z4TmDm96De7IpNygH1wbY1oPcYUMHB268dWLcM zJgLyP9cD3CUK2CqVRkBl0ymmSalpxDwhqTS7D3cXLmsiBAALukIk/FHqEoz9Vo6LUrIrr7qq9Hp 4vMKPL29X1q9BKHV6TQqlRr+qVUa00JZVlpWViIpKykpLSmRSiQNmzbt2LOX5SR0gXurfqPg32t+ hMTgiV2snR3JNM/gMFBuA9PJ81UtUm8Nm8WKbtPaoFTkJ8T/m/NUawjluQOnafyeLVtHifmLB3Ue 0HLoVx72QY0baZLiknUORrY938VJQACdkTANVIBHGBl0Jp1KGA1Ggy41UypuFTFhwTItwWDx7MPr ON8/S7YPq+/HJtIePRTYC4Qko6pEIiuVHFv6be/uHY49PNTYna0oLbhzT83o68mlU4ylZTISILGc WrUCj9Sm85NQbxRJD4qLTu7aG9D/i30TRrgyDXIdMWberw3anT+yc+3CkSM9r5zrXtcZFVIaTXXp AAZYgKsZFBDdyfR//DGw9GfQcTh4qV8kENrE9L+iGHwfC+4DMLWFVQcCGXTsafr/ySkw61vQqC2w duf0DgHeAKilYP0icKEQLOkMXlsg0wAXWuH9wJo1YFDMy810PujbFfxwABjKW65cJ9CxHVgfBzzL t+jYu4Fu5rm4g93LbXcOAi2yTMmuNk4QNRSBlwsoeJhSUNbcR1SngQebTf1p/gx5x8A/flxvFxAU EmC67aqykgytmkR3oFZX/TUajSn5BVCDJRLTJCTmv8KS4iIjYWQwWUwWi2GaZQOuMDk8nruXd1Dd ehwul8vjcarl2AE6jQZrBhfz82ydkPeFUV12KaOM3PETNxefmBD+jTRpg8YtuUxmnTbha+IekDoH Kx6nnTl/r1OANDnjviQuvWNbUBp3d9cfB/iKx1fv6mO/CRC6OPbo42t1SqJZRI+tS8Y8vHBkeeyy Xn0GrFi7zNPema5q9OmokeTCezNmbnDqOKRFW4+jZ3/df1JEvRJbwGPa8blCB23ajX2nTxmfnLwO gDug8l18yCCy89KhnSUPDi79eUfr2B8St2xr3L1LzyHj794cnFBY2h04o598nFrUJ7i6xBzEAlzN IFRgx0Lw+fcmc3bNWFDB2NPngJFdwIF4sOUqGFiv/IE6cGA5GLMUOAaAQzMqHmjIB6O7gD1xYPEe 8EVExW8tkBhgwipA54CRfcHDvWBpTLlvc7IBtz6gVDjYaMpFgT4V3QkKMkzLykOcSwqB3hvY/cPx HhiEV0SPEMWPG/fdGtbUr/HQibGXto/7feOlgxStVjf7tx2t6jjC53Lr8In8tAK3byIrOgTbDoIg iouLnzx5kpCQEB8f/+hR/KPHj8kUiqunh5unl5unZ2iDBi5ubhw+n1yedxyYZDNcHR39wyNzbt+w 3lhr+kqMOmWBTtkhKoxOEXzUr92Kq4c6tm9KIwGvoKYJG2+WrBw/pufGiYPb0SkklZJLenB8xv1o ZfatmeM+AQS379TVfevZVzghlUPSF0gBXdCsy+CdjRpNDYzcfV+xftX8xAa9e0fvIAMjm/fR4eVt mwyNuDF40MjeXUk6VVCrGAad1XnUgi87LfjoxDaDTmPX5lM9xW3Bjg39h41tEbWBMGijPp4SU4d3 6uSKtZvWUoCRX7fnj3XdzBdgqvc7uQgrX5qtwAJczVg9G6w4AmZtBRP7Ak75gjP7DghpBRrFgEv7 QVP/igf+sRJM+AWMXw+mDga88o+1MBG07ATsGoDTv4OWIYBcvix7vAf0XQigleToC9ZsAS5SkC0H YnfgX/FtAQQdMB0qHm6QAyi1tErefOZWUOD5yrzuBTg44/0rWM4tBg8N/2bVwLlBtClDe32xLa3T tDt5UsLJu46/G6zdG5Mvb16wcZ3eu+HG0S3/M/3V6/UyM1KpFC3LyspKS0tLSkrQEn6k0WgeZtq3 b9+yYycpAcRica3pVoAX4ujslG0e6I9CxNSmMXJUntdPmw+xXEwmbJ0BK1Kiv7F3MnXFhkUPP3Ww qxuHPf2Hg0Nm5RpoHFcxMz1PxdPece8w4tC2ZXYcBpfLo1YqJNpM2hWlobBM/e4ktnOdn6RlRkCB e13RSvPzJASN5eRkZz7IYfX+i98q5TdWR357M8qOTRW0m12aN7pYYeBxidxchQOXQYsaceHBxwXF JQyO0E7Ih7/1273izOwcjZHp4e7GY5scAhguTe/euGcfYPcf37c3gMvBaoUC7DsOxq8Cs3qYGnut 3ZqgoXn6D6BuD7b/DNz5wADKNyOrwOafwadLwLz+5iEX1gcS4OYpkB8ETmwxySFRqaTz6QQONgY0 CqAyADUTjBwHHuSDrbtAx8YV94Q7vMJ3ig5eac2iXl5VpfEkZKopcdj7/t9BobNGz1iV/rTfhsVz o9u2b+Mv8KvX1O/l97qTy8c+0YWv3bo90vEdPIrfCSi3mZmZz549Q8uMjAyJRMLn84VmRCIRWnF2 dubxeHwzcIXBYKAwojqd7n9Xr9kzWTXFun1L2CwWhcFA0dlQdOtaI8CARHX3edGATGY5vIhbwuSL GzcQm9YoTHef5/NFBvjwCxJhuULncvhCPv0VZzNNn8xilSs9KOTnv8Nydncr98sUKpfHKssEpgLH 9JnEs3fimW0Esfj5Pgw2z4P9sm+CzhL4+Zef0oPM8A0Jeqcrft9gAa5mGPLAtjlg/sem9ZA+4OoO kHkbJBpBzwhgVALwFPQMB/EZJlmd/TuY0w88PAZKPEEbf2AoAH98C77/xKTcvh3ArWNAnwmO3gV9 ugOjGhApoG8UeJBmOnD0OrD6M2DptGUJQeALO1VFATHjwK99gKC81aTMMzlnLdkLPG8Afx8wpB44 /icIbA8cSsCKheCGFmTOBnU2gabu4OQZEBENNElgQazpwGmfgnVrQR0BOHwBdOgM8i6CT+eD4sfg k9Fg6XfAqzr25NUQSI51W2y6nrlWpmXxKteAGF8ckI80Mlj0f/6CW2ZHQCtarTY1NfXp06dJSUmJ iYlwJSsry9/fPyQkJDg4uH79+gMGDPDy8nrbOQTN55drNExWbYv+SJBIVC7fEpz8w4tPbgWZJqcz q87dg+bgpnb0alKbms9q0aXUBhjg0ykgmwbcHUyNuknQfNSDB7fAlhQQEwma9AQTaMAtANixgU4O 6M7Q0AHb1wN+F9A8BIz4GiQD4O4EGFSQpgEkI0h5BLavAy06gpDWYFwBEPmAL9nAoARyD0AqZyO/ hOUERvV7VcJIgOcEJk0yrboKTL9+4Sgoqwu6c4GDF5g0HgAOELBNDmLwFx3CgCsBnOuDSfUBwx5w mECeBTbuBmFNAZkO2nY0/Tl4ABbOe/8eyqvU1wSJynn7bnZon8nl8uLi4qKiIriUmHyiii0TTKEl 1GAHBwdozkZGRvbq1QuuODo6/puIKKbYGa+IGFPjgTUWlaSYZydCM4VYQpTbOl02wMEv+tjulgzm q83fd4fccn5aM+O/GEFR/cCFYLWCCkbPq7gtZjBoDUyDgsLag5XtK377zTagYQI6DQydXfGrBm3A 1vrAhQUoEWBRxL9KF9sJzLJKGGEAMxYDjj3g0sDU8tvXbwdCR8DwBosbvtxuFIPta4CDA6A6g+/b /KuUYP41UAxKSkrSrMjMzDR1Xr4ACm1gYKBAIOCYYbPZaFmFAchQBO93CjlZU4BVGY1CbhQKPswg qdaQyGQmq2pnmiFTalfvFRbgag9XCLiv/xYapq9rx6WygPv7cTYmUYCTyztsJ9OAi9N7SQmmElDY dGYs9mtluaVSqQEBAVBlg4KC2rVr5+fnJxTawDW0VvX9mpEqlalxD4HZGwth6xRhqjVYgDGYGgyU 2EIzBS8oKyurYHJB4xUatf7+/s2aNYMGrr29PbRoq4M2sKhUmNTqkJIqAV5Lempq9uN4DpNBsYJM Jteaa8RULViAMZgag8FgQD5QycnJyBMqLy/Pw8PD29vbx0xUVJSzszODwaDRaHQ6HS3f3jHqPybU zeVhTr4dv5b44mXk5j26ekWnVlM4bCqVCm8+XCIBtnXSMNUULMAYTLUA2k8ajUZhhVwuLyoqgkat xcAtKSmBcguFFipuREQEXHF1da2J5TtqnhVyOMBgchKuiZdQGbVKXZiRzmKxoOhSX4AurXZbwITR oNEZGAy65SK1ahVBZdDJRF52JsESu9jzrK/faFSnJDwpU+kpTL6frzef/SovLaM2OyVJznAN9BSR zL+hkJaWypRMrkgk4FgFIyDkJXlJmcqQun5McyYyGnSSwgK52iCwdxRyme/pvlfVA8UCjMHYACi3 ZWVl0H7NNQNX8vPz9Xo9MluR5Qqxs7Pz9PRs0KCBvb29WCwWiUS1Q6uAaQwoGV6qmMUoVSoF3De4 OdQY7IR8Bp9P0uth6VwxkletpjQjfv2W6+NnjxQyTYJCGHXH9qyRBfXuG8JaOnnAI61Pq259hvbq 5OP4XIY1JU8m9BqQRpFJdfYtB49dM3OUc0UNJjKvn57w+aSi1kvPrO3DAODhxb0rf9iTWSDhOwSM mDi1V4tgtJ9eLdu2ctriHcbzT3YFmvy9FP/bvHLL/r+KZDrXOq1nzZ7SxEcM3j//WI+xAGMw7x0o t9CWTXjB48ePk5OTob4GBAQEBQUFBgY2bNjQ399fIBBYeg1rfd+hSYDpdE+RXebTZCqFwmHV+Oik Ag6HxeVpS0ssAmzxw6rFzxGSn3x7277LQ78aLjQLilGnvXZ4F9GvWW9fYcqjG+cSb/x14uDKab5L Dh4dF+1r3kFGdam/bdP3TqrHY0cN39yi3ZyOwdYnNGhU29Z/c/hhsnu4Et24u4d/LKDWW7sxdt/q 2IGx20pPL0HxZdJubJmyfLdW340wj7VO3TNr4NfHpy1eM6qN3fRh/becad5kdNf3dNUVnOz+2SPG AoypSgiDQQ9ItFo2VuDvQCEYLfEXESVmUAhG+BGKjYeHBzRnu3TpMnbsWDc3Nx6PV7vL5TcDaxjQ 0GexmP4C7v30dLGTs52p/lGDcw4By1M6XWu15UNQX2CqXxoJFrCayBHWP2gGAOgMe2f37scP/RKi uLp0+fLJnQNz1h+cMzIG3ikyk84VCLx8m0Y2i7j3IAtYCzChubB60pp4Ymxfv2OK59uGLT87BJAN GkXrllHb41J05umApekXJ3ec2759qyuXn991p+aDjx/5vGVUCA2o6oY4St6z84N1UwcW4A+dsuzk x0peVIB5wI+h5NLFuPrNWvAZ716iGdX3L19MLdM4uXiFhAbZsd8+lqHh7p7NSxPsdyzsU1Vj76sh Op0u0wyKvwiXUGWhmlriL8IltGWdnZ0t8RchzMrzUnzAoJKLSoWCRWexWA4kIvnJY1rdMGENd8iq 9a3Nr0ULDJVGO8MnzGCSjEbCu3HP1ZujWkfGfr44Niq8QSQ5SSVksGm6B5cPnzjyeNhWL+ujnl3e MXbe75+u3t0sa8WxVMupDFc3r1++72hCYnLrz5dxTEHos2fPmHO74aD/TW/Z59Y+tBvHPbKdO9BL szbP+XTzNcXisX7gvYGaqVB/v7Wr3TspMRbg2oJOOn/+tDW/sDN1O92pIPvU4lajr504vq9TmPO7 nkldnLVo/uQjN57RSHqVuvGu2zs/qu9BJb9FriIMSfH3j5931dRkAa4cgjE5ORmFYITLxMTE3Nxc 1HQcGhrauHHjIUOGQNO22noaV1uQBqPebgadTlapGdV23sS3gyAIg+71k23XXowE2fBUpnsxKTi8 DRoFp4GTK/qICg4mz3HglDX3T3snJGY18i45u39r8P9+p1Jp7YePHxblYzmVIu/xqBkr8pjDhvVu fCtWa9CWlSpVDiwWCZCY7i5urLgz+aVqWRFh1P+1ee2evZfmnf+Foz6lN5jmsfR248MsVPD01sf9 htxJyZu88c/+Ue8l8rPF8IXSyzAD8zBcB+/e2oEFuJaglpZI0p8AkHj/2WZ3X+qVHYdAtjEztwS8 QoAJeYnEwBULaK84D4TGYjP5/Am7bgx1Stu9ddOQqNB1u2+O6hVauXRUyUqMVDaH9dJEppMBiV5j plqAJaZMJiu2QiKRKJVK60AWUIMdHR2hOdusWbM+ffq4uLjY29t/uIZO1QGLKmQ3IAOCQiaVymQs dg0ODV1QArVBZutU2AA7V2e3xlrVi8CiOlnyvaeKDiK2waBWyKRWO5LtHLylmjK4FtoseuJnn4eG hDSoF8S2arxOTXxEJYvqhNwZ1i1Gkpicr57y+SzplqUzBCx6ky794V/P7QuHffG/pJnDHyTf8Gva dNv0QRulEok8vf9HPZas/XVQkGz4sGEkrx5nD85s+t7cr1DWRY03bDNo4N8/aIXGAlxLUMoL87PS 4crDJ4XdnHWbDiUDwEgrygUgBG6UZd5e8e30S4ni5j36T/+i4/dLvz5xLbBv89RzadRFq1c0dC5v r5omBwMe3m5h9UODQpqINF1OnTgzqFsIVZ61ZvGik7eeOnvGxC4ZG+jKO7xuUhy9jl3R4+sF9guW zgt1YML6f0i9wMLbpzZcKJg6dYjpbPr8ld1Ghn23vWPof+GO+AbQZLTp6ekoIBRcefbsGXyRLPEX 4RLatXw+n2MFfLtqfR+eDUGdZyZTmDDm5GS7ONXgiGkKpUJZVsqq+d5k7wpP5C42pq3b+2Dj2Kbw 451dq/Jc/P1dhDptenFhrqVbX5v914/HS2b1gpZxvNjLv3PP7u7cigIUFNHl552RegLWe3Xnlgyd n9F58bRPubTitUPmNZm/tFmAyN/Px4l9Sk1mfzJ3x0cqU6jt4rgT3Ufs/mnrpta+7umHp6QQrrt+ mNfAhf3+hrehlhv4oLlcLo/HQ6UE3PIPToUFuJZQmp3w7BlVyNaeuHp/uKjwjIJdp7HHs8xi+FXh 47Mtuw418p2aORq/nzYsLPpxVnLijUs7MtPFZK2iVXDRo9zfvVgvNUavVWuVCoOOUKsUcllB9uP7 mkY5Br1my9SeS68LJw/vcO6r6d8G8rbNHpufkbbst4PODmKDqjQsj192dCasAzuLeDp58eY5Xzt1 7TE4hPv4jx/mXLrzm/q93wH4vmk0GrlcDi1XqLV6vd5ablEIRlhpDTQDhTY6OjogIADK7XtPGeaN WGI2FjzLVIaEsmtmZznM+QW5udVq4iOY2xUKxd/v96/hOvt0iWg8d3JzRfKqaJecUdNPjpvzm7cD W1MIn2rpwT9POahDCxOvzBwx3aldnw5tg8CTU/B5v7JaS2fx3J9PkqZ/5MikyQK8PJwoID/h1B8/ p6eP6tfp2PZZtG7L6rPJgO2G5vXlSMQUMj/IP0jIBtk6RXHygzFNgp/IyggDe8TybT9M6FLl1wtv LFRcgUAgMgNX4EedTvdKI/jN1XcswLWEp7dOOX48cq7o7Mpzf/2pygBBX84byv72r6dao+7I7h0s v9579n4nfLLrTA9OXS/7XDY/KGbl+d0j6CmH3FuMTciWFN7bc+xxoflMdUePDNZIZVsXTHggVN0/ 8xc5rP+sTz5nFJxbeUzyZex4auYdlcipQYjJa5EpErQeOXvfdzOKr/zSof/hNJXpeCUA3k3ge+Y1 dOio8CPLf9p8LKDDnI71q9j8RRGP1Wq1SqWSSqUZGRnXr18XCoWwNgpfA2jXwnwP3wpo1EK5bdGi hSUEY9UmA/MvsR7LYSgufHD/fuPGjen/yJiwLWVyeYY5CnT1gclkwvpo5e1UKhUamFX5S1Te2BVr QqJCj91Of5AO5i38bcLUTnQosTznQZ+N3n/694kHFAyOqNlnkz75YoafiCF1Dx/RK1jEeLP6kEOb D/kyINScFZzmnT30+44jSYkpkX1WDh4xzHo/gVeDcZOKROb9PFqPmjAh2NHRVSTiGhSF/AD3qrxM cyg6WLZAwxcWNQ5mYKmCBBjWdZCj5TvFAMcCXDuQnNh6vF7/9e3C7T7ZsGLafWLAD7fD3C6plv4v WWEs0kjbjxoZaMfI0RsIgkanmiqfbh2iXLgMtYCjNxjTM0vZcrXKYGRRmFxHDt3UKkiOK74ZdywR nnr97IV9Ir1S9/2YU5T9w8yJTft8ufri1YaBJsdFvourN+EupJMIR3cmk2LJdDSu42dThn3bdszU ieSEh5q1d8YIqtq95vbt27Aeit4EuPT19a1Xr56fn5+LiwvcgnplsGNUjSPjwT2+UBAaFFyzmv2h +Zubly/JfFatkg2NM1gxjYyMrLCdz+fn5eVV7W+RmXZtBs1q2U9PEIBCo6K7QGOJBoyb32OEUqs3 kClUNptDo5rahPkerYa6v9oCtj5lQNfR01/s5VKv9dTFLQwGI5lMpVDKHcl0CPrq60DU2Mz3bjF/ fouqvTRrioqK4N2zN+Pq6oo8QuAWFouVmJgICyLLeKS3lGEswLUBoyzjQjKrn3+IU3hQGD32jrHO xN6hLkXFIsH8A7fzuWR6wq3EopgGCoOeICWlFqphXpUkPU1J5SZfvEOj2Af5OrdqO6XVi7MpcuIB 8Dl/9IR3+qn5C5d93TEse+3B8Y3rMJj2/ef98u0nUfK8lJ9Wnhjw1ReABAqy81Mz0u+dOVpk9sB6 Acm9Tf/1DZeO27u/yagVMV5V7xMdHh4O8zfUYFj9hG+Ct7e3k5MTrJDa2dnB1+CfOURgbI6qtPTO +fM0Gt3Hy4tGrTGlk1ypTHt4v1pNLAFTAt+IuLi4yl95enpeu3YtJiamyn+UUumRkchUDo9fqd3p 7e5T+b3IZAr5NXMBk99mjEZVEB8f7+bm5uHhAXXX2QwqcGBBlJCQAGXYMjbpLUOQ1pgsjnkD2sKk J3y2u5cjSSDq3dlHrotpKARUirubULzr12ubP2q74pMVI3PPyRPjikuebl97LQqA+z980e+GR3qy fMDk5U3cyr0g0PwlUdKSctRtGnfduKVui5WL1274YcC+VV/1Dj+wbt7oK14FqelU+2aDp5t2PrJx ee6VfblFZT2+XuvLBJeMRiob6TB/8KbJ4zquGfZx9Pu45OpT0mGqFmluzuWjR0qaNQ8KCRVy/6bL QKPV0qtBZSs7K/tZ4hPbpqEyUGh/+eWXyttDQ0NXrVqlVqvx2PR3wmg0Xr16tWnTpl5eXmKxGGqw SCRCQ/ypVOqVK1fgR+spsN7GBQwLcG2A4RF9fJtzgzAXKEzjfzw/wsgzDQzieX678JvrICyync/d u1GPkyUufr4iTXaqUnhzDWgxf+uvQ4NIDKG7iz29fLWS5ez/w54L9i6m8LxMO89Ri9b1n6Vic3ih v+z+9NmzrEK5wN7J08OZY+506T/+q6WjupNoXBdnJwoJdP9iVjsmcmTVnf/1q7phbbpEBldMLgZj BfKCRgENUBxslaT49rEjmSnJweGRHs5Ogtf33MuUKq1B5iq2pYN9nqQkKe6BUir9+13/Q+Bd9fHx SU9Pl0gk0Eqz/srR0bFJkyabNm0aP368rZJXEykoKEhJSendu7eDg4NAIEDDJaD6whwLazPQAg4M DLTMQobcULAF/EFAoonbdnjehMx38Hrh10sJ6dAnxLzm5FPX6flgd3cno/ymKXC8u59fwKvPRqK5 ur10XiCRaXyeWWzpbHf/YHf/cjtzxM7e3i83Obh5O5hXdEXxS9crw5dO8xLWPIcazH8DKqFgUY8a LnQAABooSURBVMVgMNhsNpfL1Wq1UIb1etMUScqszHvZWWme3mJXV75IBG0OJoNBvJg2Kjcn1xTk My/Xwc3VsUUrqi2CeMCUlMpkD65fT7lzGxCVAkHZFHhj4Z3s1q3b/v37R48eXeHbSZMmDRgwoF27 dnXq1LFJ8moc8Fnv27cP1mn8/PzQuCMovSj+BszA9+/fRyODEZaZKP9Wg7EAf4hoAcivkog9rx90 Ufz0CpT55QOjsPxiXocloAEs0UQiETQjkDEBBZh4oWdGjao0KbGUQk0lkUyByXQ6vV6n02i1CoVG pYQ6LSsu9PDx9fXyevNvvQ9KpNJr5889vXGdqGbqC17c2759+y5atGjo0KEVWpuhARcbG/vVV19t 2bIFGsS2SmQNAt6upKSkefPmwYog0l0EvM8wE966dQveYViPZJlBcTneJkA0FuAPDzJ3wrrto5lV MCCn9+eru4FXK6xz0xF5eZ84OeFOJsxrQQENoDEhFAqh7QsFA61YD5KBYgy3KJVKuVwuk6m1UHS1 WmAw0ChkqrlpmlAqb1+6yOF0dRTbVXlnsJEgyK86p8FoTM7KenTtWsa9O1X7i1UFCjHm4eHh4uJy +/btFi0q+gZHRER07dp1/PjxUINxtJk3AHPjzp079+/ff+HCBaiylpnKLG5WEonk5MmTsAaJAmNZ 2qWxAGNeDUMgePsJFt50Hgbntechs2tyUCPMfwQUCVhaQYMMrsPCC5m/0KSw2JTwI4qvIpVKS0tL FQqFxUS2spLV969dCW7Q0MPNrQqDH8mUysycXDsBHxarVHNzIkwX/KeQy58+fpzxKE6Sk13h56zn xrFQVel5V1D9pnXr1lA5KgswZOzYsVBLoB3cq1evVq1aQcPuv09kdQbmw5SUlOPHj6empsIln8+3 fqaWJwvVNycnp2HDhlB6uVwuap22dAO/+SewAGMwGNuAjAloN6ARZbCAQ+prHU/qlQKMpspAO6Co Zyq1Ov3B/TKp1Mvb+w1OW28JPHl2UXHyo7jkuyYDlwkLVqGQK7IzqFWS/HyNSqWRSQmjEaXcupCF VwRLYbj97W2g9weacRkKw5EjR54+fRoYGFhhB3jzx4wZ8+jRowMHDqxcuRLKMNRpPz+/DzCapjUw dxUWFsbHxx8+fBhmud69ew8ZMsTO7tXtK5mZmQsXLoT3Fkovmv0MrsAbCGuW2Asag8FUX1A/JXgh FRZZtRZguI6aoKGVDAtBuILaqC0WMFzCLTKZTCKRFMTH5aenO/v5+3t7mRxh3jESC7S7YQqKS0ph qfrowrnS/Hy0XV5cVPQsw5JgeGY0Bw6SWOt4L/AjLHxhOnk8HrSE4EW9jRn0nkCt0DAxPXr0GDBg wPnz51FLgzUwbfXMlJSU/P7773PmzIE23yvjZ304wMfq6OgYFhbWv3//5s2bU18/Hl2lUs2YMUMo FMKbDO+t0AwUYJg3UPcwtoAxGEz1xTInEpKxCt5M8CMUYGjgQoMSWpbQ9oVaW7H92WiE26GlAstN +FVOTk7Cs/RUsb3I3sHd148vFEJrlM2gv6Eo1EEDWqNVazWSgoJnycnSIii36cjArbAnchlDibF0 9Vk7u8Il3AjNIAcHBxQg6S0tofeBxcM8MjKyZ8+e8+fP/+abb14X/FwkEo038x8nskYDqyywvuLr 64viQiMZtoThw5GwMBhMtcYiXa9TKaivz+cMZjCg5iEr2VqA4Qo0i+G38CuFGSjS0qzMkoz09Af3 yBQq39nZ0cdPKBaz2CxTKCUyiTASUPSNBoNOb9CrVYW5+VmP42QlJcBogBthdYBtFk7rWdYRyPaF yYAyBotauGKxdSyXg9zKkL2OIpPbsCHa4mTer1+/TZs2zZ07d82aNTZJSe3j1KlT33//fUBAAHrW sMolFothxkAzI2EB/rDQykpu3U1u0rwxg/q8yHj68GIpN6CJh2Dj4qkZ7IgBH7X3d3PmMF/MvWnM Gdulz+WsEiAMnvz1zIEdwzm0iu11ipyE1bOmXXMefXBZLxoAssKMc3+evBGfYu/bpEf3Dv6uQrQb QRiuHFo39buEHac3+pu8ng2ZT+4dOnAo/pmsXquYPt1bOfPeiy809tusTbzuacKCDIV4hDJGvMB6 B6jHUALhEkovLAehNQx3gLqI5nKGOxBlpfn37+SZjWnUdg3VXgN3Ky/kdDKZSmciibUe4mmdMOQy xuVykcVjLcCW3ZDmoWlioQVs26ioyAhGbm4DBgyIjY3dsGHD8OHDP/Be3n8JzFrbtm2bMmVK8+bN 7cygWRlglkDtz2/f74AFuJZQlHJt4mdbD9z63ZP73DH50E9z0xtPrz8w7Ny+DfsebVi/rk6n1p3G TJvSqb6b6Wt1QVKi7uMvx3BV+etjPzPw94xtGVThnPtWL1y5/TjR5yNYjEEBvvjrjBk7M/v2bH91 35rfLiff+m0Wyj3S9AsTpy+6m9JIbe65K773R9/h87jB7aPrCn5b9Hmm9qeln3T8724EptZhaaZ+ 5XBbZBBDLYQaA9UXboHqAsUY+XNZdkOms840jFiPtBl9azkn8hlG2okcqSrYMdYxQ3g8HrJ1KpS2 ltAitBegJmgbarClQuDo6Ag1AypHVlYWXKkQHgvzlsBss27dun379rVp0wZJLwoKDVcqzMb2NmfD AlxL0GllcgqwniZEp9CSTa8fz9G107bVK0KUZ8ZOmNbr4KY1R+LGtPUCZMB0cun40chm3kyyJnvv sYcVBFiR8Ntn++5GtfG8qwXorO0/++n6WKaAy3x2J6rvF7/LATCZwIaCJfV7SnhcPkeHTG8KgzVg /OrhQzsJ6SQn3ZMrJYXv76pJ5Xl/P4SxOa97xKjVFxl5UE2h2MByUKPRVO4qNsXxMHchIxmuMCUf EmCkrwgknxWcnFFjOLJukflbOeovUlxUCttWfcGLkFgwtfB6vby8Ro8efejQoW7dum3evDk0NNSG CauJZGdnDxkypLi42NfXF9q70Op1MePk5IRmZajQJfG3YAGuRRhB5cBUJBKdx2dQWdzw6MnnG3Uc P+7z2M/7BB852UwgodixxXyqJC/lyaNnjfu7WB8lz749MHRY78kL+olvfnL9+UYGT1jy+P6uq9eO HPxdFtqVB60HnXL/qtlruAG/rp++YNJetJswtNekUGDUyh+d273r8F/NZo57rxeNyjjr8Zfv9ecw 1RD43GHBB4s/qHlQGpH6Wusr8aL92aK+Fnm2toBh0Qn1FQ0igieE6xVylHXMauTh/Mpwg9bjRKtD hkSXBq8LDfFC0Yy/+OILaMPFxMSEhYXBi7V1Gqs1MLckJSWdO3du27Zt8InXqVOHx+OJxWJo+KJJ CVF0aFRpe6dSCAtwLYEwAMMzlU7/so1Or6W7858HqUe9uwK3Opu3bhvWJerSlceNmjy5fO/yuGH9 dJIMGcV7S4uXIWH1isIVi745CjrcnDSu8JdhcMPzkozQpz64+duP00/e042IHQbPmXTh0IJVe0ct OdHCM9uol2m0RmCeCkldmr/y29lbf/4lYMTqT7o0ex/Xi0o96wLRYotga/iDAmUDmAGA2UkKmXoV HLWAlUO1wYxltLG1ACNBRbF8LeZvhexkqfBZDFxQPVT2zSDbHa3D1LZu3drPz+/WrVuLFy+GtY2O HTv26tULmnS2TWQ1RCaTnTlz5ujRo8nJyVqtFsotvEt8Ph/au46OjlCAoe0L7WDkkfcPHO6wANcS uA4uHi1ZDKrl2ZekPMhqNVwITO3HL6u3dKFPTMt6lwpNU6cx6UwP94AmA78c8HEXMftlG9qjK//7 ecMRuBLhZW/ecLx1jxuHf9vgIqA3G/jZiYGf7Vo9btDko9/O+3zL8sHxRSB+dNR6836NPJ2+3nF2 UfegHyZ1nrtNvflyyqfNfd/fJZNeRBJGgzKR1ww2gj9AkBAikxQujZVClCOVRaIL1587Z5VXaOum FItpW9k322LX1qx6nuVlQR+RTczlcuvWrZuWlrZ9+/bx48cHBgb27NkzIiIiNDRUKBRWHjT8IaBQ KEpKStLT02/fvv3nn39ev34dSqynpyc0c2HdDjnAQ/WF5i8UYCi9cAXZvij7veuQMyzAtQQGWyQs fHLgZvb4tibNy7uy4wbwGu3vYNCXZCTfafQiVxhkaYfO5zUaGwxAnFejqLmrVvnyK+YB//BO24/8 T2EKQKS6t3X1mkTel6OH8Ziam38cc2jbyceB3apdTFO3eTlKMHTh6cgv5DqdriT1buzyvf1jZ/QL dS24sG7hGfVvF48Obubz/qYotxQoaFDmO4V/w9QykBa+ObNZonaAStJb+VR/a9fWxDxmrcHWHd5Q ht3d3WNiYjIyMh4+fHjx4kVo9qnVavj+v+FG1VZQNwTTDCxYunfvjlzikfc7VF9YNUFDftGoXxR7 8h+XPFiAawkcsUdEPa+FI3sr5y1r4yn9bNRcr/AFdTztCH2uXq94lJLaMdSu9NmD76d9dbWUMa5Z CDDGEYTxlW8XV+TRoZuHeVUvSNm7gdZrQPc2TCJ307DBmf3HTBzS+a+dMwr8WgQxATeyPfLiKHrI +m59wqiRY0LZ4PGVRAYhO71y+ua5EpiurmO+mjGoVZVfL7J4YNbnvwC5pGILuAZj1Cm0OjqVQas0 t6DBoMgsyne092K/CDtFGDSFpblyvV7E9xCxTG08FU1Soya3uIAv9uC8wiYxFkmypDo9n+dkz351 3EqDuiizrJREE3jaOVT+VlZ4ecm10190jnU3m5RSaY6eZmfHKjfcrrQo1cj3tqPbJgrHK7FosKXD GwkwFBVk0kHpVSqVSH1Rc711XO4PB+vuLTQsDZq/SIAFZuAKj8eznvjon4VbwQJsG6pcJMgM4bR1 PzEndPlu3uj1BCBTPzu4ebwdg6wnWD7B7hsm9Vv7pQG+dCwO+5tfzrcNtVc+Zfq6OvMYf5MBuHQH DxrDbA64zDy+btSI2NFn93JdA5dv+Iprld8YPJGbJ0DXJA6JYtOvZiuYAQENjNL0wqysqr1SVByg eAhoCDyqisKPto38h/nHGI2qhKR9Sy7Mz9UpADV4WMvl/YMimC98+o166R+HO23OVczuf7qdvWmK D51GsvX08D0ZtykkI40RNr7jhk4eftZPXa+Vnrobu/7Ozp4xiWO9y8V+MugkBy5M2pR40kiiEoTD 4OgdgwNDGeSXRxOEPilpx+RzszWmlmqjvePs73qMdbVyUyKMyj/jt93KSijQznMha7Myd048Prtx 09/nNm7/8gyJv07+a36wz+ZlnbpUq0IWOUUjwbA4nUE5kcvlKIyJyoy1AFdu0q/doAIEdUNYBBg5 xqPpFlAQNEuT27+p9JM+wNpNdWDv3r3wufbo0aPKz6woK9UaAEcotNS8dSpZ0pOEnGIpgy0MCAl1 FrHNm406nZFG+7vCwaDXGqCtic5FaDWKMqmSyRbyOBUmTiHgC0tj0P6D2j4sKcLDw+vXry8SiVxc XDw8PDw9PV1dXWEVHtZJkQa//1RgqpL4ezNjr2/l2fcMd3FOzTp7rzh5WMe7QwPMA9YNslM35i27 txMAz3n9j7W2dzRqc37889OjBXkt/AeG8slXkw/ek4uX9dnTRPg8uAShL95yatzOtHMA+C4ZfiXC uqoIDBeujl5172qDwP7BIqfE9J2X85NGRf/VPzjEslNu7p9zT0wpYTTv7t9QL3+4K+FQg+DYea1G C15EqlHIEpce+Thb9O2GTh0u3f1u8Y21ANiN7rR7gH99tENS4uYlV5cX0VpNi17aysX+P7mF7wxS ViixOp1Oq9VCxUWGL4r3icZrWXrNPyiZsHRDWOooyNEE+cYj0GTA/97ls1pVzj4goHgkJSW9jzNz BMIKbWo0Fi+0YUSlEX9k2tvIJYVKfylnJDqD6+DAfdV+JAbj1RMDVzn5+fmwBmpvb4+GwDs5OaEI cLaNu4v5N+iNnOZ1l/ep38uZy06L50+6vCqzOIcIcCMBIi3z6I5HBwT8jizVE/O+RFbq//7MeVAn ZP3EFj14VGq42H/euembbl1u2KEDyqokQl2mJFp59YzLPJWlVEdw2ZYfMijubHp4Miho6uSW40UM iiywSe5v3a+nbu/k963d89fBcPPW0jRSw9Wdl9WxExt1Um9d/qpnJ9PKPm5g/1xKc/JP3i0VzOzS mg4MKo2ubcjUjOS1RZoy9K2u7NL8y0uogpiV0bH+1divGIkHami19AdbBypBUcMq+Ip/IFgCqiAN RiDHeEuM0irxwsMCbBv8/Pz++OMPmLmxYLwrDx8+hNLr7u4Ol9ZD4G0++xvmH1O/8VxkPCoV6Xdy 7+mMTD8HD/gg1Yr0PdeXlNCaLek2Z9vBIWYHKs3tgjid0Wt4eC+eOeqqh1uzQIHHvdyrUmMHEXqZ aG5TPt79KHXLg4yn/ny29Q9lPj1cSHEd4PuRyFxf5PEjPvVr9F1pXqlKY0czG9D6tGOZae0bfx4i EpNNtVR+++bTN2ybmqcqBcAkwEZd3p4rS928pofzeVDEujVf0I1IGpHwmyvbNOSPMJbuODtLYuT3 9W2fn39ToXDxsg+wY1bTuI8WX27U1mqsxIdm+1pjfXMqRBqoQgd4LMC2wdPTEwrG+fPno6OjbZ2W moRWq71582ZERIS3tzc0fKEGi0QiHo9ncYWwdQIx/xSj8lHi3j0JO+/k5rQLW9LFx9mozf7l7NiL CsFn7eZ70SgGIzA/XsIUcYYS6cZ68awpdC6ZRoASbXmlMOjVBsCt6M5lBCw600kgtmwQcOxVRTrt y6gdBkDiOLLcX3YKM4RsoFEZdOYP2tu3Fl/Runwe0p1BsfTxKLQAfjKVpUpJ/EVpsU4rOXBzKp1M lhn0Ia5jF3afIazGGdPS5WkJ9mlt9X7IAgwqjTqr8vo9FmDbALP7tGnT+vfvf/bsWagftk5OjaGw sDApKWno0KGOjo7IFxHavtVh8nPMv8FoUB64NHVbwmEq0/fLLns7egfRSLJd56cfzHwA6B7n7v54 FZTEabLk5xdl+n6sN7lAP1MYgNisagZtWZpeQaZ6Mctrbak0XcH09ajUMaLVG6QqDbR+zZ90SQWJ PGY9Fv1lSaghtGp9mUV2NKVPcsk8Lt1kxZblX/s58ZSLaEq0z0ufL03hgwKanSPD1DWjVcsNBl1k nY1TmkazyeBO/OqlV9cczB47wqMGjKm1CIylIvvBqi/iPyhPqnHFrLbj4+MzZsyYxYsXy2QyW6el ZlBQUDB//vzo6OiAgABXV1cUgAYFzcfqW6PJTPl56+O//H3mbBh0PsY3mEYmEXqdUeAX7tk+3DmQ SSs0kEvYJLJKn5ZdcoFNZpBBQmrp80njlcoclaaMxfWv4PqgJ7QEUbFJhMMV6/TKIkU+Ehajtuh+ WYaAac+mvXAqJPGc6eosWZbBiHYxZGVdItEEdlS20SA/l/h7pt5xbPvhHKvMpidURoJENkdMJ0zR YIlAz1b2TB6bzgvz7BbC5RA1tpglfdj8B3e4puaM2sGgQYP0ev2cOXM+NEf/f0BaWtqUKVO8vb07 d+6MJh6xhD7H6lvDMSY+/ZMtajGmcWd1WVpybkJSQZaGYjcockFsl62xnU1/s9os8qHZf9zi+4kt Z7byCKdRpEfu/Vik1sJjzz3ckiktaB4Sad2aZzToSBQ2BWhlGqXByoqz9+4WRBSdePxHnkZPGBRX Hmz4SwWcBC0EFodEinN7/4gHqTvOZ+dAKS3MOb/s1i4XkbMjVygve3Q26XSTenMihC+HJBmNBiNV QAMGpU6pMwIqjUkmU28nnlGYfzSv9P4zlYKBe0YwrwEPQ7IxBoNh8uTJRUVFGzZs4PP5f3/AB4lK pRoxYkSPHj26detGeQGefaG2oPp5h/ee0nKbokJ3ftM22iJcCvmTBbuHdutlGoYE99+5O+yXYimg h/gSCak6YOeyYPdHn5PUmcv2jyxx/nJ+U+9BO3vJtSp0bKem56YGgRl7vmzY7PsBIQ2fxC2YePEn uN2JFZKvSgCg3g8jTgWziZNnxp4hmnzdehQhvzVvf68ELeAwQ8jaBJkRfNzy4mdhQRfPfPxNBmnd Rz+HvvBtJnSFy05/ejrtBvrI9dz9v5iwZX/0OCUpbBvydRu2ZNntZUrOgGOfrHkvE2Jjaj64D9jG QCFZs2bN3r17Z8+eXbdu3QYNGnh6ekILDxp2tk6aLYH1Qii6EokkJSXl7t27Dx8+HDhwYIcOHeh0 unUDEVbfWgGrc+R3pRk3GDQfIY3HopJKlY9c3D2t96BS+fW929o/j4bBGtT3GvPqigfSAr3BPUgU MbCRaWoQvV5SSDYSirtqUpNegR8X6rXo2JaujgbtvUKSTqHMMBANg4OnztDxrufGaY1EEL1D/6gZ waZA6KrC4qclrACVzuAqCp/UfsP+p8dlWi2JHBDsNWlA3SASUGZICqODBnvyhS+TRWZFurcnM7zR J29PX0AWT47ZSLq4NDn7t62AGuw97KPGE7H6Yl4HtoCrBfAp5OfnQ5m5efPm06dPCwoKNBqNrRNl S6CycjgcWBGpU6dOkyZN4FIsFgOsuB8wBoOeTHk52QhBGLV6jcFgoNHZNNTGa9TklmQZqXYuAlGF Nl/CoMyS5HC4LiIWh4R21WkMBEGlMOjPw7YQ0rIMKeA688VUcx4zGDRavQGQqazn3cNEaWmGge5g x+b8bRbU6eTF8hIjoHDZYj6e6Q/zerAAYzAYDAZjA7B3AAaDwWAwNgALMAaDwWAwNgALMAaDwWAw NgALMAaDwWAwNgALMAaDwWAwNgALMAaDwWAwNgALMAaDwWAwNgALMAaDwWAwNgALMAaDwWAwNgAL MAaDwWAwNgALMAaDwWAwNgALMAaDwWAwNgALMAaDwWAwNgALMAaDwWAwNgALMAaDwWAwNgALMAaD wWAwNgALMAaDwWAwNgALMAaDwWAwNgALMAaDwWAwNuD/NA6xoqG28ywAAAAASUVORK5CYII= --Apple-Mail-7--762321555 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > > Yours, > Joel > > > lisp issue tracker wrote: >> #22: An ETR MUST consume UDP port 4342 packets not addressed to it > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-7--762321555-- From mrw@sandstorm.net Tue Sep 8 08:14: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 0579928C10D for ; Tue, 8 Sep 2009 08:14:21 -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 IiSiC+BibZwC for ; Tue, 8 Sep 2009 08:14:20 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 276013A69C5 for ; Tue, 8 Sep 2009 08:14:19 -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 n88FEklb032704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Sep 2009 11:14:46 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <1164FF37-FB79-4B7E-8517-7E863F926372@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <49C053AD-E5ED-40CE-A518-9BC9D8A51C51@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, 8 Sep 2009 11:14:46 -0400 References: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> <9C2EC0DE-06A5-4929-A120-B40BCE8AD444@sandstorm.net> <57B6EE3D-919C-4D5A-93A3-F2601E450C31@cisco.com> <49C053AD-E5ED-40CE-A518-9BC9D8A51C51@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #18: record count >1 for map request X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 15:14:21 -0000 That looks good, Dino. Thanks! Margaret On Sep 8, 2009, at 10:35 AM, Dino Farinacci wrote: > This this text satisfactory? > > Record Count: The number of records in this Map-Request message. A > record is comprised of the portion of the packet that is labeled > 'Rec' above and occurs the number of times equal to Record Count. > For this version of the protocol, a receiver MUST accept and > process Map-Requests that contain one or more records, but a > sender MUST only send Map-Requests containing one record. > Support > for requesting multiple EIDs in a single Map-Request message will > be specified in a future version of the protocol. > > Dino > > On Sep 8, 2009, at 6:33 AM, Margaret Wasserman wrote: > >> >> Hi Dino, >> >> On Sep 7, 2009, at 10:25 PM, Dino Farinacci wrote: >> >>>> On Sep 7, 2009, at 6:57 PM, lisp issue tracker wrote: >>>>> From the proposed lisp 04 text >>>>> Record Count: The number of records in this request message. A >>>>> record is comprised of the portion of the packet that is labeled >>>>> 'Rec' above and occurs the number of times equal to Record >>>>> count. >>>>> For this version of the protocol specification, a receiver MUST >>>>> accept and process a record count of one or greater but a sender >>>>> MUST always set the record count to one. >> >> This would be clearer to me if you changed the last sentence to read: >> >> "For this version of the protocol, a receiver MUST accept and >> process requests that contain one or more records, but a sender >> MUST only send requests containing one record." >> >> Margaret > From dino@cisco.com Tue Sep 8 08:15: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 62BE93A6A58 for ; Tue, 8 Sep 2009 08:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 R9tGAXn85JhA for ; Tue, 8 Sep 2009 08:15:52 -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 7B39A3A6A43 for ; Tue, 8 Sep 2009 08:15:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANMRpkqrR7O6/2dsb2JhbADFJYhDAY9XBYQY X-IronPort-AV: E=Sophos;i="4.44,352,1249257600"; d="scan'208";a="238727012" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2009 15:16:20 +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 n88FGKtE019876; Tue, 8 Sep 2009 08:16:20 -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 n88FGKns015231; Tue, 8 Sep 2009 15:16:20 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, 8 Sep 2009 08:16:20 -0700 Received: from [192.168.1.3] ([10.21.75.115]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 08:16:19 -0700 Message-Id: From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <1164FF37-FB79-4B7E-8517-7E863F926372@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, 8 Sep 2009 08:16:12 -0700 References: <060.a5bf54888b04ec3930e8ebd5e5ae1d3d@tools.ietf.org> <9C2EC0DE-06A5-4929-A120-B40BCE8AD444@sandstorm.net> <57B6EE3D-919C-4D5A-93A3-F2601E450C31@cisco.com> <49C053AD-E5ED-40CE-A518-9BC9D8A51C51@cisco.com> <1164FF37-FB79-4B7E-8517-7E863F926372@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 15:16:20.0094 (UTC) FILETIME=[519D51E0:01CA3097] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1938; t=1252422980; x=1253286980; 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]=20#18=3A=20record=20count=20>1=2 0=20for=20map=20request |Sender:=20; bh=tBJXsf3G3iZwke2kh0YTIY1RDWHWwyFv7KaFi6xnSRg=; b=ejV2KiRSgVncdocTBP0lN2ZrissSnaiB+y/el4wBaSxm+LvLNpMysLcAF4 tNlfCD7wEbuGPrKNjBCTLkn4a9iHgt9Z2OrEYmuCa4f5LN0/jOloeaQaxscn TGKZI9/GVB; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #18: record count >1 for map request X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 15:15:53 -0000 Thanks for the quick reply. I'll send a new diff file by end of day. Just so I can capture other comments I think I'll get throughout today. Dino On Sep 8, 2009, at 8:14 AM, Margaret Wasserman wrote: > > That looks good, Dino. Thanks! > > Margaret > > On Sep 8, 2009, at 10:35 AM, Dino Farinacci wrote: > >> This this text satisfactory? >> >> Record Count: The number of records in this Map-Request message. A >> record is comprised of the portion of the packet that is labeled >> 'Rec' above and occurs the number of times equal to Record Count. >> For this version of the protocol, a receiver MUST accept and >> process Map-Requests that contain one or more records, but a >> sender MUST only send Map-Requests containing one record. >> Support >> for requesting multiple EIDs in a single Map-Request message will >> be specified in a future version of the protocol. >> >> Dino >> >> On Sep 8, 2009, at 6:33 AM, Margaret Wasserman wrote: >> >>> >>> Hi Dino, >>> >>> On Sep 7, 2009, at 10:25 PM, Dino Farinacci wrote: >>> >>>>> On Sep 7, 2009, at 6:57 PM, lisp issue tracker wrote: >>>>>> From the proposed lisp 04 text >>>>>> Record Count: The number of records in this request message. A >>>>>> record is comprised of the portion of the packet that is labeled >>>>>> 'Rec' above and occurs the number of times equal to Record >>>>>> count. >>>>>> For this version of the protocol specification, a receiver MUST >>>>>> accept and process a record count of one or greater but a sender >>>>>> MUST always set the record count to one. >>> >>> This would be clearer to me if you changed the last sentence to >>> read: >>> >>> "For this version of the protocol, a receiver MUST accept and >>> process requests that contain one or more records, but a sender >>> MUST only send requests containing one record." >>> >>> Margaret >> > From luigi@net.t-labs.tu-berlin.de Tue Sep 8 09:04: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 66B4E28C24C for ; Tue, 8 Sep 2009 09:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_71=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 4CKFGpf1WUgN for ; Tue, 8 Sep 2009 09:04:43 -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 6E22128C1F7 for ; Tue, 8 Sep 2009 09:04:43 -0700 (PDT) Received: from dyn100.net.t-labs.tu-berlin.de (dyn100.net.t-labs.tu-berlin.de [130.149.220.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 31CB47067A63; Tue, 8 Sep 2009 18:05:12 +0200 (CEST) Message-Id: <8E905738-1524-47DF-83BD-DB66E1625C2D@net.t-labs.tu-berlin.de> From: Luigi Iannone 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, 8 Sep 2009 18:05:11 +0200 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Status of Security work X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 16:04:44 -0000 Hi Sam, No big advances so far on the security draft, but work will continue. Luigi On Sep 4, 2009, at 21:31 , Sam Hartman wrote: > > > I'd like to ask where we are with discussion of LISP security. In San > Francisco, a group of people got together to begin thinking about > this. We weren't at a point where we were ready for a presentation in > Stockholm. However,I'd li ke to know what current status is, people's > thoughts on steps going forward are, etc. > > I find that like the deployment model, much of my thought about how > LISP should change is dependent on security analysis we have not done. > I certainly have my own ideas, and if we ever find a quiet moment when > I'm not running around reading messages about UDP or vpacket > headers, I'll work on writing them up. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From luigi@net.t-labs.tu-berlin.de Tue Sep 8 09:27: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 4C3AD3A6802 for ; Tue, 8 Sep 2009 09:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, 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 gSY1b5gCnUqq for ; Tue, 8 Sep 2009 09:27:55 -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 732EA3A68BC for ; Tue, 8 Sep 2009 09:27:55 -0700 (PDT) Received: from dyn100.net.t-labs.tu-berlin.de (dyn100.net.t-labs.tu-berlin.de [130.149.220.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 72C867067A63; Tue, 8 Sep 2009 18:28:25 +0200 (CEST) Message-Id: <28920F62-2A81-4BF4-B306-07E68AAFFE57@net.t-labs.tu-berlin.de> From: Luigi Iannone 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, 8 Sep 2009 18:28:24 +0200 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [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: Tue, 08 Sep 2009 16:27:56 -0000 I am catching up with mails.. On Sep 2, 2009, at 22:27 , Sam Hartman wrote: >>>>>> "Dino" == Dino Farinacci writes: > >>> Now, we're ending up with two mechanisms, one specified in a WG >>> document, one specified in a non-WG document. One of them is >>> optional. > > Dino> This is the sort of thing where part of LISP is doing > Dino> engineering and other ideas are still in research. > > Right. However, as far as I can tell, the WG hasn't come to the > conclusion that map versioning needs additional research. But experimentation yes and this is an experimental WG. > When it was > presented to us, it was presented at least as far as I could tell as > an idea we should integrate into our specs. Yes, but we never converged on the packet header format, and going up to 12 byte is not an option... > I'm not following the > reasoning or discussion that lead from where I think we were in > Stockholm to a conclusion that map versioning needs research but the > other mechanisms do not. If Luigi has been convinced of that, it will > certainly go a long way to convincing me as an individual, but I'm > suspecting we won't get there as a WG without someone actually > explaining the reasoning on the list and others agreeing with it on > the list. The reasoning is very simple. Mail discussion (off mailinglist) has pointed out that in fact we never need both "Version Numbers" and "Loc Status Bits" at the same time in the header thus it is possible to overload the 4 bytes allocated to the "Loc Status Bits". Hence the L bit and R bit came up. Ok, may R-bit must not be described in draft-ietf-lisp, but I still think is a nice an clever solution. Luigi From luigi@net.t-labs.tu-berlin.de Tue Sep 8 09:29: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 D8B523A69D2 for ; Tue, 8 Sep 2009 09:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=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 y8xk1+0oPEeJ for ; Tue, 8 Sep 2009 09:29:28 -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 B9FEA3A6802 for ; Tue, 8 Sep 2009 09:29:27 -0700 (PDT) Received: from dyn100.net.t-labs.tu-berlin.de (dyn100.net.t-labs.tu-berlin.de [130.149.220.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 0EA547067A63; Tue, 8 Sep 2009 18:29:55 +0200 (CEST) Message-Id: From: Luigi Iannone To: Sam Hartman In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-14--757712124 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Sep 2009 18:29:54 +0200 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [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: Tue, 08 Sep 2009 16:29:28 -0000 --Apple-Mail-14--757712124 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 2, 2009, at 21:33 , Sam Hartman wrote: >>>>>> "Luigi" == Luigi Iannone writes: > > >>> If so, why? > > Luigi> Interoperability. > > Luigi> Let me try to explain the idea about the R-bit (and > Luigi> hopefully addressing Joel's concerns). > > Luigi> The basic idea is to have a bit that allows to overload two > Luigi> fields of the LISP header: Nonce and Loc-bits. > > Luigi> In this way, when R = 1 we can put version numbers in the > Luigi> overloaded fields. > > Luigi> Concerning draft-iannone-lisp-versioning-00, will update it > Luigi> in order to respect bit's position of the new header and to > Luigi> be coherent with draft-ietf-lisp-04. > > Luigi> Having said that, we have also to keep in mind > Luigi> interoperability with boxes that do not support the R-bit. > Luigi> Those boxes will ignore the R bit, thus making mandatory > Luigi> that when R=1 then N and L must be 0 allows to safely make > Luigi> the ETR ignore the overloaded fields. Doing otherwise > Luigi> would lead to totally incompatible headers and > Luigi> implementations. We really do not need that. > > OK. So, what you're saying is that we want to have two mechanisms for > handling map data. One works through the control plane and will be > specified in draft-ietf-lisp-lisp. > Everyone has to implement that. > > The other one is specified in your draft; it's turned on by setting > the r bit. > > We could potentially do something like that, although I don't think > the text in Dino's proposed changes for 04 actually accomplishes that. > However before we start discussing specific text I'd like to > understand why we want to do that. > > Originally I thought you wanted everyone to implement map versioning. > The impression I get from the Stockholm minutes is that one of Dino or > Darrel (unclear who) was going to propose some hybrid mechanism. > > Now, we're ending up with two mechanisms, one specified in a WG > document, one specified in a non-WG document. Not yet a WG-document ;-) > One of them is > optional. What you consider optional I consider incrementally deployable... Luigi > > I'm missing the chunk of reasoning where you decided that your > mechanism should be optional and was something only some boxes would > implement. --Apple-Mail-14--757712124 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Sep 2, 2009, = at 21:33 , Sam Hartman wrote:

"Luigi" =3D=3D Luigi Iannone = <luigi@net.t-labs.tu-berlin.d= e> = writes:


If so, = why?

   Luigi> = Interoperability.

   Luigi> Let me try to = explain the idea about the R-bit (and
   Luigi> = hopefully addressing Joel's concerns).

=    Luigi> The basic idea is to have a bit that allows = to overload two
   Luigi> fields of the LISP = header: Nonce and Loc-bits.

   Luigi> In this = way, when R =3D 1 we can put version numbers in the
=    Luigi> overloaded fields.

=    Luigi> Concerning draft-iannone-lisp-versioning-00, = will update it
   Luigi> in order to respect bit's = position of the new header and to
   Luigi> be = coherent with draft-ietf-lisp-04.

   Luigi> = Having said that, we have also to keep in mind
=    Luigi> interoperability with boxes that do not = support the R-bit.
   Luigi> Those boxes will = ignore the R bit, thus making mandatory
   Luigi> = that when R=3D1 then N and L must be 0 allows to safely make
=    Luigi> the ETR ignore the overloaded fields. =  Doing otherwise
   Luigi> would lead to = totally incompatible headers and
   Luigi> = implementations. We really do not need that.

OK.  So, what = you're saying is that we want to have two mechanisms for
handling map = data.  One works through the control plane and will be
specified = in draft-ietf-lisp-lisp.
Everyone has to implement that.

The = other one is specified in your draft; it's turned on by setting
the r = bit.

We could potentially do something like that, although I = don't think
the text in Dino's proposed changes for 04 actually = accomplishes that.
However before we start discussing specific text = I'd like to
understand why we want to do that.

Originally I = thought you wanted everyone to implement map versioning.
The = impression I get from the Stockholm minutes is that one of Dino = or
Darrel (unclear who) was going to propose some hybrid = mechanism.

Now, we're ending up with two mechanisms, one = specified in a WG
document, one specified in a non-WG = document.

Not yet a WG-document = ;-)

 One of them = is
optional.

What you = consider optional I consider incrementally = deployable...

Luigi



I'm missing the chunk of reasoning where = you decided that your
mechanism should be optional and was something = only some boxes = would
implement.

= --Apple-Mail-14--757712124-- From jmh@joelhalpern.com Tue Sep 8 09:45: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 08DD83A688C for ; Tue, 8 Sep 2009 09:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=-0.274, 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 FnUM56i048wY for ; Tue, 8 Sep 2009 09:45:37 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 21BE028C174 for ; Tue, 8 Sep 2009 09:45:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 8DFE8322800B; Tue, 8 Sep 2009 09:46:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.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 hgblob.tigertech.net (Postfix) with ESMTP id 9BE493230F92; Tue, 8 Sep 2009 09:46:06 -0700 (PDT) Message-ID: <4AA68A4B.7070307@joelhalpern.com> Date: Tue, 08 Sep 2009 12:46:03 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <060.a6bdaf04b35955374257c35fafb40c20@tools.ietf.org> <4AA66376.3090107@cisco.com> <72871E32-9956-4888-9E4C-6E58E4D44631@sandstorm.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: trac@localhost.amsl.com, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] #19: mobility bit in map reply X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 16:45:38 -0000 The usual practice with other protocols is to define a flags filed that is larger than needed, and reserve the unused bits for later assignment. This is based on the view that: 1) One generally does not know at the start all the flags that will eventually be needed 2) That it is not desirable to rev the base spec just to add flags needed for some specific function. 3) That bits should be described in the document where they are used, as otherwise the description is actually meaningless. Yours, Joel Dino Farinacci wrote: > I don't see any value in having the main spec depend on other > specifications. As someone who has implemented protocols for nearly 30 > years, it has always been a hassle to chase down code-points and header > formats in various documents. So it is much simpler and cohesive to have > it in one place. > > Having said that, in the future we should have an IANA based assignment > document. But all the flags (maybe with the exception of the M-bit in > the Map-Reply) are pretty pertinent to the core functionality of LISP. > > But we made a decision early (with CONS, ALT, INTERWORKING, and MS) that > we would put the packet formats in one place. We decided to have a > "one-way dependency arrow" for the documents. That is, all the documents > point to the main spec for packet formats and detailed procedures and > the main document references the individual component documents which > describe introductory ideas and specific details about the elements of > operation for their respective functions. > > I would like to keep it that way. Or else, we get caught up in doing > documentation procedures more than focusing on the implementation, > experiments, and deployment. And throwing more people on the problem > doesn't really help. > > Dino > > On Sep 8, 2009, at 7:07 AM, Margaret Wasserman wrote: > >> >> On Sep 8, 2009, at 10:00 AM, Eliot Lear wrote: >> >>> On 9/8/09 1:13 AM, lisp issue tracker wrote: >>>> I think that the best way forward is for us to decide on an IANA >>>> assignment policy for the flags in the map reply. If that policy >>>> permits the authors of the mobility arch draft to request a flag then >>>> they can do so; if after whatever review we decide is necessary we >>>> approve assigning a flag, then do so. Alternatively, put this on hold >>>> until mobility is in scope for our chater. >>>> >>> >>> Sam, this is a great way forward. It tackles not just the M bit but >>> also potentially issues revolving around the R bit as well. >> >> Yes, and all of the other reserved bits for which there may be >> eventual uses. >> >> Dino, I have a good deal of experience writing IANA considerations >> sections (and reviewing them, enforcing them, etc.), so let me know if >> I can help with this. >> >> 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 dino@cisco.com Tue Sep 8 09:51: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 A2DBC28C27C for ; Tue, 8 Sep 2009 09:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 qq0LOgiI1RUg for ; Tue, 8 Sep 2009 09:51:53 -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 6BB6228C243 for ; Tue, 8 Sep 2009 09:51:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJEopkqrR7MV/2dsb2JhbADHEIhDAY9lBYQYgks X-IronPort-AV: E=Sophos;i="4.44,353,1249257600"; d="scan'208";a="384410446" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 08 Sep 2009 16:52:24 +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 n88GqNQl021176; Tue, 8 Sep 2009 09:52: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 n88GqNGa009631; Tue, 8 Sep 2009 16:52: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); Tue, 8 Sep 2009 09:52:23 -0700 Received: from [192.168.1.3] ([10.21.75.115]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 09:52:23 -0700 Message-Id: <672964DD-E47E-409D-890D-58CE450E8836@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AA68A4B.7070307@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, 8 Sep 2009 09:52:22 -0700 References: <060.a6bdaf04b35955374257c35fafb40c20@tools.ietf.org> <4AA66376.3090107@cisco.com> <72871E32-9956-4888-9E4C-6E58E4D44631@sandstorm.net> <4AA68A4B.7070307@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 16:52:23.0572 (UTC) FILETIME=[BCEA4540:01CA30A4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3915; t=1252428744; x=1253292744; 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#19=3A=20mobility=20bit=20in=2 0map=20reply |Sender:=20; bh=IxrazvUU/3R+mBxqBZXxGTqS0173n48hbEvpKOZ1zws=; b=FGmNr3mD2nQKYYGyQzu5wgPicAXQzVYuV2VuioRKImtqE3UEkgzrPR+KeW 1K1CsKf+VO4/HuBEVAEqnO8+9dMdS803dEcuS64/L4D3tTPI4ucWblARaYER BcSRP3hVavZZrSOwQ1bt3Z1H++Dq8/GO2Wcsxcu3Jy+AUwRJYtZhw=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: trac@localhost.amsl.com, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] #19: mobility bit in map reply X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 16:51:54 -0000 > The usual practice with other protocols is to define a flags filed > that is larger than needed, and reserve the unused bits for later > assignment. Well we did this with the data-header because we envisioned having more flags in the future. We didn't do this in the fields of the Map-Request, Map-Reply, and Map- Register because those reserved fields may not be flags in the future. We try to do field allocations "from outside inward" so we leave contiguous bits so we have flexibility for multi-bit fields. Remember Kampai Addressing by Paul Francis? Same idea. > This is based on the view that: > 1) One generally does not know at the start all the flags that will > eventually be needed Right. > 2) That it is not desirable to rev the base spec just to add flags > needed for some specific function. Right, but that is usually after the spec is stable and not in flux. We are currently in a flux state. But .... is this true for an experimental RFC? > 3) That bits should be described in the document where they are > used, as otherwise the description is actually meaningless. Right, definitely agree. Dino > > Yours, > Joel > > Dino Farinacci wrote: >> I don't see any value in having the main spec depend on other >> specifications. As someone who has implemented protocols for nearly >> 30 years, it has always been a hassle to chase down code-points and >> header formats in various documents. So it is much simpler and >> cohesive to have it in one place. >> Having said that, in the future we should have an IANA based >> assignment document. But all the flags (maybe with the exception of >> the M-bit in the Map-Reply) are pretty pertinent to the core >> functionality of LISP. >> But we made a decision early (with CONS, ALT, INTERWORKING, and MS) >> that we would put the packet formats in one place. We decided to >> have a "one-way dependency arrow" for the documents. That is, all >> the documents point to the main spec for packet formats and >> detailed procedures and the main document references the individual >> component documents which describe introductory ideas and specific >> details about the elements of operation for their respective >> functions. >> I would like to keep it that way. Or else, we get caught up in >> doing documentation procedures more than focusing on the >> implementation, experiments, and deployment. And throwing more >> people on the problem doesn't really help. >> Dino >> On Sep 8, 2009, at 7:07 AM, Margaret Wasserman wrote: >>> >>> On Sep 8, 2009, at 10:00 AM, Eliot Lear wrote: >>> >>>> On 9/8/09 1:13 AM, lisp issue tracker wrote: >>>>> I think that the best way forward is for us to decide on an IANA >>>>> assignment policy for the flags in the map reply. If that policy >>>>> permits the authors of the mobility arch draft to request a flag >>>>> then >>>>> they can do so; if after whatever review we decide is necessary we >>>>> approve assigning a flag, then do so. Alternatively, put this >>>>> on hold >>>>> until mobility is in scope for our chater. >>>>> >>>> >>>> Sam, this is a great way forward. It tackles not just the M bit >>>> but >>>> also potentially issues revolving around the R bit as well. >>> >>> Yes, and all of the other reserved bits for which there may be >>> eventual uses. >>> >>> Dino, I have a good deal of experience writing IANA considerations >>> sections (and reviewing them, enforcing them, etc.), so let me >>> know if I can help with this. >>> >>> 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 Sep 8 09:57: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 9BC1528C2A0 for ; Tue, 8 Sep 2009 09:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-1.471, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=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 RcWXjZl9T-hi for ; Tue, 8 Sep 2009 09:57:23 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id B6FC028C297 for ; Tue, 8 Sep 2009 09:57:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 863583230F7E; Tue, 8 Sep 2009 09:57:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.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 hgblob.tigertech.net (Postfix) with ESMTP id 901943230F84; Tue, 8 Sep 2009 09:57:52 -0700 (PDT) Message-ID: <4AA68D0B.9040106@joelhalpern.com> Date: Tue, 08 Sep 2009 12:57:47 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <060.ea8474f8e9e720ff4a5501041a5c944c@tools.ietf.org> <4AA66AC4.5010108@joelhalpern.com> <14869896-3B75-4DDF-B075-FF507FCEEB5B@cisco.com> In-Reply-To: <14869896-3B75-4DDF-B075-FF507FCEEB5B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] #22: An ETR MUST consume UDP port 4342 packets not addressed to it X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 16:57:25 -0000 Yes, I got the map resolver and map server backwards. But that does not change the question. Fundamentally, for LISP control packets, I do not see why we need an inner IP header. The Control packet format itself has enough information about the source and target of the message. You suggest that there would be a problem if the RLoc is IPv6, but the connectivity to the Map Resolver is IPv4. Presumably, given that the ITR has IPv4 connectivity, there is also an IPv4 RLoc. Whether the EID is v4 or v6 is irrelevant, as that is in the control packet. Even strange mixings of v4 Mapping and v6 RLocs seem possible even without the outer header. The RLoc that the sending ITR uses in the control part of the message does not ahve to match the RLoc it uses as the UDP source address. You seem to be assuming that in the Map Request the target EID has to go in the inner destination IP address field. Given that the address is in the control message, I do not see why that is the case. It may be the case that within the ALT we want to send the packets that way. But we are not discussing the encapsulation between ALT elements. We are discussing the ITR->MR and MS->ETR encapsulation. It seems that those boxes at the edge of the ALT can deal with building headers that are suitable for traversing the ALT. Just to complete the story, for the last leg from the MS to the ETR, I do not see why the RLoc of the ITR needs to appear in the IP (inner or outer) header. It appears in the control message itself. The ETR can get the information from there for composing the direct response. Still confused, Joel Dino Farinacci wrote: > Joel, see the enclosed slide. Follow the steps (1) through (5). That is > what is implemented now and reflects what is in the current set of specs > (-04 doesn't change this procedure). This should help clarify things. > >> In trying to understand this question, and its implications, I seem to >> have totally confused myself. (Sorry Dino. I think you explained >> this to me once before, and convinced me. But I can not reconstruct >> it now.) >> >> The underlying goal is to get a LISP control message, in this case a >> mapping request, from the source to the entity that can provide a >> useful answer. > > Right. > >> The ITR wants to send the request to its Map Server. > > The ITR sends it to the mapping data system. The ITR is configured with > the locator address of the Map-Resolver. Once the encapsulated > Map-Request gets to the Map-Resolver, the mapping database system gets > the Map-Request to the authoritative ETR. > > In ALT, that means the Map-Request gets to the Map-Server the ETR > registered to. Then the Map-Server encapsulates the Map-Request to get > it to the ETR. > > Remember, the fundamental premise of LISP is "outer headers have > locators in them" and "inner headers have EIDs in them". This is true > with control packets, but control packets can have either locators or > EIDs in the inner header. > >> The Map Server send the request over the ALT to the relevant Map >> Responder. >> The Map Responder sends the request to a relevant ETR. > > No, the text above should clarify this. > >> The Control request is an IP packet, with a UDP header, addressed to >> UDP port 4342. The body of the request includes the information as to >> the EID whose mapping is being sought, and the RLOC of the ITR who is >> making the request. > > Right. But that packet can't leave the ITR or else the destination > address (the EID being sought) cannot be routed (assuming that > EID-prefixes are not in the underlying routing). So the ITR must > encapsulate the Map-Request so there can be locators in the other header. > > Also, if the Map-Request is an IPv6 Map-Request and you only have an > IPv4 path to the mapping database system, then the inner header would > have a source address of an IPv6 locator, a destination address of an > IPv6 EID and the outer header would have source and destination IPv4 > locators (see spec how Map-Reply gets returned in the mixed-AF case). > >> By assumption, that RLOC is usable by the end ETR to send the response >> back to the ITR. > > Yes, the Map-Reply is sent directly from ETR to ETR with locators in the > headers. There is no encapsulated Map-Reply. > >> So why do we need two UDP headers (and two IP headers.) > > Should be clear now? See slide? > >> The ITR can send the packet to the MS> So it should only need on IP >> header, source=ITR RLoc, Dest=MS RLoc. And one UDP header (for >> control message.) >> >> Similarly, the MR needs to send the message to the ETR. But the MR >> know the ETR Rloc. So a single IP header, source=MS RLoc, dest=ETR >> Rloc, and a single UDP header for the control message, would seem >> sufficient. >> >> This would mean that nodes are only processing messages addressed to >> themselves. This would also seem to be completely separate from the >> question of what format messages are sent over the GRE tunnel inside >> the ALT. > > There is one case where an ETR will process a control packet not > addressed to it. We found this to be an issue 2 weeks ago while doing > our implementation. > > We will document this on the mailing list once -04 gets out. It should > address the concerns that was brought up in the tracker #22 item. > > Vince will send email once we get -04 out. > >> Assuming I am missing something basic, I suspect we need some more >> text somewhere. I paged back and forth through the LISP spec, the >> LISP-ALT spec, and the LISP-MS spec. > > Hmm. Maybe it's because you have the map-server and map-resolver > functions not square? But we will try to clarify the spec. > > Dino > > > > > >> >> Yours, >> Joel >> >> >> lisp issue tracker wrote: >>> #22: An ETR MUST consume UDP port 4342 packets not addressed to it >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > From luigi@net.t-labs.tu-berlin.de Tue Sep 8 10:12: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 8478028C284 for ; Tue, 8 Sep 2009 10:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=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 h7aySg-thRf1 for ; Tue, 8 Sep 2009 10:12:39 -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 AFD2B28C1F8 for ; Tue, 8 Sep 2009 10:12:38 -0700 (PDT) Received: from dyn100.net.t-labs.tu-berlin.de (dyn100.net.t-labs.tu-berlin.de [130.149.220.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id E876D7067A63; Tue, 8 Sep 2009 19:13:08 +0200 (CEST) Message-Id: <297D7394-4758-4383-AC50-11672B132C52@net.t-labs.tu-berlin.de> From: Luigi Iannone To: Noel Chiappa In-Reply-To: <20090904152138.D22FD6BE5F8@mercury.lcs.mit.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-15--755118384 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Sep 2009 19:13:08 +0200 References: <20090904152138.D22FD6BE5F8@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] [#16]: Desire to expand data plane for map versioning or handle in the control plane X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 17:12:42 -0000 --Apple-Mail-15--755118384 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sep 4, 2009, at 17:21 , Noel Chiappa wrote: [snip] > > (Note that it could also be either 'forward' or 'backward'; i.e. the > ITR could > tell the ETR what mapping it's using for the destination EID, and > the ETR > would notify the ITR if it's old; or the ETR could tell the ITR what > the > latest mapping is for that EID, and the ITR would have to notice if > its > mapping is outdated.) > This is exactly the idea of mapping versioning.. (modulo the fact that we propose piggybacking and modulo the fact that you prefer a checksum approach). Luigi > But maybe I'm missing something? > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-15--755118384 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Sep 4, 2009, = at 17:21 , Noel Chiappa wrote:

[snip]


(Note that it = could also be either 'forward' or 'backward'; i.e. the ITR could
tell = the ETR what mapping it's using for the destination EID, and the = ETR
would notify the ITR if it's old; or the ETR could tell the ITR = what the
latest mapping is for that EID, and the ITR would have to = notice if its
mapping is = outdated.)


This is exactly = the idea of mapping versioning.. (modulo the fact that we propose = piggybacking and modulo the fact that you prefer a checksum = approach).

Luigi

But maybe I'm missing something?

= Noel
_______________________________________________
lisp = mailing list
lisp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/lisp

= --Apple-Mail-15--755118384-- From jari.arkko@piuha.net Tue Sep 8 11:01: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 CB86228C0DD for ; Tue, 8 Sep 2009 11:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 vay6FZJSE8VC for ; Tue, 8 Sep 2009 11:01:13 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7790C28C16F for ; Tue, 8 Sep 2009 11:01:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 98DF4D620E; Tue, 8 Sep 2009 21:01:43 +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 zucahXVY+qW9; Tue, 8 Sep 2009 21:01:43 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1C1C6D620D; Tue, 8 Sep 2009 21:01:43 +0300 (EEST) Message-ID: <4AA69C06.6040906@piuha.net> Date: Tue, 08 Sep 2009 21:01:42 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Sam Hartman References: <20090821211819.7C6006BE557@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Noel Chiappa , lisp@ietf.org Subject: [lisp] Security through NATs (Was: Re: #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: Tue, 08 Sep 2009 18:01:15 -0000 Sam, > 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). > Or any data object security mechanism, such as signing the records you transfer. Jari From jari.arkko@piuha.net Tue Sep 8 11:01: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 CAF8128C28A for ; Tue, 8 Sep 2009 11:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 p+PIllNODXEp for ; Tue, 8 Sep 2009 11:01:29 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id BE1DC28C16F for ; Tue, 8 Sep 2009 11:01:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 24F92D620E; Tue, 8 Sep 2009 21:02:00 +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 R+b6Pvh7pO-B; Tue, 8 Sep 2009 21:01:59 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B7680D620D; Tue, 8 Sep 2009 21:01:59 +0300 (EEST) Message-ID: <4AA69C17.4090902@piuha.net> Date: Tue, 08 Sep 2009 21:01:59 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Sam Hartman References: <20090907234129.BB52151C9@carter-zimmerman.suchdamage.org> In-Reply-To: <20090907234129.BB52151C9@carter-zimmerman.suchdamage.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Confirming Consensus on RLOC probing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 18:01:30 -0000 I agree. Jari From mrw@sandstorm.net Tue Sep 8 12:44: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 B48D43A67A6 for ; Tue, 8 Sep 2009 12:44:04 -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 r+iGVwR4RAXZ for ; Tue, 8 Sep 2009 12:44:03 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 88EB53A6991 for ; Tue, 8 Sep 2009 12:43: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 n88JiG1e045703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Sep 2009 15:44:16 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: "Joel M. Halpern" In-Reply-To: <4AA68D0B.9040106@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, 8 Sep 2009 15:44:15 -0400 References: <060.ea8474f8e9e720ff4a5501041a5c944c@tools.ietf.org> <4AA66AC4.5010108@joelhalpern.com> <14869896-3B75-4DDF-B075-FF507FCEEB5B@cisco.com> <4AA68D0B.9040106@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #22: An ETR MUST consume UDP port 4342 packets not addressed to it X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 19:44:04 -0000 On Sep 8, 2009, at 12:57 PM, Joel M. Halpern wrote: > Yes, I got the map resolver and map server backwards. But that does > not change the question. > > Fundamentally, for LISP control packets, I do not see why we need an > inner IP header. The Control packet format itself has enough > information about the source and target of the message. > > You suggest that there would be a problem if the RLoc is IPv6, but > the connectivity to the Map Resolver is IPv4. > Presumably, given that the ITR has IPv4 connectivity, there is also > an IPv4 RLoc. > Whether the EID is v4 or v6 is irrelevant, as that is in the control > packet. > Even strange mixings of v4 Mapping and v6 RLocs seem possible even > without the outer header. The RLoc that the sending ITR uses in the > control part of the message does not ahve to match the RLoc it uses > as the UDP source address. > > You seem to be assuming that in the Map Request the target EID has > to go in the inner destination IP address field. Given that the > address is in the control message, I do not see why that is the case. > It may be the case that within the ALT we want to send the packets > that way. But we are not discussing the encapsulation between ALT > elements. We are discussing the ITR->MR and MS->ETR encapsulation. > It seems that those boxes at the edge of the ALT can deal with > building headers that are suitable for traversing the ALT. > > Just to complete the story, for the last leg from the MS to the ETR, > I do not see why the RLoc of the ITR needs to appear in the IP > (inner or outer) header. It appears in the control message itself. > The ETR can get the information from there for composing the direct > response. I'm suffering from the same confusion as Joel... I don't see any value to encapsulating the ITR-to-MR and MS-to-ETR control plane packets, and I see considerable cost to doing so because it adds complexity and processing overhead to what should be a simple forwarding function in the LISP data plane. I understand that the ALT is special, but at the edges let's send the control packets directly to their intended recipients on the LISP control port, instead of encapsulating them. Margaret From hartmans@mit.edu Tue Sep 8 12:58: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 73B5228C1A7 for ; Tue, 8 Sep 2009 12:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 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 YyXfZzomV0Wp for ; Tue, 8 Sep 2009 12:58: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 ADFB128C16B for ; Tue, 8 Sep 2009 12:58:35 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4355551CC; Tue, 8 Sep 2009 15:58:52 -0400 (EDT) To: Luigi Iannone References: From: Sam Hartman Date: Tue, 08 Sep 2009 15:58:52 -0400 In-Reply-To: (Luigi Iannone's message of "Tue\, 8 Sep 2009 18\:29\:54 +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] #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: Tue, 08 Sep 2009 19:58:36 -0000 Do you want the WG to consider adopting your map versioning draft? If so, are we ready to consider that now or do you want to consider it when you've refined things more? If you want to refine things more, what refinements do you want to make? From hartmans@mit.edu Tue Sep 8 13:09: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 73B313A67F6 for ; Tue, 8 Sep 2009 13:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 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 5j7U6N0vTjUN for ; Tue, 8 Sep 2009 13:09: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 D7DA63A6822 for ; Tue, 8 Sep 2009 13:09:36 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 56B6A51CC; Tue, 8 Sep 2009 16:09:53 -0400 (EDT) To: Margaret Wasserman References: <20090902225425.834666BE641@mercury.lcs.mit.edu> <0738CF8A-EBB2-4D1E-B1A5-6371BC26AE4F@sandstorm.net> From: Sam Hartman Date: Tue, 08 Sep 2009 16:09:53 -0400 In-Reply-To: <0738CF8A-EBB2-4D1E-B1A5-6371BC26AE4F@sandstorm.net> (Margaret Wasserman's message of "Fri\, 4 Sep 2009 17\:33\:39 -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: Noel Chiappa , lisp@ietf.org Subject: [lisp] Consensus call on LISP 04 header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 20:09:38 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> Hi Dino, > (1) Leave the N and L bit settings as defined in -04. They are used >> as "field-enable" bits. (2) Don't have an R-bit since we >> cannot define how to use it or how to ignore it. (3) The E-bit >> is still used for echo-noncing. >> >> Now when the research guys want to use the Nonce and >> Loc-Status-Bits fields for a new use, all they have to do is >> set N and L to 0. Implementations which are spec compliant use >> the N and L fields when the "field-enable" bits are >> set. Otherwise, they just decap the packet and don't use those >> fields. >> >> How does that sound? Margaret> That would work. As far as I can tell, no one has objected to this proposal. Unless I hear objections by Friday, September 18, I think we have a consensus. From jari.arkko@piuha.net Tue Sep 8 13: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 1ECC43A68DB for ; Tue, 8 Sep 2009 13:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 xKvdMsDQkSag for ; Tue, 8 Sep 2009 13:39:49 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8ADD83A68CD for ; Tue, 8 Sep 2009 13:39:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 065E0D620E; Tue, 8 Sep 2009 23:40:20 +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 BieIeCWjcRTX; Tue, 8 Sep 2009 23:40:19 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 278F4D620D; Tue, 8 Sep 2009 23:40:19 +0300 (EEST) Message-ID: <4AA6C132.5020507@piuha.net> Date: Tue, 08 Sep 2009 23:40:18 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Margaret Wasserman References: <20090821151445.60C746BE5F3@mercury.lcs.mit.edu> <17D8503C-FFEB-4A16-BC44-0470979FBAAB@sandstorm.net> In-Reply-To: <17D8503C-FFEB-4A16-BC44-0470979FBAAB@sandstorm.net> Content-Type: text/plain; charset=us-ascii; 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: Tue, 08 Sep 2009 20:39:51 -0000 Margaret, Noel, > 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? I realize that we are past the question of NAT boxes putting in corrupt checksums. Nevertheless, my preference is that Lisp should be implementable on a wide variety of devices. I realize that from a big iron manufacturer point of view Lisp implementations on general purpose computer platforms do not look very interesting. But often new technology that we develop gets popular via implementations that started out that way. BSD based routers etc. Jari From dino@cisco.com Tue Sep 8 14:45: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 3E4D73A6A89 for ; Tue, 8 Sep 2009 14:45:38 -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 S-h+MW2eCbrB for ; Tue, 8 Sep 2009 14:45: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 1C5773A69BB for ; Tue, 8 Sep 2009 14:45:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIJtpkqrR7O6/2dsb2JhbADFY4hDAZALBYQYgVk X-IronPort-AV: E=Sophos;i="4.44,354,1249257600"; d="scan'208";a="202723133" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 08 Sep 2009 21:46:08 +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 n88Lk8p4019457; Tue, 8 Sep 2009 14:46: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 n88Lk8fb022363; Tue, 8 Sep 2009 21:46: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); Tue, 8 Sep 2009 14:46:07 -0700 Received: from [192.168.5.7] ([10.21.83.229]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 14:46:07 -0700 Message-Id: <15F5C9BC-F07F-4B03-A443-54D044BFAA66@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 v936) Date: Tue, 8 Sep 2009 14:46:04 -0700 References: <060.ea8474f8e9e720ff4a5501041a5c944c@tools.ietf.org> <4AA66AC4.5010108@joelhalpern.com> <14869896-3B75-4DDF-B075-FF507FCEEB5B@cisco.com> <4AA68D0B.9040106@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 21:46:07.0664 (UTC) FILETIME=[C5B14B00:01CA30CD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2858; t=1252446368; x=1253310368; 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]=20#22=3A=20An=20ETR=20MUST=20con sume=20UDP=20port=204342=20packets=20not=20addressed=20to=20 it |Sender:=20; bh=tAIMozxwlMNTCXkQqqw8ZLXeBA63wd7O9N/gb0yZey0=; b=VK9Gua1uMRtcQXFp7/lB9fCSnPsHL4VZHNdLCHGwYnhRMNNOKw2lMMMLKF J7zAsXEG+eQRetyFqYJ+EWAT0e610N2xluO/bdhx4BlfCpe/qLCVnycZADPK tfQK3X7J8e; 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] #22: An ETR MUST consume UDP port 4342 packets not addressed to it X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 21:45:38 -0000 > On Sep 8, 2009, at 12:57 PM, Joel M. Halpern wrote: > >> Yes, I got the map resolver and map server backwards. But that >> does not change the question. >> >> Fundamentally, for LISP control packets, I do not see why we need >> an inner IP header. The Control packet format itself has enough >> information about the source and target of the message. >> >> You suggest that there would be a problem if the RLoc is IPv6, but >> the connectivity to the Map Resolver is IPv4. >> Presumably, given that the ITR has IPv4 connectivity, there is also >> an IPv4 RLoc. >> Whether the EID is v4 or v6 is irrelevant, as that is in the >> control packet. >> Even strange mixings of v4 Mapping and v6 RLocs seem possible even >> without the outer header. The RLoc that the sending ITR uses in >> the control part of the message does not ahve to match the RLoc it >> uses as the UDP source address. >> >> You seem to be assuming that in the Map Request the target EID has >> to go in the inner destination IP address field. Given that the >> address is in the control message, I do not see why that is the case. >> It may be the case that within the ALT we want to send the packets >> that way. But we are not discussing the encapsulation between ALT >> elements. We are discussing the ITR->MR and MS->ETR >> encapsulation. It seems that those boxes at the edge of the ALT >> can deal with building headers that are suitable for traversing the >> ALT. >> >> Just to complete the story, for the last leg from the MS to the >> ETR, I do not see why the RLoc of the ITR needs to appear in the IP >> (inner or outer) header. It appears in the control message >> itself. The ETR can get the information from there for composing >> the direct response. > > > I'm suffering from the same confusion as Joel... > > I don't see any value to encapsulating the ITR-to-MR and MS-to-ETR > control plane packets, and I see considerable cost to doing so > because it adds complexity and processing overhead to what should be a This is an originated control packet, so the control plane puts the encapsulated header on. So it is very simple. The data-plane need not be involved. If you choose any other method you can't support all the combinations we tend to support. That is mixed address-families, xTRs attached to the ALT, LISP-naive ALT routers, and there are more. > simple forwarding function in the LISP data plane. I understand > that the ALT is special, but at the edges let's send the control > packets directly to their intended recipients on the LISP control > port, instead of encapsulating them. You can't do that because the packet will be dropped by the PE router because there is no route in the underlying routing for the EID. Dino From jmh@joelhalpern.com Tue Sep 8 15:01: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 92AC13A6899 for ; Tue, 8 Sep 2009 15:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.858 X-Spam-Level: X-Spam-Status: No, score=-2.858 tagged_above=-999 required=5 tests=[AWL=-0.259, 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 2BgyR1sr-7FW for ; Tue, 8 Sep 2009 15:01:35 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id A6AC73A6A11 for ; Tue, 8 Sep 2009 15:01:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id E7B253230F81; Tue, 8 Sep 2009 15:02:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.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 hgblob.tigertech.net (Postfix) with ESMTP id 056213230F7E; Tue, 8 Sep 2009 15:02:05 -0700 (PDT) Message-ID: <4AA6D459.4080105@joelhalpern.com> Date: Tue, 08 Sep 2009 18:02:01 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <060.ea8474f8e9e720ff4a5501041a5c944c@tools.ietf.org> <4AA66AC4.5010108@joelhalpern.com> <14869896-3B75-4DDF-B075-FF507FCEEB5B@cisco.com> <4AA68D0B.9040106@joelhalpern.com> <15F5C9BC-F07F-4B03-A443-54D044BFAA66@cisco.com> In-Reply-To: <15F5C9BC-F07F-4B03-A443-54D044BFAA66@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] #22: An ETR MUST consume UDP port 4342 packets not addressed to it X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 22:01:36 -0000 As far as I can tell, all of the different address combinations can be handled without the double-header on the leaf->Map Service connection. The necessary data is in the Map Request. And this does not have to match the enclosing IP header as to IP version. (It does have to match the kind of EID the ALT is prepared to handle, but that is true anyway.) What can not be handled is transparently removing the ITR - Map Service connection. But I do not understand the issue. Given how simple the Map Responder (and Map Server?) logic are, it would seem natural to include that in any LISP-ALT leaf device (probably in any LISP-ALT device, for simplicity. Given that ALT devices talk to each other over GRE, if we want the ITR to send the query into the ALT system, it presumably has to do so over a GRE tunnel. So the ITR logic is now different anyway. So it can change the encapsulation. (If the ITR does not have to use GRE, then the LISP-ALT device is supporting two formats, and it might as well support the format that simplifies the client.) I suspect one of the keys to the difference is that I do not expect that the device which receives requests from clients can simply forward those based on the EID in the IP header. I expect validation is needed, cache checking, etc. And given taht we are dealing with LISP, the need for such a device to add an extra header seems irrrelevant to me. I am also confused because it seems that your unstated goal is for the Map Responder (and Map Server) protocol to be the same as the protocol that you are trying to isolate the ITR/ETR from. I thought the goal was to keep the ITR / ETR simpler. Admittedly, simplicity is in the eye of the beholder. And there is always the question of where the necessary complexity belongs. Yours, Joel Dino Farinacci wrote: >> On Sep 8, 2009, at 12:57 PM, Joel M. Halpern wrote: >> >>> Yes, I got the map resolver and map server backwards. But that does >>> not change the question. >>> >>> Fundamentally, for LISP control packets, I do not see why we need an >>> inner IP header. The Control packet format itself has enough >>> information about the source and target of the message. >>> >>> You suggest that there would be a problem if the RLoc is IPv6, but >>> the connectivity to the Map Resolver is IPv4. >>> Presumably, given that the ITR has IPv4 connectivity, there is also >>> an IPv4 RLoc. >>> Whether the EID is v4 or v6 is irrelevant, as that is in the control >>> packet. >>> Even strange mixings of v4 Mapping and v6 RLocs seem possible even >>> without the outer header. The RLoc that the sending ITR uses in the >>> control part of the message does not ahve to match the RLoc it uses >>> as the UDP source address. >>> >>> You seem to be assuming that in the Map Request the target EID has to >>> go in the inner destination IP address field. Given that the address >>> is in the control message, I do not see why that is the case. >>> It may be the case that within the ALT we want to send the packets >>> that way. But we are not discussing the encapsulation between ALT >>> elements. We are discussing the ITR->MR and MS->ETR encapsulation. >>> It seems that those boxes at the edge of the ALT can deal with >>> building headers that are suitable for traversing the ALT. >>> >>> Just to complete the story, for the last leg from the MS to the ETR, >>> I do not see why the RLoc of the ITR needs to appear in the IP (inner >>> or outer) header. It appears in the control message itself. The ETR >>> can get the information from there for composing the direct response. >> >> >> I'm suffering from the same confusion as Joel... >> >> I don't see any value to encapsulating the ITR-to-MR and MS-to-ETR >> control plane packets, and I see considerable cost to doing so because >> it adds complexity and processing overhead to what should be a > > This is an originated control packet, so the control plane puts the > encapsulated header on. So it is very simple. The data-plane need not be > involved. > > If you choose any other method you can't support all the combinations we > tend to support. That is mixed address-families, xTRs attached to the > ALT, LISP-naive ALT routers, and there are more. > >> simple forwarding function in the LISP data plane. I understand that >> the ALT is special, but at the edges let's send the control packets >> directly to their intended recipients on the LISP control port, >> instead of encapsulating them. > > You can't do that because the packet will be dropped by the PE router > because there is no route in the underlying routing for the EID. > > Dino > > > From dino@cisco.com Tue Sep 8 15:15: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 EACF53A68A5 for ; Tue, 8 Sep 2009 15:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=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 ZEMSTSy4l-2U for ; Tue, 8 Sep 2009 15:15: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 649CB3A685A for ; Tue, 8 Sep 2009 15:15:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAER0pkqrR7MV/2dsb2JhbADFSYhDAZAIBYQYgVk X-IronPort-AV: E=Sophos;i="4.44,354,1249257600"; d="scan'208";a="238950826" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2009 22:16:28 +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 n88MGSrG004183; Tue, 8 Sep 2009 15:16: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 n88MGSSL027880; Tue, 8 Sep 2009 22:16:28 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, 8 Sep 2009 15:16:28 -0700 Received: from [192.168.5.7] ([10.21.83.229]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 15:16:27 -0700 Message-Id: <935DE4ED-6925-4800-9B14-8C35138CA625@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AA6D459.4080105@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, 8 Sep 2009 15:16:26 -0700 References: <060.ea8474f8e9e720ff4a5501041a5c944c@tools.ietf.org> <4AA66AC4.5010108@joelhalpern.com> <14869896-3B75-4DDF-B075-FF507FCEEB5B@cisco.com> <4AA68D0B.9040106@joelhalpern.com> <15F5C9BC-F07F-4B03-A443-54D044BFAA66@cisco.com> <4AA6D459.4080105@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Sep 2009 22:16:27.0776 (UTC) FILETIME=[02905800:01CA30D2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7738; t=1252448188; x=1253312188; 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#22=3A=20An=20ETR=20MUST=20con sume=20UDP=20port=204342=20packets=20not=20addressed=20to=20 it |Sender:=20; bh=u0fhpJBmhPZirPYRzPL/C8PnxiZNSQ2wZ3hh3TYcQBc=; b=FwfRzUNEJ8jaYwwo0u2z24NjZjQ1ZciF7aHsOitMx46PcHZuTreJItHOYw hobZGhGBOaSJPKwboLZHyENe+8FYCE3+3fPV2PXIeMSargC+yvKxdWo5Ky9f PpHmzGp04SBdGvsSnTCCiJAJyOWHDoF66dLAQAljW3qNSaCMLJMz0=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] #22: An ETR MUST consume UDP port 4342 packets not addressed to it X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 22:15:59 -0000 > As far as I can tell, all of the different address combinations can > be handled without the double-header on the leaf->Map Service > connection. The necessary data is in the Map Request. And this does > not have to match the enclosing IP header as to IP version. (It > does have to match the kind of EID the ALT is prepared to handle, > but that is true anyway.) It is also about debuggability. You want to know who builds a packet, and who is forwarding or encapsulating. The level of indirection allows the map-resolver to reencapsulate perhaps and provides opportunities to do caching in other parts of the infrastructure. We don't know right now if that is a good idea but the level of indirection helps us. We don't want the map-resolver to look into the contents of the ITR built packet. It could be encrypted in the future. The Map-Resolvers and Map-Servers act as a service interface for sites. So they are really simple by decap'ing and forwarding packets on the ALT. The ITR and ETR functionality is really simple too. They just build Map-Requests for the address-family the EID is being sought for and if there is a bottom layer that decides if the packet is sent directly on an ALT, or a DHT, or to a map-resolver, this is done independent of the LISP core protocol functionality. Encapsulating at the ITR to get a Map-Request to a Map-Resolver is trivial. Just slap a header on the packet and put the configured map- resolver as the destination address in the outer header. And pick a local RLOC for the source address. That is all there is to it. > What can not be handled is transparently removing the ITR - Map > Service connection. But I do not That is exactly what the MR/MS architecture is doing. > understand the issue. Given how simple the Map Responder (and Map > Server?) logic are, it would seem natural to include that in any > LISP-ALT leaf device (probably in any LISP-ALT device, for simplicity. > > Given that ALT devices talk to each other over GRE, if we want the > ITR to send the query into the ALT That is the way it is spec'ed out but it doesn't have to be GRE. It can be dark fiber, it can be 802.1Q, it can be L2TP, pseudo-wires. But what is important is that the object being sought for is in the destination field of the IP header. That allows ALT to be taken out and DHT put in and the key is still in the destination address of the IP header. You don't want these devices to have to parse the LISP payload. In fact, if you use data-probes on the mapping database, there is no where else to put the EID but in the destination address field. And there are some of the mind, that dropping or queuing packets is not good and sending data-probes to solicit Map-Replies is a way to go. > system, it presumably has to do so over a GRE tunnel. So the ITR > logic is now different anyway. So it can change the encapsulation. > (If the ITR does not have to use GRE, then the LISP-ALT device is > supporting two formats, and it might as well support the format that > simplifies the client.) No, not really two formats. The inner Map-Request uses the same code to build the packet. You just do something more afterwards. I can show you the code Joel. ;-) It's not different, it's in addition to. It makes a big difference. > I suspect one of the keys to the difference is that I do not expect > that the device which receives requests from clients can simply > forward those based on the EID in the IP header. I expect > validation is needed, cache checking, etc. And given taht we are > dealing with LISP, the need for such a device to add an extra header > seems irrrelevant to me. Well how much validation does a DNS server to when a query comes in. Even if you wanted to force policy here, just think of the OpEx hit to manage this. > I am also confused because it seems that your unstated goal is for > the Map Responder (and Map Server) protocol to be the same as the > protocol that you are trying to isolate the ITR/ETR from. I thought > the goal was to keep the ITR / ETR simpler. It is simpler for the user. There is no BGP configuration on the xTRs. Simpler for the protocol developer is secondary to the user. But I believe it's not bad for the developer. > Admittedly, simplicity is in the eye of the beholder. And there is > always the question of where the necessary complexity belongs. Simplicity must be in the eye of the poor network administrator that has to configure, manage, and monitor the routing system. Dino > > Yours, > Joel > > Dino Farinacci wrote: >>> On Sep 8, 2009, at 12:57 PM, Joel M. Halpern wrote: >>> >>>> Yes, I got the map resolver and map server backwards. But that >>>> does not change the question. >>>> >>>> Fundamentally, for LISP control packets, I do not see why we need >>>> an inner IP header. The Control packet format itself has enough >>>> information about the source and target of the message. >>>> >>>> You suggest that there would be a problem if the RLoc is IPv6, >>>> but the connectivity to the Map Resolver is IPv4. >>>> Presumably, given that the ITR has IPv4 connectivity, there is >>>> also an IPv4 RLoc. >>>> Whether the EID is v4 or v6 is irrelevant, as that is in the >>>> control packet. >>>> Even strange mixings of v4 Mapping and v6 RLocs seem possible >>>> even without the outer header. The RLoc that the sending ITR >>>> uses in the control part of the message does not ahve to match >>>> the RLoc it uses as the UDP source address. >>>> >>>> You seem to be assuming that in the Map Request the target EID >>>> has to go in the inner destination IP address field. Given that >>>> the address is in the control message, I do not see why that is >>>> the case. >>>> It may be the case that within the ALT we want to send the >>>> packets that way. But we are not discussing the encapsulation >>>> between ALT elements. We are discussing the ITR->MR and MS->ETR >>>> encapsulation. It seems that those boxes at the edge of the ALT >>>> can deal with building headers that are suitable for traversing >>>> the ALT. >>>> >>>> Just to complete the story, for the last leg from the MS to the >>>> ETR, I do not see why the RLoc of the ITR needs to appear in the >>>> IP (inner or outer) header. It appears in the control message >>>> itself. The ETR can get the information from there for composing >>>> the direct response. >>> >>> >>> I'm suffering from the same confusion as Joel... >>> >>> I don't see any value to encapsulating the ITR-to-MR and MS-to-ETR >>> control plane packets, and I see considerable cost to doing so >>> because it adds complexity and processing overhead to what should >>> be a >> This is an originated control packet, so the control plane puts the >> encapsulated header on. So it is very simple. The data-plane need >> not be involved. >> If you choose any other method you can't support all the >> combinations we tend to support. That is mixed address-families, >> xTRs attached to the ALT, LISP-naive ALT routers, and there are more. >>> simple forwarding function in the LISP data plane. I understand >>> that the ALT is special, but at the edges let's send the control >>> packets directly to their intended recipients on the LISP control >>> port, instead of encapsulating them. >> You can't do that because the packet will be dropped by the PE >> router because there is no route in the underlying routing for the >> EID. >> Dino From jari.arkko@piuha.net Tue Sep 8 15:25: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 B16DC3A63EB for ; Tue, 8 Sep 2009 15:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdqMGfOPKzca for ; Tue, 8 Sep 2009 15:25:27 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 711503A68BF for ; Tue, 8 Sep 2009 15:25:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 18315D620E for ; Wed, 9 Sep 2009 01:25:58 +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 PJOQTw+lyomB for ; Wed, 9 Sep 2009 01:25:57 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 4BE10D620D for ; Wed, 9 Sep 2009 01:25:57 +0300 (EEST) Message-ID: <4AA6D9F4.1020006@piuha.net> Date: Wed, 09 Sep 2009 01:25:56 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Lisp WG concerns X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 08 Sep 2009 22:25:28 -0000 A couple of weeks ago, several people complained to me that the discussions in the Lisp WG were unhealthy in various ways: not enough progress was made, too much weight was put on one or the other side of an issue, the other side was being unreasonable, various people were misbehaving, and so on. I have finally completed my review of everything that has been going on in list and talked to various people. Apologies for taking so long, but I had a lot of backlog. In any case, in my opinion I saw no serious misbehavior or other grave problems. The positive spin of the WG's state is that you have a very active discussion, many implementors from different teams, and momentum to move forward. That being said, there are also problems: Human issues: Some of the discussion has a confrontational tone, often needlessly. Not everyone is taking time to explain how they arrived to their conclusion. There is no "we" feeling in the group making decisions. Discussions move to form (format and split of issues) or process from the substance. Its hard to gauge consensus when the participants belong to just few interest groups (even if there are many key participants). Legitimate conflicts: Some of the interested groups and implementation teams are thinking about very different deployment situations and implementation strategies, which creates conflicts about whose priorities are honored first. Existing RFCs cause pain for tunnel implementations and relaxing the requirements might cause other types of pain. (And revising those RFCs seems to generate some unnecessary fear for what should be our daily business.) Technical issues: While much of the basics are pretty clear, there are also areas that probably need a lot more work, like security. Darrell and Sam are already tackling much of this. I will just bring up a couple of high level points that I hope everyone in the group understands. We are here to work on an *IETF version of Lisp*, and we do that because we believe that the joint expertise from everyone in the group will create a better result than if someone just did the protocol on their own. But that necessarily implies the need to take the other people's opinions in account. The Lisp RFCs *will* be different from the initial drafts. There can be no single man's IETF Lisp. This is the set of people you have, and all of you are seriously interested in Lisp. You *have to find a compromise* that all parties can live with to publish a spec. I believe the end result will actually be better that way. I would also like to plea for the following: 1) Be respectful in the discussions 2) Decisions are made based on justifications that are brought up on the list. Be aware that many of the original design decisions are probably questioned in this process, and that's as it should be. You may have to live with a decision or two that you believe is wrong. 3) Try to keep the discussion on the substance. If the form is wrong, its not necessarily because the other guy is evil. 4) Lisp is not the only component of the Internet, and I expect Lisp to play by the rules of the rest of the system. Sometimes there's a bug in the rest of the system, but it is possible -- and often easy -- to fix those. That is why we are doing the work in 6MAN. And sometimes something in Lisp will be harder because the rest of the system cannot accommodate the best possible solution for you. Live with it. Jari From dino@cisco.com Tue Sep 8 17:18: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 42A1E3A68A1 for ; Tue, 8 Sep 2009 17:18:52 -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 QpB-ugddS8rn for ; Tue, 8 Sep 2009 17:18: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 704683A6A34 for ; Tue, 8 Sep 2009 17:18:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI+RpkqrR7MV/2dsb2JhbADFO4hDAZAWBYQY X-IronPort-AV: E=Sophos;i="4.44,355,1249257600"; d="scan'208";a="239009484" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Sep 2009 00:19:09 +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 n890J9EL017718; Tue, 8 Sep 2009 17:19:09 -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 n890J9eW000927; Wed, 9 Sep 2009 00:19:09 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, 8 Sep 2009 17:19:09 -0700 Received: from [192.168.5.7] ([10.21.83.229]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 17:19:06 -0700 Message-Id: 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 v936) Date: Tue, 8 Sep 2009 17:19:05 -0700 References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> <066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org> <5F97F934-5508-46C7-8778-1978E4BD04CF@lilacglade.org> <6CC7FE39-8B40-4473-8A05-99C12DC7A05F@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Sep 2009 00:19:07.0625 (UTC) FILETIME=[25602D90:01CA30E3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7392; t=1252455549; x=1253319549; 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#8=3A=20Limits=20on=20=22Glean ed=22=20Map=20Entries=20Not=20Clear |Sender:=20; bh=FhsyCgwtFdmxbbsUYuQkgHvlrNMApuxWln9p9VD11yU=; b=lz03qluolgGnRikJgnC79yihWM/R0VL6zcBK1e86S5ra/b5vsze/AWp8J3 JbU1RAK9xh1JefZpg8QIhZjGLwfUA3TnEAyJykilTapE/LiizPM8FrB9WJ/j G+vkmC6aXZ7PZ28hODhoWuJmcmudQa22R7WJ5eChdRpFGF6XQscyI=; 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] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 00:18:52 -0000 > On Sep 7, 2009, at 10:14 PM, Dino Farinacci wrote: > >>> On Sep 7, 2009, at 7:18 PM, lisp issue tracker wrote: >>> >>>> In Dino's proposed 04 text the following is added: >>>> >>>> o A "gleaned" map-cache entry, one learned from the source RLOC >>>> of a >>>> received encapsulated packet, is only stored and used for a few >>>> seconds, pending verification. Verification is performed by >>>> sending a Map-Request to the source EID (the inner header IP >>>> source address) of the received encapsulated packet. A reply to >>>> this "verifying Map-Request" is used to fully populate the map- >>>> cache entry for the "gleaned" EID and is stored and used for the >>>> time indicated from the TTL field of a received Map-Reply. >>>> >>>> We're still waiting to hear back from the WG and Margaret on this >>>> text. >>> >>> While this text is better than what was in the -03 draft, it isn't >>> good enough, IMO. >>> >>> On the list, we discussed an additional requirement that gleaned >>> mappings will never overwrite mappings that were received in map >>> replies. >> >> Right, and the text above does not imply that. The verifying Map- >> Request is responded by a Map-Reply. It is the contents of the Map- >> Reply that is stored in the map-cache. > > I think we should explicitly state that a "gleaned" map-cache entry > will not be created if a map entry already exists for an EID prefix > containing the EID in the received packet, even if the map-cache > entry indicates that packets to that EID should be sent to a > different ETR. I will add that and send text in another email. >>> Also, I am concerned about the implications of this behavior in >>> the case of intentional spoofing. If the attacker sends a message >>> to create the gleaned mapping, he will also know that the host >>> will soon send a >> >> You need to be clear about the case. Is the attacker spoofing the >> address of a real locator or is the attack spoofing the mapping data? > > The attacker is trying to get an ITR to use a bogus map cache entry, > so that data will be sent to the attacker's ETR (and processed by > the attacker's end-system) instead of to the actual ETR that serves > the EID. That cannot happen. I think you may be convince of that now? >> Yes, but the Map-Request will never be sent to the attacker when it >> is sent into the mapping database system. > > True. > >>> In that case, he _could_ send a large-enough number of map replies >>> for that EID, all with difference nonce values, perhaps covering a >>> non-trivial percentage of the 24-bit nonce space. >> >> Who is he? The attacker? Nope, that won't happen, the attacker >> won't get the Map-Requests so it can't Map-Reply. And if it chooses >> to Map-Reply on its own, the ITR won't accept unsolicited Map- >> Replies. > > There is nothing tying a map reply to the original map request > except for the nonce. So, if an attacker can reliably cause an ITR > to send a map request for a particular EID, he can then send map > replies for that EID, even though he didn't see the request. If he > sends a bunch (potentially thousands) of map replies over the next > several seconds, perhaps one of them will match the nonce of the > request that the ITR actually sent. In that case the mapping > information from the reply may be added to the cache instead of the > mapping entry from the ETR that genuinely serves the indicated EID. > This is a percentages game... While it might only work 1 in a > ~10,000 times, there isn't any reason why the attacker couldn't try > it 10,000 times, using different EIDs and/or targeting different > ITRs until it works. The spoofed entries could contain a long TTL > and a short prefix, so that the attacker could cause an ITR to use > his ETR for a large number of EIDs for a long time. If the LISP > ITR were run by an ISP, for example, this could cause all of the > ISPs customers to connect to the attacker instead of to the real > site(s) that are associated with those EIDs. No this isn't true. What ties the real ETRs and no one else to the EID in a Map-Request is the authenticated registration to the map-server. All the attacker can do is send packets to the xTR which it drops. At the same rate, the xTR would get packets to decapsulated. All limited to the rate of the PE/CE link. > There are a couple ways to deal with this attack that I can think of: > > (1) Make the nonce in the map request/reply larger (64-bits or > more?), so that there is a much smaller chance that an attacker can > hit upon a matching nonce. This could probabilistically limit the > case where The L2TP guys have said that 32-bit cookies work pretty well. > attackers could create a bogus map cache entry using this mechanism > to on-path attackers. I don't have the security analysis skills to > know how long the nonce needs to be to make it large enough to > thwart an off-path attacker, but we could probably get someone from > the security area to help us figure > that out. > > (2) Require that the reply be sent from the map resolver to whom the > request was sent, perhaps with additional authentication to indicate > that it was actually sent from that map resolver. This would make > it necessary for an attacker to gain control of a map resolver and/ > or to reconfigure the ITR in order to inject bogus map cache entries. We don't need to do this. But to be honest I don't understand what you are proposing. But it sounds like a lot of machinery. > There are probably other ways to thwart this type of attack, so we > might want to talk to security folks to see if there are other > options. > > >>> What is an ITR supposed to do if it receives two different >>> responses to the map request for the gleaned address? >> >> What do you mean by different. In our implementation, if one is >> received with the wrong nonce, then the Map-Reply is rejected and a >> spoof-alert log message is issued. If the later comes in with the >> right nonce, it is accepted. > > What happens if you get two different replies that both have the > right nonce? Will you accept the first The second mapping data overrides the first. > and then accept the second, overwriting the information received in > the first? Or will you accept the first, throw away the state > related to that nonce, and reject the second because it doesn't > match any open nonce? Either way, if an attacker can send a reply > with a matching nonce (regardless of how many replies he sends that > don't match), you will end-up using his mapping about 50% of the > time, instead of the mapping > from the real ETR that serves that EID prefix. We will accept both which are secure and from the authoritative source. The same nonce would only happen if the ITR sent 2 Map-Requests with the same nonce and a different ETR at each site received it and replies. Which is a valid scenario. And the attacker could only exist if it was man in the middle. But it would have to be in the middle of both the ALT and the Map-Reply return path. Which usually is an on-path device and rare. Dino > > Margaret From dino@cisco.com Tue Sep 8 17: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 419273A6B33 for ; Tue, 8 Sep 2009 17:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 9+Knk7SBeUW8 for ; Tue, 8 Sep 2009 17:26:09 -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 8720F3A6B2C for ; Tue, 8 Sep 2009 17:26:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHCTpkqrR7PE/2dsb2JhbADFMohDAZAcBYQY X-IronPort-AV: E=Sophos;i="4.44,355,1249257600"; d="scan'208";a="93662836" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 09 Sep 2009 00:26: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 n890QeWb023882; Tue, 8 Sep 2009 17:26:40 -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 n890Qe6w003982; Wed, 9 Sep 2009 00:26:40 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, 8 Sep 2009 17:26:40 -0700 Received: from [192.168.5.7] ([10.21.83.229]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 17:26:40 -0700 Message-Id: From: Dino Farinacci To: Margaret Wasserman 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, 8 Sep 2009 17:26:38 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Sep 2009 00:26:40.0693 (UTC) FILETIME=[336CDE50:01CA30E4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=923; t=1252456001; x=1253320001; 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:=20Updated=20text=20to=20data=20gleaning |Sender:=20; bh=UTPEi4N6mmP2jvA1Myjg8cixVIulmhHZg+x9IQ2kxbg=; b=ik1xHxSvd+rHYzc9ytegkNQEQvblvSd8HPHZFmJM1e4orD0nS34d84ZIkk K/mgcDi50AeGu8MV5XIPn9W5AZxjkLCAmBq43N2wZGYD6JRnyBHopgOasSR8 dMXFSl5uPF; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: [lisp] Updated text to data gleaning X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 00:26:10 -0000 Here is the new text (the last sentence was added) to reflect Margaret's comment: o A "gleaned" map-cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. Let me know if this reflects the comment made. Thanks. Dino From dino@cisco.com Tue Sep 8 17: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 E9B8D3A68D0 for ; Tue, 8 Sep 2009 17:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9OVMXgtVzkD for ; Tue, 8 Sep 2009 17:29:54 -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 702EE3A68A1 for ; Tue, 8 Sep 2009 17:29:54 -0700 (PDT) X-Files: rfcdiff-lisp-03-to-04.html, draft-ietf-lisp-04.txt : 164640, 149591 X-IronPort-AV: E=Sophos;i="4.44,355,1249257600"; d="txt'?html'217?scan'217,208,217";a="202774124" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 09 Sep 2009 00:30:25 +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 n890UPf3015220 for ; Tue, 8 Sep 2009 17:30:25 -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 n890UP4k009993 for ; Wed, 9 Sep 2009 00:30:25 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, 8 Sep 2009 17:30:25 -0700 Received: from [192.168.5.7] ([10.21.83.229]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 17:30:22 -0700 Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-3--728883991 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Sep 2009 17:30:22 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Sep 2009 00:30:23.0032 (UTC) FILETIME=[B7F31B80:01CA30E4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=321944; t=1252456225; x=1253320225; 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:=20Tuesday=20updated=20diff=20file=20for=20the=20l isp-04=20proposed=20changes |Sender:=20; bh=60LJga38ZSriaETHXEqyaWL58EIwk5hv8+TiPilJKp8=; b=Vvf1DO3+jJSbfwCzgSiQ5VLWzxEn3906qR96VYUys405h04kkcbOvVlxYN jGqQswTA2cVXHCCeOdeM4R1ZenuV6ldayXh73/41LUCLRW6AoGf3drj+FvA8 B3Rb9BH649; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [lisp] Tuesday updated diff file for the lisp-04 proposed changes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 00:29:55 -0000 --Apple-Mail-3--728883991 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Enclosed. I will send daily diffs up until Friday noon PDT (if there are any changes). Then I will submit at that time if there is no objection. Thanks, Dino/Dave/Darrel/Vince --Apple-Mail-3--728883991 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 12, 2010                                         D. Lewis
                                                           cisco Systems
                                                           July 27,
                                                       September 8, 2009

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

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 12, 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 35
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 36
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 38 39
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 40
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 39 41
     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 43
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 43 45
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 44 46
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 45 47
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 45 47
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 46 48
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 47 49
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 50
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 50
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 48 50
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 50 52
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 50 52
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 52
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 52
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 52 54
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 52 54
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 54 56
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 55 57
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 56 58
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 61
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 59 61
     14.2. Informative References . . . . . . . . . . . . . . . . . . 60 62
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 63 65
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 66

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 statically 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 prepends 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
      statically 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 prepends 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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

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

   OH

   Outer 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 the ETR. packet for decapsulation.
      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 decapsulation, otherwise, it is silently dropped.
      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

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

   LISP Locator Reach Bits:  in the LISP header are nonce-present bit.  When this bit is set by an ITR to
      indicate to an ETR 1, the reachability
      low-order 24-bits of the Locators in first 32-bits of the source
      site.  Each RLOC in LISP header contains
      a Map-Reply Nonce.  See section Section 6.3.1 for details.

   L: this is assigned an ordinal value from
      0 the Locator-Status-Bits field enabled bit.  When this bit
      is set to n-1 (when there 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are n RLOCs in a mapping use.

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1.  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.

   rflags:  this 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
      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.  When the E-bit is clear but the N-bit
      is set, an ITR is either echoing a previously requested echo-nonce
      or providing a random nonce.  See section Section 6.3.1 for more
      details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator
      Reach Status Bits are numbered from 0 to n-1 from the right least
      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 is
      reachable. 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 Reach Status Bits
      setting in an encapsulated packet MUST reflect the mapping for the
      EID-prefix that the inner-header source EID address matches.

   S: this is the Solicit-Map-Request (SMR) bit.  See section
      Section 6.5.2 for details.

   E: this is the echo-nonce-request bit.  See section Section 6.3.1 for
      details.

   rsvd-flags:  this 6-bit

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The outer header Time to Live 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.
      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 is set to solicit the other side to send a Map-
      Request containing this nonce.  See section Section 6.5.2 for
      details.

   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 (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

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

   When doing Re-encapsulated Tunneling:

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

   o  The new OH outer header Type of Service field SHOULD be copied from
      the stripped OH header Type of Service field (with one caveat, see
      below)..
      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 Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record count. Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

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

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request, it may
   originate a "verifying Map-Request", addressed to the original ITR.
   If the ETR has a map-cache entry that matches the "piggybacked" EID
   and the RLOC is in the locator-set for the entry, then it may send
   the "verifying Map-Request" to the original Map-Request source.  If
   not, then it MUST send it to the "piggybacked" EID.  Doing this
   forces the "verifying Map-Request" to go through the mapping database
   system to reach the authoritative source of information about that
   EID, guarding against RLOC-spoofing in in the "piggybacked" 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|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
      advertising that the site 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.

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

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

   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: this bit is reserved for use by the LISP mobile-node design
      documented in [LISP-MN].

   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.

   o  A "gleaned" map-cache entry, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply and or that stored in the database
   mapping service does not database system provide any reachability status information for Locators.  This is done outside RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the mapping service.  See Routing Locator Reachability Algorithms described in the
   next section for details. section.

6.3.  Routing Locator Reachability

   There are 4 methods

   Several mechanisms for determining when a Locator is either
   reachable or has become unreachable:

   1.  Locator RLOC reachability is determined by an are currently
   defined:

   1.  An ETR by examining may examine the Loc-Status-Bits in the
       Loc-Reach-Bits from a LISP header of a an
       encapsulated data packet
       which received from an ITR.  If the ETR is provided by
       also acting as an ITR when an and has traffic to return to the original
       ITR encapsulates data.

   2.  Locator unreachability is determined by site, it can use this status information to help select an
       RLOC.

   2.  An ITR by receiving may receive an ICMP Network or ICMP Host Unreachable messages.
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  Locator unreachability  An ITR which participates in the global routing system can also be determined by
       determine that an BGP-enabled
       ITR when there RLOC is down if no prefix matching a Locator address from the BGP RIB. RIB route exists that
       matches the RLOC IP address.

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

   5.  Locator reachability is determined by receiving  An ITR may receive a Map-Reply
       message from a ETR's Locator address ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  Locator reachability can also be determined by receiving packets  When an ETR receives an encapsulated by packet from an ITR, the ITR assigned to
       source RLOC from the locator address. outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   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 an encapsulating ITR closest to the Locators about
   reachability for all ETRs at the source site.  The  CE-based ITRs at the source
   site can determine reachability when running their
   IGP at the site.  When relative to each other using the ITRs are deployed on CE routers, typically site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route is injected into the site's IGP from each of the
   ITRs. site IGP.

   o  If an ITR goes down, the CE-PE link goes down, fails or if the upstream link to its PE
   router goes down, the CE router withdraws the fails, its
      default route.  This
   allows route will either time-out or be withdrawn.

   Each ITR can thus observe the other ITRs at presence or lack of a default route
   originated by the site others to determine one of the Locators
   has gone unreachable.

   The Locators Locator Status Bits it sets
   for them.

   RLOCs 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 encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit numbered as 0.  So,
   for bit.  For example, if the ITR with locator an RLOC
   listed as in the 3rd Locator position in of the Map-Reply goes down, down (ordinal value
   2), then all other ITRs at the site will
   have clear the 3rd least significant
   bit from (xxxx x0xx) of the right cleared (the bit that corresponds to
   ordinal 2). Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will look check for a any change in
   the
   Loc-Reach-Bits value. Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to the Locator an RLOC that has just gone
   unreachable. is indicated as
   down.  It can start will only resume using the Locator again when the bit that
   corresponds to RLOC if the Locator goes from 0 corresponding Loc-
   Status-Bit returns to a value of 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 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 ITR 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 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.

   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 more secure to reach an authoritative ETR,
   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 have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   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,  Two are the Echo-Noncing and
        RLOC-Probing algorithms which is are documented in this
        specification.  The other two are third is 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.

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

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.

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, Sam Hartman, Michael Hofling, and Pedro Marques.

   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-3--728883991 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-3--728883991 Content-Disposition: attachment; filename=draft-ietf-lisp-04.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-04.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: March 12, 2010 D. Lewis cisco Systems September 8, 2009 Locator/ID Separation Protocol (LISP) (PROPOSED) draft-ietf-lisp-04.txt (NOT SUBMITTED) 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 March 12, 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. Farinacci, et al. Expires March 12, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 . . . . . . . . . . . . . . . . 35 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 36 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 39 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 40 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 41 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 41 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 42 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 43 7. Router Performance Considerations . . . . . . . . . . . . . . 45 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 46 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 47 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 47 Farinacci, et al. Expires March 12, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 48 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 49 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 50 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 50 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 50 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 52 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 52 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 52 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 52 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 54 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 54 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 56 12. Security Considerations . . . . . . . . . . . . . . . . . . . 57 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 58 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 14.1. Normative References . . . . . . . . . . . . . . . . . . . 61 14.2. Informative References . . . . . . . . . . . . . . . . . . 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 Farinacci, et al. Expires March 12, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 12, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 12, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 12, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 12, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 statically 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 prepends 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 statically configured. Farinacci, et al. Expires March 12, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 prepends 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 Farinacci, et al. Expires March 12, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 12, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | | Farinacci, et al. Expires March 12, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer 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 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 MAY be transmitted as zero by an ITR and when received by an ETR, MUST accept the packet for decapsulation. 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 decapsulation, 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. 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. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See section Section 6.3.1 for details. Farinacci, et al. Expires March 12, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. E: this is the echo-nonce-request bit. When this bit is set to 1, the N bit must be 1. 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. rflags: this 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 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. When the E-bit is clear but the N-bit is set, an ITR is either echoing a previously requested echo-nonce or providing a random nonce. See section Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least 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 outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Type of Service field (with one caveat, see below). When doing Re-encapsulated Tunneling: Farinacci, et al. Expires March 12, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer 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: Farinacci, et al. Expires March 12, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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 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 Farinacci, et al. Expires March 12, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires March 12, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 | | + 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. Farinacci, et al. Expires March 12, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D1 |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: Farinacci, et al. Expires March 12, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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 Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. 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 Farinacci, et al. Expires March 12, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request, it may originate a "verifying Map-Request", addressed to the original ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map-Request" to the original Map-Request source. If Farinacci, et al. Expires March 12, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 not, then it MUST send it to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" 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=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | 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. See section Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is advertising that the site is enabled for the Echo-Nonce locator reachability algorithm. See Section 6.3.1 for more details. Farinacci, et al. Expires March 12, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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: this bit is reserved for use by the LISP mobile-node design documented in [LISP-MN]. Farinacci, et al. Expires March 12, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 [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 [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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 12, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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=3D3 |P| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | 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. Farinacci, et al. Expires March 12, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 12, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a Farinacci, et al. Expires March 12, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the 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. Farinacci, et al. Expires March 12, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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-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 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 Farinacci, et al. Expires March 12, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 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 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. 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 Farinacci, et al. Expires March 12, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 obtain those benefits, especially if the 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. Farinacci, et al. Expires March 12, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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- Farinacci, et al. Expires March 12, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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-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-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-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. Farinacci, et al. Expires March 12, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the 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 ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- prefix uses is the one copied from the SMR message. 3. The remote xTR retransmits the Map-Request slowly until it gets a Map-Reply while continuing to use the cached mapping. Farinacci, et al. Expires March 12, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending 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 more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. Farinacci, et al. Expires March 12, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 12, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, Farinacci, et al. Expires March 12, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 12, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 12, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 12, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 12, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Interoperable implementations have been available since the beginning of 2009. We are trying to converge on a packet format so implementations can converge on the -04 and later drafts. 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. Farinacci, et al. Expires March 12, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 12, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts 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. Farinacci, et al. Expires March 12, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. [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, Farinacci, et al. Expires March 12, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 September 2007. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 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. Farinacci, et al. Expires March 12, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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-02.txt (work in progress), 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. Farinacci, et al. Expires March 12, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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. Farinacci, et al. Expires March 12, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, and Pedro Marques. 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. Farinacci, et al. Expires March 12, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 12, 2010 [Page 66] =0C --Apple-Mail-3--728883991 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-3--728883991-- From mrw@lilacglade.org Tue Sep 8 19:08: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 AEAF928C1E5 for ; Tue, 8 Sep 2009 19:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 xu+L50FOKBDH for ; Tue, 8 Sep 2009 19:08:02 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 4B6633A68C7 for ; Tue, 8 Sep 2009 19:08:02 -0700 (PDT) Received: from OMTA22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id eS8Z1c00B1vN32cA8S8aUo; Wed, 09 Sep 2009 02:08:34 +0000 Received: from [10.36.0.42] ([173.48.144.147]) by OMTA22.emeryville.ca.mail.comcast.net with comcast id eSCK1c0083B1aZH8iSCbt1; Wed, 09 Sep 2009 02:12:50 +0000 Message-Id: <49CD8D62-3039-43FD-9622-FAC8FAA800A2@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: Tue, 8 Sep 2009 22:07:24 -0400 References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> <066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org> <5F97F934-5508-46C7-8778-1978E4BD04CF@lilacglade.org> <6CC7FE39-8B40-4473-8A05-99C12DC7A05F@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 02:08:03 -0000 On Sep 8, 2009, at 8:19 PM, Dino Farinacci wrote: >>> You need to be clear about the case. Is the attacker spoofing the >>> address of a real locator or is the attack spoofing the mapping >>> data? >> >> The attacker is trying to get an ITR to use a bogus map cache >> entry, so that data will be sent to the attacker's ETR (and >> processed by the attacker's end-system) instead of to the actual >> ETR that serves the EID. > > That cannot happen. I think you may be convince of that now? No, I don't see what would stop this from happening... There are two steps here: (1) The attacker manages to send a spoofed map reply that gets processed by the ITR. (2) The ITR sends encapsulated data packets to the ETR in the spoofed map reply, instead of to the correct ETR for the destination EID. The second step can certainly happen, if an attacker can cause the ITR to store a spoofed map-cache entry. We all seem to agree that this can happen "for a few seconds" if an attacker sends a packet that will generate an incorrect "gleaned" entry. The question is whether the attacker can parlay this into a longer- lived map cache entry by flooding the same ITR with map responses for the EID in the gleaned entry immediately after sending the packet that caused the gleaned entry in the first place. The attacker knows that the ITR will send a request for that entry, so she can play a numbers game and send replies with as many nonce values as possible, hoping to hit on the nonce that the ITR uses in its request. > > No this isn't true. What ties the real ETRs and no one else to the > EID in a Map-Request is the authenticated registration to the map- > server. The ITR that sends the map request can't see the authenticated registration in the map server. I am not saying that an attacker could get a spoofed entry into the mapping system. We don't actually require map responses to come from the mapping system; they come directly from ETRs, at least some cases, and they don't contain any information that can be used to authenticate the data. So, there is no reason that an attacker couldn't generate responses that, if they happen to hit the right nonce value, would look just as authentic to the requesting ITR as responses from the real ETR. > > All the attacker can do is send packets to the xTR which it drops. > At the same rate, the xTR would get packets to decapsulated. All > limited to the rate of the PE/CE link. It will drop them unless the nonce matches. > > >> There are a couple ways to deal with this attack that I can think of: >> >> (1) Make the nonce in the map request/reply larger (64-bits or >> more?), so that there is a much smaller chance that an attacker can >> hit upon a matching nonce. This could probabilistically limit the >> case where > > The L2TP guys have said that 32-bit cookies work pretty well. What do they use the 32-bit cookies to protect? It is possible that a 32-bit nonce is sufficient to protect the map request/reply system, but given the level of danger if we are wrong, I think it would be wiser to move to a 64-bit nonce. These are in control packets only, so moving to a longer nonce shouldn't effect forwarding performance or anything. I agree that if we end-up moving to authenticating the individual mapping entries we won't need a 64-bit nonce, but isn't clear that we need a 32-bit nonce in that case, either. > >> attackers could create a bogus map cache entry using this mechanism >> to on-path attackers. I don't have the security analysis skills to >> know how long the nonce needs to be to make it large enough to >> thwart an off-path attacker, but we could probably get someone from >> the security area to help us figure >> that out. >> >> (2) Require that the reply be sent from the map resolver to whom >> the request was sent, perhaps with additional authentication to >> indicate that it was actually sent from that map resolver. This >> would make it necessary for an attacker to gain control of a map >> resolver and/or to reconfigure the ITR in order to inject bogus map >> cache entries. > > We don't need to do this. But to be honest I don't understand what > you are proposing. But it sounds like a lot of machinery. A longer nonce wouldn't require any additional machiner. >> What happens if you get two different replies that both have the >> right nonce? Will you accept the first > > The second mapping data overrides the first. > >> and then accept the second, overwriting the information received in >> the first? Or will you accept the first, throw away the state >> related to that nonce, and reject the second because it doesn't >> match any open nonce? Either way, if an attacker can send a reply >> with a matching nonce (regardless of how many replies he sends that >> don't match), you will end-up using his mapping about 50% of the >> time, instead of the mapping >> from the real ETR that serves that EID prefix. > > We will accept both which are secure and from the authoritative > source. > > The same nonce would only happen if the ITR sent 2 Map-Requests with > the same nonce and a different ETR at each site received it and > replies. Which is a valid scenario. > > And the attacker could only exist if it was man in the middle. But > it would have to be in the middle of both the ALT and the Map-Reply > return path. Which usually is an on-path device and rare. The attack I am talking about is not an on-path attack. It is performed by an off-path attacker who makes some guesses about how a particular LISP implementation will perform. It becomes particularly dangerous if any of ship LISP implementations with (cryptographically) poor random number generators, which might allow an off-path attacker to optimize the specific nonce values that it will try in its spoofed responses. Margaret From jnc@mercury.lcs.mit.edu Tue Sep 8 20:59: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 D1F0A3A6910 for ; Tue, 8 Sep 2009 20:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 kyuhvUH1u6CP for ; Tue, 8 Sep 2009 20:59: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 C87E33A68FF for ; Tue, 8 Sep 2009 20:59:58 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 45A236BE60C; Wed, 9 Sep 2009 00:00:29 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> Date: Wed, 9 Sep 2009 00:00:29 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 03:59:59 -0000 > From: Margaret Wasserman >> That cannot happen. I think you may be convince of that now? > No, I don't see what would stop this from happening... > ... > (1) The attacker manages to send a spoofed map reply that gets > processed by the ITR. > ... > We all seem to agree that this can happen "for a few seconds" if an > attacker sends a packet that will generate an incorrect "gleaned" entry. My brain isn't working too crisply today, but on thinking about it a bit, I think I may have seen what Dino was getting at. It has to do with your point (1), and the "if an attacker [can] send a packet that will generate an incorrect 'gleaned' entry" - because that last may be harder than it seems. Start with a point you made a couple of messages back: >>> a "gleaned" map-cache entry will not be created if a map entry >>> already exists for an EID prefix containing the EID in the received >>> packet In other words, the gleaning attack can't even _start_ iff a cached map entry _already exists_. Put another way, it's only possible to attack mappings which aren't _already_ cached in the ITR. Any bogus packets, with a bad mapping, will be ignored if a valid cache entry for that EID already exists. So there are only two possible 'windows' in which one could do the two-step attack. (Step one, 'glean' a bad mapping; step two, validate the bad mapping by pre-empting the lookup by flooding the target with bogus replies. Actually, there might be circumstances in which one can go directly to the second step; see below.) The first potential 'window' is before a mapping to a particular destination exists; but for popular destinations, there's probably only a small time period when that is true, shortly after an ITR restarts. If an attacker can cause an ITR to crash and restart, then perhaps this attack would be mounted, but that does make the attack harder. For non-popular destinations, the attacker would have to know that a user was about to attempt communication with a given destination (because installing a bogus mapping for a destination that nobody at the attacked site was going to communicate with would be a waste of time), which again sounds like it might be fairly tricky. The second potential 'window' is just after a cached mapping times out. I don't recall exactly how timed-out map entries are handled, but if such entries become 'provisional', and a validate cycle is started, then the attacker could try the second step (only) of the two-step attack - but they would have to know when the entry times out, and I don't see how they could know that. None of which should be construed as an opinion one way or the other on whether it's worth making it harder to spoof Map-Replies - just trying to explain why the hole may be very hard to exploit, in practise. Noel From dino@cisco.com Tue Sep 8 21:52: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 4213628C0F6 for ; Tue, 8 Sep 2009 21:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 H1scu8ZvvD-K for ; Tue, 8 Sep 2009 21:52:06 -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 EA4623A68BB for ; Tue, 8 Sep 2009 21:52:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMbRpkqrR7O6/2dsb2JhbADFA4hDAZA2BYQY X-IronPort-AV: E=Sophos;i="4.44,356,1249257600"; d="scan'208";a="42582761" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 09 Sep 2009 04:52:38 +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 n894qcCS015743; Tue, 8 Sep 2009 21:52:38 -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 n894qc2i018921; Wed, 9 Sep 2009 04:52:38 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, 8 Sep 2009 21:52:38 -0700 Received: from [192.168.1.3] ([10.21.149.31]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 21:52:38 -0700 Message-Id: <88F5C0C6-B7FD-4D59-AE18-3B808B4B06B6@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <49CD8D62-3039-43FD-9622-FAC8FAA800A2@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: Tue, 8 Sep 2009 21:52:37 -0700 References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> <066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org> <5F97F934-5508-46C7-8778-1978E4BD04CF@lilacglade.org> <6CC7FE39-8B40-4473-8A05-99C12DC7A05F@cisco.com> <49CD8D62-3039-43FD-9622-FAC8FAA800A2@lilacglade.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Sep 2009 04:52:38.0569 (UTC) FILETIME=[5B0F8190:01CA3109] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7282; t=1252471958; x=1253335958; 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]=20#8=3A=20Limits=20on=20=22Glean ed=22=20Map=20Entries=20Not=20Clear |Sender:=20; bh=J5mVRqz1g+ajAYxZX0YaRtx7+0fLS/ZydKoslw78JyM=; b=YLJFy8hclE1ieX/bBSqk+AH36Iz9tllasbYhGvXFnGDkHTBEpgLkM+BRPw zvETa0vxcBsaSp0y4bQWI5AbVw5+2UOlMh1qrgtoKHp+67qViKEF+24K3zr8 XlElVQDksZ; 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] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 04:52:08 -0000 > On Sep 8, 2009, at 8:19 PM, Dino Farinacci wrote: >>>> You need to be clear about the case. Is the attacker spoofing the >>>> address of a real locator or is the attack spoofing the mapping >>>> data? >>> >>> The attacker is trying to get an ITR to use a bogus map cache >>> entry, so that data will be sent to the attacker's ETR (and >>> processed by the attacker's end-system) instead of to the actual >>> ETR that serves the EID. >> >> That cannot happen. I think you may be convince of that now? > > No, I don't see what would stop this from happening... > > There are two steps here: > > (1) The attacker manages to send a spoofed map reply that gets > processed by the ITR. And you say this will happen because the attacker guessed the 32-bit nonce, right? Because that is the only way it could happen. > (2) The ITR sends encapsulated data packets to the ETR in the > spoofed map reply, instead of to the correct ETR for the destination > EID. > > The second step can certainly happen, if an attacker can cause the > ITR to store a spoofed map-cache entry. > > We all seem to agree that this can happen "for a few seconds" if an > attacker sends a packet that will generate an incorrect "gleaned" > entry. Well, my implementation doesn't forward packets to a gleaned entry. It puts the entry in "tenative state" awaiting for the Map-Reply. > The question is whether the attacker can parlay this into a longer- > lived map cache entry by flooding the same ITR with map responses > for the EID in the gleaned entry immediately after sending the > packet that caused the gleaned entry in the first place. The > attacker knows that the ITR will send a request for that entry, so > she can play a > numbers game and send replies with as many nonce values as possible, > hoping to hit on the nonce that the ITR uses in its request. The attacker would have to guess each nonce. Unlikely. >> No this isn't true. What ties the real ETRs and no one else to the >> EID in a Map-Request is the authenticated registration to the map- >> server. > > The ITR that sends the map request can't see the authenticated > registration in the map server. > > I am not saying that an attacker could get a spoofed entry into the > mapping system. We don't actually require map responses to come > from the mapping system; they come directly from ETRs, at least some > cases, and they don't contain any information that can be used to > authenticate the data. So, there is no reason that an attacker > couldn't generate responses that, if they happen to hit the right > nonce value, would look just as authentic to the requesting ITR as > responses from the real ETR. Right, but it's a question of probability versus complex machinery to make it secure for those remote cases. I'd like to remind you that the DNS has lived with this problem for a very long time. >> All the attacker can do is send packets to the xTR which it drops. >> At the same rate, the xTR would get packets to decapsulated. All >> limited to the rate of the PE/CE link. > > It will drop them unless the nonce matches. >> >> >>> There are a couple ways to deal with this attack that I can think >>> of: >>> >>> (1) Make the nonce in the map request/reply larger (64-bits or >>> more?), so that there is a much smaller chance that an attacker >>> can hit upon a matching nonce. This could probabilistically limit >>> the case where >> >> The L2TP guys have said that 32-bit cookies work pretty well. > > What do they use the 32-bit cookies to protect? It is possible that > a 32-bit nonce is sufficient to protect the map request/reply > system, but given the level of danger if we are wrong, I think it > would be wiser to move to a 64-bit nonce. These are in control > packets only, so moving to a longer nonce shouldn't effect > forwarding performance or anything. I agree that if we end-up > moving to authenticating the individual mapping entries we won't > need a 64-bit nonce, but isn't clear that we need a 32-bit nonce in > that case, either. So what makes you think a ITR can process fast enough a blast of nonces where 32-bits won't be long enough? >>> attackers could create a bogus map cache entry using this >>> mechanism to on-path attackers. I don't have the security >>> analysis skills to >>> know how long the nonce needs to be to make it large enough to >>> thwart an off-path attacker, but we could probably get someone >>> from the security area to help us figure >>> that out. >>> >>> (2) Require that the reply be sent from the map resolver to whom >>> the request was sent, perhaps with additional authentication to >>> indicate that it was actually sent from that map resolver. This >>> would make it necessary for an attacker to gain control of a map >>> resolver and/or to reconfigure the ITR in order to inject bogus >>> map cache entries. >> >> We don't need to do this. But to be honest I don't understand what >> you are proposing. But it sounds like a lot of machinery. > > A longer nonce wouldn't require any additional machiner. Let's see what the working group consensus is on this. > >>> What happens if you get two different replies that both have the >>> right nonce? Will you accept the first >> >> The second mapping data overrides the first. >> >>> and then accept the second, overwriting the information received >>> in the first? Or will you accept the first, throw away the state >>> related to that nonce, and reject the second because it doesn't >>> match any open nonce? Either way, if an attacker can send a reply >>> with a matching nonce (regardless of how many replies he sends >>> that don't match), you will end-up using his mapping about 50% of >>> the time, instead of the mapping >>> from the real ETR that serves that EID prefix. >> >> We will accept both which are secure and from the authoritative >> source. >> >> The same nonce would only happen if the ITR sent 2 Map-Requests >> with the same nonce and a different ETR at each site received it >> and replies. Which is a valid scenario. >> >> And the attacker could only exist if it was man in the middle. But >> it would have to be in the middle of both the ALT and the Map-Reply >> return path. Which usually is an on-path device and rare. > > The attack I am talking about is not an on-path attack. It is > performed by an off-path attacker who makes some guesses about how a > particular LISP implementation will perform. It becomes > particularly dangerous if any of ship LISP implementations with > (cryptographically) poor random number generators, which might allow > an off-path attacker to optimize the specific nonce values that it > will try in its spoofed responses. By the way, the ETR would also have to guess the EID-prefix used by the site as well. So if the attacker replied with a mask-length that was not returned by the authoritative ETR, then the ITR knows there is a spoofer. But I bet in practice, you won't be able to realize this attack. Dino From dino@cisco.com Tue Sep 8 22:08: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 7B8163A688F for ; Tue, 8 Sep 2009 22:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 P8Ue6YGXkhoE for ; Tue, 8 Sep 2009 22:08:42 -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 51A773A67B0 for ; Tue, 8 Sep 2009 22:08:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIfVpkqrR7MV/2dsb2JhbADEcIhDAZA0BYQYimA X-IronPort-AV: E=Sophos;i="4.44,356,1249257600"; d="scan'208";a="239081938" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Sep 2009 05:09:14 +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 n8959EEQ028099; Tue, 8 Sep 2009 22:09:14 -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 n8959EFT001932; Wed, 9 Sep 2009 05:09:14 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, 8 Sep 2009 22:09:13 -0700 Received: from [192.168.1.3] ([10.21.149.31]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 22:09:13 -0700 Message-Id: <0347DCC7-2FFC-4D87-BDCF-ED4FAB3B8860@cisco.com> From: Dino Farinacci To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-Reply-To: <20090909040029.45A236BE60C@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, 8 Sep 2009 22:09:13 -0700 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Sep 2009 05:09:13.0617 (UTC) FILETIME=[AC27C810:01CA310B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4178; t=1252472954; x=1253336954; 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#8=3A=20Limits=20on=20=22Glean ed=22=20Map=20Entries=20Not=20Clear |Sender:=20; bh=jfiM3WXk0OtN5f7H5ROPRdTO4JorxzSySNxMKjjP0+I=; b=XzQ0d1+11waSRpYBmodT1+Eu5AiAf7XGImiS64xAp6jy1FEN79qg0F9CJJ H1mxMzxh7ahDnOtJTUZZkN1pF2N9U/zdGED5dHY5VYjEX4OaWKhvsDv5ZEEB OojtNdrOg8IeTtH7s2mdCfD/vzuYuO2FXCqe2aWflcENCEVS8dcAg=; 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] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 05:08:43 -0000 But you know Noel, all this is not really needed. I mean the data gleaning provides little value in an untrusted environment. If the ITR is going to send a verifying Map-Request, it could just sent a regular one for a return packet. The reason we put data gleaning in the spec is because we talked to hosting providers that wanted to reduce the additional delay in returning packets to client sites. So if they send any type of Map-Request, being it verifying or a regular one, it adds delay. Therefore, the feature can only be used in a trusted environment. We have heard from enterprise sites who want to run LISP internally to their branch offices, would use this feature *without* the verifying step. But I would say for the capital-I Internet, this may not be a useful feature. So we should limit our time working on it. Dino On Sep 8, 2009, at 9:00 PM, Noel Chiappa wrote: > >> From: Margaret Wasserman > >>> That cannot happen. I think you may be convince of that now? > >> No, I don't see what would stop this from happening... >> ... >> (1) The attacker manages to send a spoofed map reply that gets >> processed by the ITR. >> ... >> We all seem to agree that this can happen "for a few seconds" if an >> attacker sends a packet that will generate an incorrect "gleaned" >> entry. > > My brain isn't working too crisply today, but on thinking about it a > bit, I > think I may have seen what Dino was getting at. It has to do with > your point > (1), and the "if an attacker [can] send a packet that will generate an > incorrect 'gleaned' entry" - because that last may be harder than it > seems. > > > Start with a point you made a couple of messages back: > >>>> a "gleaned" map-cache entry will not be created if a map entry >>>> already exists for an EID prefix containing the EID in the received >>>> packet > > In other words, the gleaning attack can't even _start_ iff a cached > map entry > _already exists_. Put another way, it's only possible to attack > mappings > which aren't _already_ cached in the ITR. Any bogus packets, with a > bad > mapping, will be ignored if a valid cache entry for that EID already > exists. > > So there are only two possible 'windows' in which one could do the > two-step > attack. (Step one, 'glean' a bad mapping; step two, validate the bad > mapping > by pre-empting the lookup by flooding the target with bogus replies. > Actually, > there might be circumstances in which one can go directly to the > second step; > see below.) > > The first potential 'window' is before a mapping to a particular > destination > exists; but for popular destinations, there's probably only a small > time > period when that is true, shortly after an ITR restarts. If an > attacker can > cause an ITR to crash and restart, then perhaps this attack would be > mounted, > but that does make the attack harder. > > For non-popular destinations, the attacker would have to know that a > user was > about to attempt communication with a given destination (because > installing a > bogus mapping for a destination that nobody at the attacked site was > going to > communicate with would be a waste of time), which again sounds like > it might > be fairly tricky. > > The second potential 'window' is just after a cached mapping times > out. I > don't recall exactly how timed-out map entries are handled, but if > such > entries become 'provisional', and a validate cycle is started, then > the > attacker could try the second step (only) of the two-step attack - > but they > would have to know when the entry times out, and I don't see how > they could > know that. > > > None of which should be construed as an opinion one way or the other > on > whether it's worth making it harder to spoof Map-Replies - just > trying to > explain why the hole may be very hard to exploit, in practise. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From luigi@net.t-labs.tu-berlin.de Wed Sep 9 01:54: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 42FD63A689A for ; Wed, 9 Sep 2009 01:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.142, 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 vYpNSe0kuz76 for ; Wed, 9 Sep 2009 01:54:19 -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 818D53A6817 for ; Wed, 9 Sep 2009 01:54:19 -0700 (PDT) Received: from dyn100.net.t-labs.tu-berlin.de (dyn100.net.t-labs.tu-berlin.de [130.149.220.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id DA9E2701BAB5; Wed, 9 Sep 2009 10:54:49 +0200 (CEST) Message-Id: <2E833DA6-0BEB-4555-A5BA-33335C8DB565@net.t-labs.tu-berlin.de> From: Luigi Iannone 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: Wed, 9 Sep 2009 10:54:49 +0200 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [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: Wed, 09 Sep 2009 08:54:20 -0000 On Sep 8, 2009, at 21:58 , Sam Hartman wrote: > Do you want the WG to consider adopting your map versioning draft? > If so, are we ready to consider that now or do you want to consider > it when you've refined things more? The draft has to be updated before going for any call. > > If you want to refine things more, what refinements do you want to > make? Mainly specifying how to use the R-bit and how compatibility can be assured with the main spec. All things that have been more or less already discussed, just need to be written down. Luigi From hartmans@mit.edu Wed Sep 9 04:39: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 66B1C28C356 for ; Wed, 9 Sep 2009 04:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_63=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 9Uy7MhUYZJk4 for ; Wed, 9 Sep 2009 04:39: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 8A81D28C355 for ; Wed, 9 Sep 2009 04:39:34 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A787C51CC; Wed, 9 Sep 2009 07:39:51 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> From: Sam Hartman Date: Wed, 09 Sep 2009 07:39:51 -0400 In-Reply-To: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> (Noel Chiappa's message of "Wed\, 9 Sep 2009 00\:00\:29 -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: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 11:39:35 -0000 Hi. Last night, I was trying to convince Margaret that the 32-bit nonce in the map request was sufficient to protect against her attack, but in the process of trying to do so, convinced myself that her attack is too plausible for my comfort. I'm an attacker trying to attack ITR A. 1) Find some EID B that if A looks up a mapping entry for B, it won't get a response. For example, someone who is still registered with their map server, but for whom there is some routing problem between B's ETR and A. Or go attack B and create a routing problem so that B's ETR's packets don't get to A. 2) Send A traffic that will cause A to look up the mapping for B. Often, spoofing traffic that appears to be sourced from B is sufficient for this. There may also be LISP mechanisms sufficient to get this to happen. 3) Generate a bunch of fake map replies, each with a different nonce. If you happen to guess the nonce that A used, then you can insert a verified mapping entry with a fairly large TTL. So, how likely is it? Well, let's assume a gig link, so roughly 2^30 bits/second. Let's assume my map reply packets are roughly 2^12 bits. So, I can send around 2^18 packets a second if I don't mind flooding your link. That gives me a probability of success in a second of 1 in 2^14. However I can repeat the attack. I have a very good probability of success if I'm willing to spend 2^14 seconds or about 4 hours. Now, probably it doesn't quite work that way. I suspect I may be off by as much as a factor of 4 in terms of how much overhead is involved, and how much I can stuff on a gig link. Also, if I generate a gig of traffic at someone for four hours, I'm going to fail on the subtle front. I'm also unconvinced that even if it could handle the load, any sane control plane would accept that much traffic from one source. However, I can scale back and say spend 10 days rather than four hours. Yes, I can think of cases where this attack seems practical and where spending a few days to get a mapping cache entry is worth it. My conclusion here is that 32-bits is not a big enough nonce in the map request and reply. I think that for the price of four bytes per packet,and a 64-bit nonce, we could completely solve this particular attack. From hartmans@mit.edu Wed Sep 9 05:40: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 DAAEF3A66B4 for ; Wed, 9 Sep 2009 05:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 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 d9Te0rmshekx for ; Wed, 9 Sep 2009 05:40:24 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 22E973A68F4 for ; Wed, 9 Sep 2009 05:40:24 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DAD5951CC; Wed, 9 Sep 2009 08:40:40 -0400 (EDT) To: Dino Farinacci References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <0347DCC7-2FFC-4D87-BDCF-ED4FAB3B8860@cisco.com> From: Sam Hartman Date: Wed, 09 Sep 2009 08:40:40 -0400 In-Reply-To: <0347DCC7-2FFC-4D87-BDCF-ED4FAB3B8860@cisco.com> (Dino Farinacci's message of "Tue\, 8 Sep 2009 22\:09\:13 -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] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 12:40:24 -0000 >>>>> "Dino" == Dino Farinacci writes: Dino> But you know Noel, all this is not really needed. I mean the Dino> data gleaning provides little value in an untrusted Dino> environment. Dino> If the ITR is going to send a verifying Map-Request, it Dino> could just sent a regular one for a return packet. The Dino> reason we put data gleaning in the spec is because we talked Dino> to hosting providers that wanted to reduce the additional Dino> delay in returning packets to client sites. Dino> So if they send any type of Map-Request, being it verifying Dino> or a regular one, it adds delay. Therefore, the feature can Dino> only be used in a trusted environment. We have heard from Dino> enterprise sites who want to run LISP internally to their Dino> branch offices, would use this feature *without* the Dino> verifying step. Dino> But I would say for the capital-I Internet, this may not be Dino> a useful feature. So we should limit our time working on it. Then let's remove it. We're chartered to design LISP for the Internet to solve the Internet route scaling problem. I agree with you that it is not useful in the Internet environment, but it significantly complicates the security analysis and once we actually have a security model we'll probably end up removing it then. From mrw@lilacglade.org Wed Sep 9 06:14: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 B9DC23A6965 for ; Wed, 9 Sep 2009 06:14:37 -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 to4aMuRV7qKu for ; Wed, 9 Sep 2009 06:14:36 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 563A828C498 for ; Wed, 9 Sep 2009 06:14:33 -0700 (PDT) Received: from OMTA22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id ecrY1c00A1vN32cA4dF6LT; Wed, 09 Sep 2009 13:15:06 +0000 Received: from [10.2.0.20] ([69.33.111.74]) by OMTA22.emeryville.ca.mail.comcast.net with comcast id edKq1c0071cMU3H8idKt6e; Wed, 09 Sep 2009 13:19:59 +0000 Message-Id: <1589F5F1-BC73-4ADD-A310-9475E6A22A6B@lilacglade.org> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <88F5C0C6-B7FD-4D59-AE18-3B808B4B06B6@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, 9 Sep 2009 09:14:53 -0400 References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> <066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org> <5F97F934-5508-46C7-8778-1978E4BD04CF@lilacglade.org> <6CC7FE39-8B40-4473-8A05-99C12DC7A05F@cisco.com> <49CD8D62-3039-43FD-9622-FAC8FAA800A2@lilacglade.org> <88F5C0C6-B7FD-4D59-AE18-3B808B4B06B6@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 13:14:37 -0000 On Sep 9, 2009, at 12:52 AM, Dino Farinacci wrote: >> >> We all seem to agree that this can happen "for a few seconds" if an >> attacker sends a packet that will generate an incorrect "gleaned" >> entry. > > Well, my implementation doesn't forward packets to a gleaned entry. > It puts the entry in "tenative state" awaiting for the Map-Reply. Shouldn't the specification say this, then? If so, this would close a possible security concern. I had assumed that when the specification said you could create a "gleaned" map cache entry that it meant that you could _store and use_ a "gleaned" map cache entry. What is the point of creating the tentative entry at all if you won't use it? > > I'd like to remind you that the DNS has lived with this problem for > a very long time. Not quite, because DNS requires that the response be returned by the server to which the request was sent. LISP allows a response to come from anywhere. >> >> The attack I am talking about is not an on-path attack. It is >> performed by an off-path attacker who makes some guesses about how >> a particular LISP implementation will perform. It becomes >> particularly dangerous if any of ship LISP implementations with >> (cryptographically) poor random number generators, which might >> allow an off-path attacker to optimize the specific nonce values >> that it will try in its spoofed responses. > > By the way, the ETR would also have to guess the EID-prefix used by > the site as well. So if the attacker replied with a mask-length that > was not returned by the authoritative ETR, then the ITR knows there > is a spoofer. How does the ITR tell which response is coming from the authoritative ETR and which isn't? Margaret From mrw@sandstorm.net Wed Sep 9 06:21: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 3F9163A6B03 for ; Wed, 9 Sep 2009 06:21:31 -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 mEDF12CFcmZL for ; Wed, 9 Sep 2009 06:21:30 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 5EC093A69EB for ; Wed, 9 Sep 2009 06:21:30 -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 n89DLw1m088886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2009 09:21:59 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <38F03CB7-B548-459C-88AE-44EBED6F9C20@sandstorm.net> From: Margaret Wasserman To: Margaret Wasserman In-Reply-To: <1589F5F1-BC73-4ADD-A310-9475E6A22A6B@lilacglade.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, 9 Sep 2009 09:21:58 -0400 References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> <066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org> <5F97F934-5508-46C7-8778-1978E4BD04CF@lilacglade.org> <6CC7FE39-8B40-4473-8A05-99C12DC7A05F@cisco.com> <49CD8D62-3039-43FD-9622-FAC8FAA800A2@lilacglade.org> <88F5C0C6-B7FD-4D59-AE18-3B808B4B06B6@cisco.com> <1589F5F1-BC73-4ADD-A310-9475E6A22A6B@lilacglade.org> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 13:21:31 -0000 Just to make my response a little clearer... On Sep 9, 2009, at 9:14 AM, Margaret Wasserman wrote: >> >> I'd like to remind you that the DNS has lived with this problem for >> a very long time. > > Not quite, because DNS requires that the response be returned by the > server to which the request was sent. LISP allows a response to > come from anywhere. This is significant for two reasons: (1) I can send the response from anywhere, using valid addresses for that location, so I don't need to worry about my packets being ingress filtered for having an invalid source address, and (2) When I am flooding the ITR with responses trying to get a nonce hit, I can do so from many different systems. In other words, this lends itself to a distributed attack. Margaret From jnc@mercury.lcs.mit.edu Wed Sep 9 06: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 6FAA928C4A9 for ; Wed, 9 Sep 2009 06:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 LzoXzlhg0jal for ; Wed, 9 Sep 2009 06:42: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 85F4428C4AC for ; Wed, 9 Sep 2009 06:42:34 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 155D66BE617; Wed, 9 Sep 2009 09:43:06 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090909134306.155D66BE617@mercury.lcs.mit.edu> Date: Wed, 9 Sep 2009 09:43:06 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 13:42:35 -0000 > From: Sam Hartman >> The reason we put data gleaning in the spec is because we talked to >> hosting providers that wanted to reduce the additional delay in >> returning packets to client sites. >> .. if they send any type of Map-Request, being it verifying or a >> regular one, it adds delay. >> ... >> We have heard from enterprise sites who want to run LISP internally to >> their branch offices, would use this feature *without* the verifying >> step. > Then let's remove it. No, because, as Dino points out, there are a number of potential early adoptets to whoom it is important. We can't afford to blow off early adopters. A lot of the larger entities which have been talked to have some very sharp technical people 'on team', and so concerns that they have expressed have been taken very seriously - it's not just that they are users, and you have to make the users happy, it's also that they are pretty sharp, and may have good points. > I agree with you that it is not useful in the Internet environment, I'm not sure I follow this statement (from either you or Dino). What exactly is meant by "hosting providers that wanted to reduce the additional delay ... to client sites"? I'm assuming these providers, and their clients, are generic HPs and their users, who would indeed be out there in the ordinary Internet. > it significantly complicates the security analysis Well, yes and no. We can debate the size of the hold (my message last night was an attempt to do that), but no matter what size it is, there is a simple fix (increasing the nonce size). > once we actually have a security model we'll probably end up removing > it then. Down the road, perhaps. But one still must get to mile-post 1, before we can plan what to do at mile-post 10. Hence my concern for the concerns of early adopters. Noel From mrw@sandstorm.net Wed Sep 9 07:01: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 F313128C4C2 for ; Wed, 9 Sep 2009 07:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 IZX0eVdxAe-d for ; Wed, 9 Sep 2009 07:01:57 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id DF81D28C4C0 for ; Wed, 9 Sep 2009 07:01:56 -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 n89E2Kch091184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2009 10:02:20 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <21E10AF9-4336-4F23-8E6F-8A0640A2AB35@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090909134306.155D66BE617@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, 9 Sep 2009 10:02:20 -0400 References: <20090909134306.155D66BE617@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 14:01:58 -0000 On Sep 9, 2009, at 9:43 AM, Noel Chiappa wrote: >> Then let's remove it. > > No, because, as Dino points out, there are a number of potential early > adoptets to whoom it is important. We can't afford to blow off early > adopters. There are a lot of early adopters who insist that we do what, exactly? Who are these early adopters? Is it possible to get them to state their requirements to the WG, so that we can discuss the best way to meet them, rather than stating their requirements as a need for a specific solution? Margaret From jnc@mercury.lcs.mit.edu Wed Sep 9 07:50: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 A0AE83A6C36 for ; Wed, 9 Sep 2009 07:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 ldHfvo+Ljh6F for ; Wed, 9 Sep 2009 07:50: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 007E23A6C31 for ; Wed, 9 Sep 2009 07:50:23 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A4F386BE61A; Wed, 9 Sep 2009 10:50:55 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090909145055.A4F386BE61A@mercury.lcs.mit.edu> Date: Wed, 9 Sep 2009 10:50:55 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 14:50:25 -0000 > From: Margaret Wasserman > Is it possible to get them to state their requirements to the WG, so > that we can discuss the best way to meet them, rather than stating > their requirements as a need for a specific solution? The impression I get from Dino's original is that their requirement was indeed put in high-level terms, not as a specific mechanism: >>> hosting providers that wanted to reduce the additional delay in >>> returning packets to client sites which I gather means 'packet arrives at large content provider site from previously unheard-from correspondent, i.e. no cached mapping in the ITRs at the LCPS, and the LCPS wants to be able to return a reply ASAP, in particular without waiting for a mapping resolution cycle'. BTW, I see from looking in my records that this particular optimization _may_ have come out of a block of work I did on optimizing CONS, back in 2007 - at least, this particular optimization is discussed in the notes I have there. It may also have been thought about before that - IIRC, some of the other deployment models of LISP (e.g. LISP 1) used a similar concept. Anyway, here is the block of notes about that particular optimization, from a table of potential optimizations from September, 2007): #2b - Piggybacking of client bindings on initial data packet o Not considered at length o Costs are modest -- The ITRs either have to have some way of deciding which packets are initial packets (probably means extra state), or they'd have to put the binding on all packets -- Extra fields in the data packet to contain the reverse bindinga -- Processing of normal data packets in ETR is more complex, as they have to check for, and process, the binding o Benefits are significant -- Removes all the overhead of the reverse request, in almost all cases o Vulnerable to hijacking unless the binding is secured in some way o Vulnerable to DoS unless the binding is secured in some way o This one also has the issue if the return ITR isn't the same as the incoming ETR - the binding would have to be forwarded Obviously, many (most?) of the optimizations in that table are CONS-speciic, but several of them are directed at this very point: reducing the delay for LCPS's to respond to clients which are contacting them for the first time. I also have an extensive series of essays covering this very point: Caching bindings in the CDR hierarchy is half of what we need to make CONS work quite well for large content providers. ... It's the other direction that I think we need to think about now; i.e. the second binding needed for any two-way communication. I've been called these 'reverse' bindings, but that is probably not the best term for that binding, because a 'reverse binding' is usually the binding between two names, but in the other direction to normal, e.g. in our case an RLOC->EID binding. So I'm going to start calling these 'client bindings'. To be exact, I use this term for the second of a pair of binding requests, one from each end - on the assumption that although not all pairwise connections are client/server, many are, and for all client/server interactions, the client does the lookup of the 'server binding' first. (One can be fairly certain that the other end will in fact need this binding, because if the client's ITR needs the server binding, the two probably have not communicated previously, and so the server's ITR won't have the client binding either; i.e. sending the client binding to the server end is not useless overhead.) We've discussed this a bit, alluding briefly to piggybacking them on server binding requests, and adding them to initial data packets. We've also mentioned some of the difficulties caused by non-symmetric operation, both for the [x]TRs and the CARs. What I want to do here is a more complete analysis of the whole problem, along with a detailed recommendation. but alas most of it is CONS-specific, so I don't think there's too much use in forwarding it. Noel From jnc@mercury.lcs.mit.edu Wed Sep 9 08:38: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 ABA0728C2FF for ; Wed, 9 Sep 2009 08:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 OKl6W1NXXAjj for ; Wed, 9 Sep 2009 08:38: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 D358A28C39A for ; Wed, 9 Sep 2009 08:38:14 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C4AFE6BE619; Wed, 9 Sep 2009 11:38:44 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090909153844.C4AFE6BE619@mercury.lcs.mit.edu> Date: Wed, 9 Sep 2009 11:38:44 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: [lisp] Packet format change mechanism [Was: #8: Limits on "Gleaned" Map Entries Not Clear] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 15:38:15 -0000 > From: Margaret Wasserman > I think it would be wiser to move to a 64-bit nonce. These are in > control packets only, so moving to a longer nonce shouldn't effect > forwarding performance or anything. This message isn't really about this particular issue (hence the mod to the subject line), but this gave me a good 'hook' to start from. Let me seque into my main point by saying that I personally don't have a strong feeling one way on another on this particular point. I think both are right - Dino that the hole is very small (see my message from last night: http://www.ietf.org/mail-archive/web/lisp/current/msg01304.html which still seems accurate to me, although I haven't thought deeply about it today), and Margaret that the fix is simple and cheap. (Heck, a cheapo ITR which thinks the risk is negligible can use only 32 bits of randomness, and zero-fill the other half of the field.) What is _not_ cheap is the change to the packet format - but I am _not_ suggesting we don't make packet format changes (far from it), merely suggesting a change in _how_ we make changes to the format. To start with, everyone needs to understand that there is a substantial deployed testbed. Every time we make an incompatiable change to the packet format, the testbed has to bifurcate and/or have a flag day. This is a hassle, and slows down progress. So my suggestion is simple: we divide packet format changes into 'critical' and 'non-critical'. Non-critical changes are changes that we want to add, but aren't necessary 'right away'. (This 32->64 fix, if agreed on, would be an example.) We should accumulate non-critical changes in a list somewhere (do we have a IETF Wiki page, or something, where we could keep it?), and only add them in batches when either i) we make a critical change (i.e. the format is going to change _anyway_), or ii) we're about to do some significant milestone and it's OK to add them (e.g. go to RFC). I think that this mechanism nicely satisfies both i) the need to be able to make changes, and ii) the need not to disrupt the testbed with 'flag days' unless absolutely unavoidable. Noel From hartmans@mit.edu Wed Sep 9 08:54: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 47E7028C426 for ; Wed, 9 Sep 2009 08:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 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 iw8-tcMF55oq for ; Wed, 9 Sep 2009 08:54:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 8BFEF28C41A for ; Wed, 9 Sep 2009 08:54:40 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3F64B51CC; Wed, 9 Sep 2009 11:54:57 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090909153844.C4AFE6BE619@mercury.lcs.mit.edu> From: Sam Hartman Date: Wed, 09 Sep 2009 11:54:57 -0400 In-Reply-To: <20090909153844.C4AFE6BE619@mercury.lcs.mit.edu> (Noel Chiappa's message of "Wed\, 9 Sep 2009 11\:38\:44 -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] Packet format change mechanism [Was: #8: Limits on "Gleaned" Map Entries Not Clear] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 15:54:41 -0000 We do have wiki pages off http://tools.ietf.org/wg/lisp, and in my individual opinion this would be an excellent use of wiki pages. I'd prefer to see format changes made at least every six months. From hartmans@mit.edu Wed Sep 9 08:57: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 547DC28C454 for ; Wed, 9 Sep 2009 08:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 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 y4D412ytrRQ5 for ; Wed, 9 Sep 2009 08:57:55 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 99D8F28C44E for ; Wed, 9 Sep 2009 08:57:55 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DBF3D51CC; Wed, 9 Sep 2009 11:58:12 -0400 (EDT) To: Margaret Wasserman References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> <066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org> <5F97F934-5508-46C7-8778-1978E4BD04CF@lilacglade.org> <6CC7FE39-8B40-4473-8A05-99C12DC7A05F@cisco.com> <49CD8D62-3039-43FD-9622-FAC8FAA800A2@lilacglade.org> <88F5C0C6-B7FD-4D59-AE18-3B808B4B06B6@cisco.com> <1589F5F1-BC73-4ADD-A310-9475E6A22A6B@lilacglade.org> From: Sam Hartman Date: Wed, 09 Sep 2009 11:58:12 -0400 In-Reply-To: <1589F5F1-BC73-4ADD-A310-9475E6A22A6B@lilacglade.org> (Margaret Wasserman's message of "Wed\, 9 Sep 2009 09\:14\: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] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 15:57:56 -0000 >>>>> "Margaret" == Margaret Wasserman writes: >> I'd like to remind you that the DNS has lived with this problem >> for a very long time. Margaret> Not quite, because DNS requires that the response be Margaret> returned by the server to which the request was sent. Also, I'll point out that we've spent the last year trying madly to find ways of increasing DNS's nonce size exactly because of this sort of attack. And there, yes, we do have real-world proofs of the problem. From darlewis@cisco.com Wed Sep 9 09:06: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 D43133A6998 for ; Wed, 9 Sep 2009 09:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.259 X-Spam-Level: X-Spam-Status: No, score=-6.259 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, J_CHICKENPOX_63=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 wvnkLlUBuyiF for ; Wed, 9 Sep 2009 09:06:05 -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 D0A1F28C0DB for ; Wed, 9 Sep 2009 09:06:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIJvp0qrR7PE/2dsb2JhbADFUYhDAZBjBYQYimA X-IronPort-AV: E=Sophos;i="4.44,359,1249257600"; d="scan'208";a="385200500" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Sep 2009 16:06:38 +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 n89G6cQU023294; Wed, 9 Sep 2009 09:06:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n89G6c0T010596; Wed, 9 Sep 2009 16:06:38 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); Wed, 9 Sep 2009 09:06:38 -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, 9 Sep 2009 09:06:40 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] 32-bit nonce in map request insufficient Thread-Index: AcoxQk257ks2aa5DSvOe9BC605M6wgAI/MPg References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> From: "Darrel Lewis (darlewis)" To: "Sam Hartman" , "Noel Chiappa" X-OriginalArrivalTime: 09 Sep 2009 16:06:38.0260 (UTC) FILETIME=[82FEA740:01CA3167] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3265; t=1252512398; x=1253376398; c=relaxed/simple; s=sjdkim4002; 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]=2032-bit=20nonce=20in=20map=20re quest=20insufficient |Sender:=20; bh=YXLfpwG1TRKXxZYb5P4R/ds1lNZExWOrFOC5BMv0rBo=; b=CvTzdvsEF4LrNSgHhF3tW0xRkU1ZvYQX+Y3oJALLlVxM5KToVbB6WY9x+9 g7mnQbtLZDoIjFK2IB7k+6JEYt043yi+YrDMRIzUj5SFhoBRHsi7GsyVnKA8 zJsmBK3qY8; Authentication-Results: sj-dkim-4; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 16:06:06 -0000 >=20 > I'm an attacker trying to attack ITR A. >=20 > 1) Find some EID B that if A looks up a mapping entry for B, it won't > get a response. For example, someone who is still registered with > their map server, but for whom there is some routing problem between > B's ETR and A. Or go attack B and create a routing problem so that > B's ETR's packets don't get to A. A routing problem on the ALT? But basically the map-request is dropped. >=20 > 2) Send A traffic that will cause A to look up the mapping for B. > Often, spoofing traffic that appears to be sourced from B is > sufficient for this. There may also be LISP mechanisms sufficient to > get this to happen. Yes this is possible. >=20 > 3) Generate a bunch of fake map replies, each with a different nonce. > If you happen to guess the nonce that A used, then you can insert a > verified mapping entry with a fairly large TTL. A bunch, as in several thousand? Remember these map replies will be rate limited, and the fact that they have incorrect nonce's logged. >=20 > So, how likely is it? Well, let's assume a gig link, so roughly 2^30 > bits/second. Let's assume my map reply packets are roughly 2^12 bits. > So, I can send around 2^18 packets a second if I don't mind flooding > your link. That gives me a probability of success in a second of 1 in > 2^14. However I can repeat the attack. I have a very good > probability of success if I'm willing to spend 2^14 seconds or about 4 > hours. The key isn't the access link speed, it's the capacity of the control plane of the ITR and the rate limiting mechanisms into the control plane. This will result in a _few hundred_ packets per second of map-replies being the maximum allowed by the implementation. So I suspect you're off by several orders of magnitude in your timing because of this. >=20 > Now, probably it doesn't quite work that way. I suspect I may be off > by as much as a factor of 4 in terms of how much overhead is involved, > and how much I can stuff on a gig link. Also, if I generate a gig of > traffic at someone for four hours, I'm going to fail on the subtle > front. I'm also unconvinced that even if it could handle the load, > any sane control plane would accept that much traffic from one > source. However, I can scale back and say spend 10 days rather than > four hours. If you notice you're under attack, you (if possible) access list this attacker, and if you cannot you call your upstream provider, traceback the attack with the help of your upstream, possibly black hole the source, change the IP of your link, etc. Basically all the ways you deal with an attack today. =20 >=20 > Yes, I can think of cases where this attack seems practical and where > spending a few days to get a mapping cache entry is worth it. I'm sorry I disagree with you. =20 >=20 > My conclusion here is that 32-bits is not a big enough nonce in the > map request and reply. I think that for the price of four bytes per > packet,and a 64-bit nonce, we could completely solve this particular > attack. I disagree with your conclusion, I feel this is not a feasible attack, and you haven't shown it to be operationally practical. -Darrel From hartmans@mit.edu Wed Sep 9 09:17: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 28F4C28C4F5 for ; Wed, 9 Sep 2009 09:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 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 Mg3jvQLK1ZWU for ; Wed, 9 Sep 2009 09:17: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 65D9F3A6BA8 for ; Wed, 9 Sep 2009 09:17:02 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4EA7F51CC; Wed, 9 Sep 2009 12:17:19 -0400 (EDT) To: "Darrel Lewis \(darlewis\)" References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> From: Sam Hartman Date: Wed, 09 Sep 2009 12:17:19 -0400 In-Reply-To: (Darrel Lewis's message of "Wed\, 9 Sep 2009 09\:06\:40 -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] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 16:17:03 -0000 >>>>> "Darrel" == Darrel Lewis (darlewis) writes: >> >> I'm an attacker trying to attack ITR A. >> >> 1) Find some EID B that if A looks up a mapping entry for B, it >> won't get a response. For example, someone who is still >> registered with their map server, but for whom there is some >> routing problem between B's ETR and A. Or go attack B and >> create a routing problem so that B's ETR's packets don't get to >> A. Darrel> A routing problem on the ALT? But basically the Darrel> map-request is dropped. No, a routing problem between the ETR serving B and A. Being able to suppress the map request from getting to B's ETR is nice but not required. Darrel> replies will be rate limited, and the fact that they have Darrel> incorrect nonce's logged. Darrel> The key isn't the access link speed, it's the capacity of Darrel> the control plane of the ITR and the rate limiting Darrel> mechanisms into the control plane. This will result in a Darrel> _few hundred_ packets per second of map-replies being the Darrel> maximum allowed by the implementation. So I suspect Darrel> you're off by several orders of magnitude in your timing Darrel> because of this. OK, so we're talking a month to mount the attack. Sorry, but that is still outside my comfort margins given the simplicity of the fix. Again, I don't think it is reasonable to require sites to notice attacks like this and to take steps to stop them--possibly having to root out an entire distributed botnet--when we can fix the problem with a reasonably small protocol change. From darlewis@cisco.com Wed Sep 9 09:24: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 D378028C17F for ; Wed, 9 Sep 2009 09:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 zCtyRhGt4Wpa for ; Wed, 9 Sep 2009 09:24:32 -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 12ADF28C148 for ; Wed, 9 Sep 2009 09:24:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALtzp0qrR7PD/2dsb2JhbADFdYhDAZBiBYQY X-IronPort-AV: E=Sophos;i="4.44,359,1249257600"; d="scan'208";a="239363595" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Sep 2009 16:25:05 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n89GP5Qq024110; Wed, 9 Sep 2009 09:25:05 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n89GP54e021473; Wed, 9 Sep 2009 16:25:05 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); Wed, 9 Sep 2009 09:25:04 -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, 9 Sep 2009 09:25:05 -0700 Message-ID: In-Reply-To: <1589F5F1-BC73-4ADD-A310-9475E6A22A6B@lilacglade.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear Thread-Index: AcoxT5EtD4FOrlpCRWG6m5cPjcQ7PwAGPTEQ References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org><066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org><5F97F934-5508-46C7-8778-1978E4BD04CF@lilacglade.org><6CC7FE39-8B40-4473-8A05-99C12DC7A05F@cisco.com><49CD8D62-3039-43FD-9622-FAC8FAA800A2@lilacglade.org><88F5C0C6-B7FD-4D59-AE18-3B808B4B06B6@cisco.com> <1589F5F1-BC73-4ADD-A310-9475E6A22A6B@lilacglade.org> From: "Darrel Lewis (darlewis)" To: "Margaret Wasserman" , "Dino Farinacci (dino)" X-OriginalArrivalTime: 09 Sep 2009 16:25:04.0910 (UTC) FILETIME=[169C0AE0:01CA316A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1722; t=1252513505; x=1253377505; 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]=20#8=3A=20Limits=20on=20=22Glean ed=22=20Map=20Entries=20Not=20Clear |Sender:=20; bh=MXlozQoa2hl4YweAeIWtf2j4NsfXyI68Ani6bCpSeos=; b=s4HMw98R6aV6huCENOZE7zaelcyZbUfZDA54N4bzahRPEG7lZJ0RfwFjYC +ASLzdrsJaNAbEpqDh+VLsw+7FusTEohjsIELTblMyY+awx1Ag8qbArMMBJ2 NysbE5wKJe; Authentication-Results: sj-dkim-3; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 16:24:32 -0000 > Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear >=20 >=20 > On Sep 9, 2009, at 12:52 AM, Dino Farinacci wrote: > >> > >> We all seem to agree that this can happen "for a few=20 > seconds" if an =20 > >> attacker sends a packet that will generate an incorrect "gleaned" =20 > >> entry. > > > > Well, my implementation doesn't forward packets to a=20 > gleaned entry. =20 > > It puts the entry in "tenative state" awaiting for the Map-Reply. >=20 > Shouldn't the specification say this, then? If so, this=20 > would close a =20 > possible security concern. I had assumed that when the=20 > specification =20 > said you could create a "gleaned" map cache entry that it meant that =20 > you could _store and use_ a "gleaned" map cache entry. What is the =20 > point of creating the tentative entry at all if you won't use it? > > I think we have a communication problem on this thread. =20 Dino's comments seem to be about data-gleaning. That is, placing map entries in the cache by inspecting the data-plane traffic. That is, techniques described around=20 Margaret and Noel (I think) seem to be talking about the map-data that is piggybacked on a Map-Request packet. So if this is the case (apologies if I mis-represented anyone's point of view) hopefully by pointing this out this could help clear up the discussion. Speaking just for myself, Data Plane gleaning doesn't seem useful in the capital I internet, but Map-Request map-data gleaning is very useful, since it prevents packet loss/delay on return traffic of session set up. (several content providers emphasized this as an important feature during LISP's presentations at NANOG). -Darrel From dino@cisco.com Wed Sep 9 09:42: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 7AD113A6A63 for ; Wed, 9 Sep 2009 09:42:38 -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 Z7I48EmLlv57 for ; Wed, 9 Sep 2009 09:42: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 E1DCF3A6A4B for ; Wed, 9 Sep 2009 09:42:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALd3p0qrR7O6/2dsb2JhbADFfohDAZBeBYQY X-IronPort-AV: E=Sophos;i="4.44,359,1249257600"; d="scan'208";a="385230248" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Sep 2009 16:43:10 +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 n89Gh9jN030002; Wed, 9 Sep 2009 09:43:09 -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 n89Gh9Pk028308; Wed, 9 Sep 2009 16:43:09 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, 9 Sep 2009 09:43:09 -0700 Received: from [192.168.1.2] ([10.21.125.164]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 09:43:09 -0700 Message-Id: <3915E94A-0F0E-4832-8DA7-1301615639BD@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <1589F5F1-BC73-4ADD-A310-9475E6A22A6B@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: Wed, 9 Sep 2009 09:43:08 -0700 References: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> <066.05400d447ae9dbcf77be1ad4ee9237d7@tools.ietf.org> <5F97F934-5508-46C7-8778-1978E4BD04CF@lilacglade.org> <6CC7FE39-8B40-4473-8A05-99C12DC7A05F@cisco.com> <49CD8D62-3039-43FD-9622-FAC8FAA800A2@lilacglade.org> <88F5C0C6-B7FD-4D59-AE18-3B808B4B06B6@cisco.com> <1589F5F1-BC73-4ADD-A310-9475E6A22A6B@lilacglade.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Sep 2009 16:43:09.0192 (UTC) FILETIME=[9CE45880:01CA316C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2215; t=1252514589; x=1253378589; 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]=20#8=3A=20Limits=20on=20=22Glean ed=22=20Map=20Entries=20Not=20Clear |Sender:=20; bh=eBnzBJGN6AZu0zKSHWqpwUqOWub8bf8rSbh4dvesYqw=; b=HG3W7b4oFbMAQjjxpSY9Tuk/kpmAeFSvLsQQLYjxQpuAwNofXvIvPmQwOB YeNaOOg3GLGw5/ubyoiWiOQuA3DQSdz7KBgtIkjPuuKjIVVL60UA1Cmb1O/6 JLlLvgjRbl; 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] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 16:42:38 -0000 > On Sep 9, 2009, at 12:52 AM, Dino Farinacci wrote: >>> >>> We all seem to agree that this can happen "for a few seconds" if >>> an attacker sends a packet that will generate an incorrect >>> "gleaned" entry. >> >> Well, my implementation doesn't forward packets to a gleaned entry. >> It puts the entry in "tenative state" awaiting for the Map-Reply. > > Shouldn't the specification say this, then? If so, this would close > a possible security concern. I had assumed that when the > specification said you could create a "gleaned" map cache entry that > it meant that you could _store and use_ a "gleaned" map cache > entry. What is the point of creating the tentative entry at all if > you won't use it? Well, we wanted to leave it up to the implementation. Because in a trusted environment, to reduce delay, you could use the data-gleaned entry right away. Like I mentioned in a previous email. >> I'd like to remind you that the DNS has lived with this problem for >> a very long time. > > Not quite, because DNS requires that the response be returned by the > server to which the request was sent. LISP allows a response to > come from anywhere. Well I could build a server that can return a request from anywhere. I think both cases use solicitation to get a response. >>> >>> The attack I am talking about is not an on-path attack. It is >>> performed by an off-path attacker who makes some guesses about how >>> a particular LISP implementation will perform. It becomes >>> particularly dangerous if any of ship LISP implementations with >>> (cryptographically) poor random number generators, which might >>> allow an off-path attacker to optimize the specific nonce values >>> that it will try in its spoofed responses. >> >> By the way, the ETR would also have to guess the EID-prefix used by >> the site as well. So if the attacker replied with a mask-length >> that was not returned by the authoritative ETR, then the ITR knows >> there is a spoofer. > > How does the ITR tell which response is coming from the > authoritative ETR and which isn't? The 32-bit nonce. Dino > > Margaret > From jnc@mercury.lcs.mit.edu Wed Sep 9 10:09: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 9FE933A6AA7 for ; Wed, 9 Sep 2009 10:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 LfkNXRopLGXZ for ; Wed, 9 Sep 2009 10:09:27 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id CA42F28C102 for ; Wed, 9 Sep 2009 10:09:24 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A5AA46BE61A; Wed, 9 Sep 2009 13:09:56 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090909170956.A5AA46BE61A@mercury.lcs.mit.edu> Date: Wed, 9 Sep 2009 13:09:56 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 17:09:28 -0000 > From: "Darrel Lewis (darlewis)" > Dino's comments seem to be about data-gleaning. That is, placing map > entries in the cache by inspecting the data-plane traffic. > ... > Margaret and Noel (I think) seem to be talking about the map-data that > is piggybacked on a Map-Request packet. Umm, no, but it's complicated. Margaret is concerned (and I was discussing) a _two-step_ attack process, the first step of which involves a temporary, gleaned, mapping ("map entr[y] in the cache by inspecting the data-plane traffic"), and the second step of which involves making that entry permanent by sneaking in a bogus Map-Reply, by bombarding the ITR with bogus Map-Replies, hoping that one will have the correct nonce. AFAIK, we haven't discussed/considered here the "map-data ... piggybacked on a Map-Request packet" stuff at all. > Data Plane gleaning doesn't seem useful in the capital I internet, but > Map-Request map-data gleaning is very useful, since it prevents packet > loss/delay on return traffic of session set up. Now you have _me_ confused! :-) I thought user-data gleaning was used/useful for precisely the same reason, i.e. the it avoided having to do a binding cycle for the return packets. Now you're saying that that functionality is provided by piggybacking the client binding on the request for the server binding? (I.e. the request for the server binding will be delivered to an ETR at the server site, and that device can retain the client binding from that Map-Request, so that when the return packet shows up, the client binding is already there?) If so, then yes, user-data gleaning seems to be superfluous. But now we seem to have two separate, but intertwined, issues: i) optimization of acquisition of client bindings (because I have some questions about the piggybacked binding mechanism), and ii) the security of the Map-Requst/Map-Reply cycle triggered by gleaning bindings from user-data packets (the original issue). Noel From mrw@sandstorm.net Wed Sep 9 11: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 E5F6D28C16D for ; Wed, 9 Sep 2009 11:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 3hONAp+dX0qK for ; Wed, 9 Sep 2009 11:16:04 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id CD48F28C525 for ; Wed, 9 Sep 2009 11:16:02 -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 n89IG4FJ004861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2009 14:16:04 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@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: Wed, 9 Sep 2009 14:16:04 -0400 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 18:16:05 -0000 Hi Darrel, On Sep 9, 2009, at 12:06 PM, Darrel Lewis (darlewis) wrote: > > A bunch, as in several thousand? Remember these map replies will be > rate limited, and the fact that they have incorrect nonce's logged. In the attack we are describing, "these map replies" are being sent by an attacker (possibly from multiple remote ETRs) to insert a spoofed map-cache entry in an ITR. I realize that the LISP spec says that the sender should rate limit its replies, but attackers don't typically follow that sort of advice. Margaret From mrw@sandstorm.net Wed Sep 9 11:18: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 A7D123A699E for ; Wed, 9 Sep 2009 11:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 nli9C-gVlqO0 for ; Wed, 9 Sep 2009 11:18:50 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 2116C3A694E for ; Wed, 9 Sep 2009 11:18:21 -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 n89IIq3Q004988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2009 14:18:52 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-Reply-To: <20090909170956.A5AA46BE61A@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, 9 Sep 2009 14:18:51 -0400 References: <20090909170956.A5AA46BE61A@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 18:18:50 -0000 On Sep 9, 2009, at 1:09 PM, Noel Chiappa wrote: > > AFAIK, we haven't discussed/considered here the "map-data ... > piggybacked on a > Map-Request packet" stuff at all. As Noel said, this is not the attack I was discussing before. This is a different potential avenue for attacking LISP. I was thinking about this one last night, and I don't think that we can allow ETRs to cache map "replies" contained in the map requests they receive, unless they can verify somehow that the map reply information in the packet contains the valid ETR for the indicated EID prefix. Margaret From jnc@mercury.lcs.mit.edu Wed Sep 9 11:19: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 2597C3A696F for ; Wed, 9 Sep 2009 11:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 r9qeTMyWVHqf for ; Wed, 9 Sep 2009 11:19: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 4545F3A694E for ; Wed, 9 Sep 2009 11:19:53 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7552B6BE61E; Wed, 9 Sep 2009 14:20:25 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090909182025.7552B6BE61E@mercury.lcs.mit.edu> Date: Wed, 9 Sep 2009 14:20:25 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 18:19:54 -0000 > From: Margaret Wasserman >> Remember these map replies will be > rate limited > I realize that the LISP spec says that the sender should rate limit > its replies, but attackers don't typically follow that sort of > advice. Umm, he was referring to rate-limiting in the destination ITR, not in the sources: >> The key isn't the access link speed, it's the capacity of the >> control plane of the ITR and the rate limiting mechanisms into the >> control plane. This will result in a _few hundred_ packets per >> second of map-replies being the maximum allowed by the implementation. Most control-planes have rate-limiting mechanisms built into them (actually, into the forwarding-plane -> control-plane transfer mechanisms, in many cases) to prevent a variety of DoS attacks using large amounts of traffic. Noel From jnc@mercury.lcs.mit.edu Wed Sep 9 11:29: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 7F2F63A67E2 for ; Wed, 9 Sep 2009 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 dEZbNwNHY4ET for ; Wed, 9 Sep 2009 11:29:11 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id B266B3A659C for ; Wed, 9 Sep 2009 11:29:11 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6D7936BE621; Wed, 9 Sep 2009 14:29:44 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090909182944.6D7936BE621@mercury.lcs.mit.edu> Date: Wed, 9 Sep 2009 14:29:44 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 18:29:12 -0000 > From: Margaret Wasserman > I don't think that we can allow ETRs to cache map "replies" > contained in the map requests they receive, unless they can verify > somehow that the map reply information in the packet contains the > valid ETR for the indicated EID prefix. Well, the exact same analysis (and mechanisms) as for 'user-data traffic gleaning' apply here; i.e. you ignore it if you already have a verified binding; you mark it 'provisional' if you don't already have a binding, and request a verified binding; etc. (And apologies for treating a separate problem in the same thread - or do security issues with both kinds of 'gleaning' fall under the same rubric? If not, maybe the tracker-wizards can open a new one?) Really, I do feel that there are more important things to worry about, such as the one I referred to in a prior post, i.e. 'does this mechanism really provide no-binding-lookup delays at large-content-providers'? (Yet another tracker issue?) My concern relates to sites which are served by groups of xTRs, and making sure bindings get distributed to the right one(s). Although perhaps there is a mechanism to deal with my concerns, and I just haven't read the right document yet. Noel From mrw@sandstorm.net Wed Sep 9 11:47: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 422843A6B64 for ; Wed, 9 Sep 2009 11:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 hcorNgL4LT1p for ; Wed, 9 Sep 2009 11:47:50 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id ED1273A68DE for ; Wed, 9 Sep 2009 11:47:49 -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 n89Im1Ss006661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2009 14:48:01 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090909182944.6D7936BE621@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, 9 Sep 2009 14:48:01 -0400 References: <20090909182944.6D7936BE621@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 18:47:51 -0000 On Sep 9, 2009, at 2:29 PM, Noel Chiappa wrote: > > (And apologies for treating a separate problem in the same thread - > or do > security issues with both kinds of 'gleaning' fall under the same > rubric? If > not, maybe the tracker-wizards can open a new one?) If we can place some limits on "gleaned" mappings that resolve the issues we've raised, those same limits would probably apply to mappings that are "gleaned" at the other end by being passed in map replies. So, I don't care if this is one issue or two, as long as we understand the limits needed in both places. Margaret From darlewis@cisco.com Wed Sep 9 12:18: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 3F0373A68AF for ; Wed, 9 Sep 2009 12:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 UT8GhodVUt3V for ; Wed, 9 Sep 2009 12:18:48 -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 937023A6932 for ; Wed, 9 Sep 2009 12:18:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAL+cp0qrR7O6/2dsb2JhbADGTohDAZBaBYQY X-IronPort-AV: E=Sophos;i="4.44,359,1249257600"; d="scan'208";a="239486365" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 09 Sep 2009 19:18:46 +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 n89JIkjr020957; Wed, 9 Sep 2009 12:18:46 -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 n89JIkiu022974; Wed, 9 Sep 2009 19:18:46 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); Wed, 9 Sep 2009 12:18:46 -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, 9 Sep 2009 12:18:46 -0700 Message-ID: In-Reply-To: <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] 32-bit nonce in map request insufficient Thread-Index: AcoxeaSEzxPFipVpRDyXCFc0ytxR+wACGsrQ References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> From: "Darrel Lewis (darlewis)" To: "Margaret Wasserman" X-OriginalArrivalTime: 09 Sep 2009 19:18:46.0403 (UTC) FILETIME=[5A4DAD30:01CA3182] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=883; t=1252523926; x=1253387926; 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]=2032-bit=20nonce=20in=20map=20re quest=20insufficient |Sender:=20; bh=sUQzz0hE3QfEGmaOATNyo6TXoY3YMvEjVcm0HHefjFQ=; b=R+hsnWeAaXkTU6IOMXK81AjOGcGU/X6WatqiiKvJYl30mOKDx2Jj4trdD3 IFU/4VvBHk8vGu4jf3OiFxipByk2ejbOaJ9/V6s/j+gCtnxtaSmLZ94LltyQ RuppsiV36O; Authentication-Results: sj-dkim-2; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 19:18:50 -0000 =20 >=20 > Hi Darrel, >=20 > On Sep 9, 2009, at 12:06 PM, Darrel Lewis (darlewis) wrote: > > > > A bunch, as in several thousand? Remember these map replies will be > > rate limited, and the fact that they have incorrect nonce's logged. >=20 > In the attack we are describing, "these map replies" are=20 > being sent by =20 > an attacker (possibly from multiple remote ETRs) to insert a spoofed =20 > map-cache entry in an ITR. I realize that the LISP spec says=20 > that the =20 > sender should rate limit its replies, but attackers don't typically =20 > follow that sort of advice. >=20 These map replies are rate limited by the receiving ITR, either specifically by LISP, or more genreally by such mechanisms as Control Plane Policing, not by the attacker. I'm not relying or expecting on the attacker following the specification's behavior. -Darrel From mrw@sandstorm.net Wed Sep 9 13:37: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 8E7E13A6861 for ; Wed, 9 Sep 2009 13:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 KNnX0H2mnCWX for ; Wed, 9 Sep 2009 13:37:36 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id A8A3F3A69DF for ; Wed, 9 Sep 2009 13:37:36 -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 n89KbLt5011104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2009 16:37:21 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <44B4743A-32FA-401E-99BB-A026A6059243@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: Wed, 9 Sep 2009 16:37:20 -0400 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 20:37:37 -0000 On Sep 9, 2009, at 3:18 PM, Darrel Lewis (darlewis) wrote: >> Hi Darrel, >> >> On Sep 9, 2009, at 12:06 PM, Darrel Lewis (darlewis) wrote: >>> >>> A bunch, as in several thousand? Remember these map replies will be >>> rate limited, and the fact that they have incorrect nonce's logged. >> >> In the attack we are describing, "these map replies" are >> being sent by >> an attacker (possibly from multiple remote ETRs) to insert a spoofed >> map-cache entry in an ITR. I realize that the LISP spec says >> that the >> sender should rate limit its replies, but attackers don't typically >> follow that sort of advice. >> > > These map replies are rate limited by the receiving ITR, either > specifically by LISP, or more genreally by such mechanisms as Control > Plane Policing, not by the attacker. I'm not relying or expecting on > the > attacker following the specification's behavior. As I mentioned in private mail... If the security of LISP depends on ITRs doing this sort of rate limiting, we should make sure to mention this in the security considerations section. Personally, though, I think that it would be better to just increase the nonce size to 64-bits. Then we will quickly go from quibbling about whether it takes days, weeks or months to break the nonce-based security to all agreeing that it would take longer than the expected market lifetime of silicon-based chips... I really don't see that using a 64-bit nonce in control-plane packets has any significant cost. Margaret From darlewis@cisco.com Wed Sep 9 14:31: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 2796528B23E for ; Wed, 9 Sep 2009 14:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 mhmZDR4YK3gh for ; Wed, 9 Sep 2009 14:31:38 -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 3A3373A67B8 for ; Wed, 9 Sep 2009 14:31:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADe7p0qrR7MV/2dsb2JhbADGC4hDAZBaBYQY X-IronPort-AV: E=Sophos;i="4.44,360,1249257600"; d="scan'208";a="239555414" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Sep 2009 21:32:11 +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 n89LWB5h030699; Wed, 9 Sep 2009 14:32:11 -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 n89LWBjC009686; Wed, 9 Sep 2009 21:32:11 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); Wed, 9 Sep 2009 14:32:11 -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, 9 Sep 2009 14:32:03 -0700 Message-ID: In-Reply-To: <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] 32-bit nonce in map request insufficient Thread-Index: AcoxjWxusCDqs07QRKyakRT5oXQnTgAB05bA References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> From: "Darrel Lewis (darlewis)" To: "Margaret Wasserman" X-OriginalArrivalTime: 09 Sep 2009 21:32:11.0308 (UTC) FILETIME=[FD993EC0:01CA3194] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=622; t=1252531931; x=1253395931; 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]=2032-bit=20nonce=20in=20map=20re quest=20insufficient |Sender:=20; bh=QNdwpllpXUXSCTUTZscZD3oGCEc6IV33/1W+MUDcmQw=; b=AEHuGRm/ZIfXZ6yTFny86OQkskyibKxnmBuY4NUrBO5pKXvHoqSFlTa3oA wqSXpczLMTi8JewQ8QoQIoB5v1OXptvaIjKyTQO/NyHTLHI5YtHNazccOJGw CosxGcF+Yzdpi2i1dGXqAYQGhfYD36THC81frmv2m3n+a9Bgb3veI=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 21:31:39 -0000 he specification's behavior. >=20 > As I mentioned in private mail... If the security of LISP=20 > depends on =20 > ITRs doing this sort of rate limiting, we should make sure to=20 > mention =20 > this in the security considerations section. Margaret, the security considerations section in draft-ietf-lisp-03 says, in part: 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. Do you think this is sufficient? If not, can you propose further text? -Darrel From jmh@joelhalpern.com Wed Sep 9 14:45: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 B75E73A68A3 for ; Wed, 9 Sep 2009 14:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=-0.244, 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 PcUXmLRhWqzy for ; Wed, 9 Sep 2009 14:45:29 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id CC6453A67AA for ; Wed, 9 Sep 2009 14:45:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 7549432317A6; Wed, 9 Sep 2009 14:46:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-12.clppva.btas.verizon.net [71.161.50.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id A34F932316BD; Wed, 9 Sep 2009 14:46:02 -0700 (PDT) Message-ID: <4AA82219.6030409@joelhalpern.com> Date: Wed, 09 Sep 2009 17:46:01 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Darrel Lewis (darlewis)" References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org, Noel Chiappa , Margaret Wasserman Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 21:45:31 -0000 At the very least, I would think it needs to indicate that rate limiting should apply to both the generation and the processing of such messages. Yours, Joel Darrel Lewis (darlewis) wrote: > he specification's behavior. >> As I mentioned in private mail... If the security of LISP >> depends on >> ITRs doing this sort of rate limiting, we should make sure to >> mention >> this in the security considerations section. > > Margaret, the security considerations section in draft-ietf-lisp-03 > says, in part: > > 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. > > Do you think this is sufficient? If not, can you propose further text? > > -Darrel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Wed Sep 9 16: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 EEA483A69F9 for ; Wed, 9 Sep 2009 16:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 jEuYk7bYba48 for ; Wed, 9 Sep 2009 16:17:29 -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 1E4F13A69EE for ; Wed, 9 Sep 2009 16:17:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABDUp0qrR7MV/2dsb2JhbADFfIhDAZBmBYQY X-IronPort-AV: E=Sophos;i="4.44,360,1249257600"; d="scan'208";a="203194713" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Sep 2009 23:18:02 +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 n89NI2L0015291 for ; Wed, 9 Sep 2009 16:18:02 -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 n89NI26q012568 for ; Wed, 9 Sep 2009 23:18:02 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, 9 Sep 2009 16:18:02 -0700 Received: from [192.168.1.2] ([10.21.125.164]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 16:17:59 -0700 Message-Id: <2585D442-ADAC-44BC-8084-933CB6B5B71E@cisco.com> From: Dino Farinacci 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 v936) Date: Wed, 9 Sep 2009 16:17:59 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Sep 2009 23:17:59.0482 (UTC) FILETIME=[C567B9A0:01CA31A3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=458; t=1252538282; x=1253402282; 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:=20We=20have=20converged=20on=2064=20bits! |Sender:=20; bh=bS6VHdcRLgMY5Y/Sg8Qw6zKkRWAG0/m/Or+H6axKBFs=; b=ac1WNQ82xL73MyfQA8X9jz3NUdEYoKq3f/lXiPsNJteDpdOCz2PRhXpcGJ uV2Ou7n9Di1Fdo7OkKMpGy1+JBuW7wkwqeIvjZ/hneBYxQ2P2s8ziO34I8XB Xba81xbtF1Lr07/O4OpSfzZ7ALBTb97igOCNJ/K+l+zsD3UEM88zc=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [lisp] We have converged on 64 bits! X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 23:17:30 -0000 Like many have said, it doesn't matter if the attack can happen or not. Making the change of the *control* nonce from 32-bits to 64-bits is an easy enough change. I consulted with many of the advocates and opposers to the 64-bit nonce and we have converged on changing from 32 to 64. I hope no one else has a problem with this action. I will post the Wed diff file in another email with the change to reflect this action. Thanks, Dino From dino@cisco.com Wed Sep 9 16:29: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 9D1503A69DB for ; Wed, 9 Sep 2009 16:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh9npmNME9MM for ; Wed, 9 Sep 2009 16:29:07 -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 3023D3A689E for ; Wed, 9 Sep 2009 16:29:07 -0700 (PDT) X-Files: rfcdiff-lisp-03-to-04.html, draft-ietf-lisp-04.txt : 167298, 150289 X-IronPort-AV: E=Sophos;i="4.44,360,1249257600"; d="txt'?html'217?scan'217,208,217";a="93835607" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 09 Sep 2009 23:29: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 n89NTeTC028643 for ; Wed, 9 Sep 2009 16:29: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 n89NTeNQ000189 for ; Wed, 9 Sep 2009 23:29: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); Wed, 9 Sep 2009 16:29:39 -0700 Received: from [192.168.1.2] ([10.21.125.164]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 16:29:38 -0700 Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-18--646128056 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Sep 2009 16:29:38 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Sep 2009 23:29:39.0178 (UTC) FILETIME=[6674DCA0:01CA31A5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=325410; t=1252538980; x=1253402980; 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:=20Wednesday=20updated=20diff=20file=20for=20the=2 0lisp-04=20proposed=20changes |Sender:=20; bh=1tdTLMlfLymNhxQRTq+ernr3mMFdpstdmcRrwNwXzB8=; b=Nu7OXGoYWhKy4U0Ks8srywfeqKNcCPoOqaJsULaVe+HgC5rPX+qMYBwxtS Fhiric1PfWKsXqnJehe451kv+6DUze7aNvky2zIlM4NuXg+2tBaRPrSMAgGy tUSgC1N14m; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [lisp] Wednesday updated diff file for the lisp-04 proposed changes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 23:29:07 -0000 --Apple-Mail-18--646128056 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Here is today's diff file. The only change from the Tuesday diff file is to change the 32-bit nonce length from the Map-Request, Map-Reply, and Map-Register messages to 64-bits in length. Thanks, Dino/Dave/Darrel/Vince --Apple-Mail-18--646128056 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 13, 2010                                         D. Lewis
                                                           cisco Systems
                                                           July 27,
                                                       September 9, 2009

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

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 13, 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 36
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 36 37
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 38 39
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 39 41
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 40 42
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 40 43
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 41 44
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 43 46
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 44 47
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 45 48
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 45 48
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 46 49
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 47 50
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 51
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 51
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 48 51
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 50 53
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 50 53
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 53
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 53
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 52 55
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 52 55
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 54 57
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 55 58
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 56 59
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 62
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 59 62
     14.2. Informative References . . . . . . . . . . . . . . . . . . 60 63
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 63 66
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 67

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 statically 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 prepends 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
      statically 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 prepends 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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

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

   OH

   Outer 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 the ETR. packet for decapsulation.
      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 decapsulation, otherwise, it is silently dropped.
      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

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

   LISP Locator Reach Bits:  in the LISP header are nonce-present bit.  When this bit is set by an ITR to
      indicate to an ETR 1, the reachability
      low-order 24-bits of the Locators in first 32-bits of the source
      site.  Each RLOC in LISP header contains
      a Map-Reply Nonce.  See section Section 6.3.1 for details.

   L: this is assigned an ordinal value from
      0 the Locator-Status-Bits field enabled bit.  When this bit
      is 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.

   E: this is the echo-nonce-request bit.  When a this bit is set to 1,
      the ITR is
      indicating to the ETR the RLOC associated with the N bit ordinal is
      reachable.  See Section 6.3 for details on how an ITR can
      determine other ITRs at the site are reachable.  When a site must be 1.  This bit should be ignored and 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 the mapping for the
      EID-prefix that the inner-header source EID address matches.

   S: this is no
      meaning when the Solicit-Map-Request (SMR) bit.  See section
      Section 6.5.2 for details.

   E: this N bit is the echo-nonce-request bit. 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
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from the IH header Type of
      Service field (with 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 least
      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 outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

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

   When doing Re-encapsulated Tunneling:

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

   o  The new OH outer header Type of Service field SHOULD be copied from
      the stripped OH header Type of Service field (with one caveat, see
      below)..
      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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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 Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record count.

   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 Count.
      For this version of the "Originating protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  An 8-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.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request, it may
   originate a "verifying Map-Request", addressed to the original ITR.
   If the ETR has a map-cache entry that matches the "piggybacked" EID
   and the RLOC is in the locator-set for the entry, then it may send
   the "verifying Map-Request" to the original Map-Request source.  If
   not, then it MUST send it to the "piggybacked" EID.  Doing this
   forces the "verifying Map-Request" to go through the mapping database
   system to reach the authoritative source of information about that
   EID, guarding against RLOC-spoofing in in the "piggybacked" 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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
      advertising that the site 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  An 8-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: this bit is reserved for use by the LISP mobile-node design
      documented in [LISP-MN].

   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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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  This 8-byte 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, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply and or that stored in the database
   mapping service does not database system provide any reachability status information for Locators.  This is done outside RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the mapping service.  See Routing Locator Reachability Algorithms described in the
   next section for details. section.

6.3.  Routing Locator Reachability

   There are 4 methods

   Several mechanisms for determining when a Locator is either
   reachable or has become unreachable:

   1.  Locator RLOC reachability is determined by an are currently
   defined:

   1.  An ETR by examining may examine the Loc-Status-Bits in the
       Loc-Reach-Bits from a LISP header of a an
       encapsulated data packet
       which received from an ITR.  If the ETR is provided by
       also acting as an ITR when an and has traffic to return to the original
       ITR encapsulates data.

   2.  Locator unreachability is determined by site, it can use this status information to help select an
       RLOC.

   2.  An ITR by receiving may receive an ICMP Network or ICMP Host Unreachable messages.
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  Locator unreachability  An ITR which participates in the global routing system can also be determined by
       determine that an BGP-enabled
       ITR when there RLOC is down if no prefix matching a Locator address from the BGP RIB. RIB route exists that
       matches the RLOC IP address.

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

   5.  Locator reachability is determined by receiving  An ITR may receive a Map-Reply
       message from a ETR's Locator address ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  Locator reachability can also be determined by receiving packets  When an ETR receives an encapsulated by packet from an ITR, the ITR assigned to
       source RLOC from the locator address. outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   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 an encapsulating ITR closest to the Locators about
   reachability for all ETRs at the source site.  The  CE-based ITRs at the source
   site can determine reachability when running their
   IGP at the site.  When relative to each other using the ITRs are deployed on CE routers, typically site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route is injected into the site's IGP from each of the
   ITRs. site IGP.

   o  If an ITR goes down, the CE-PE link goes down, fails or if the upstream link to its PE
   router goes down, the CE router withdraws the fails, its
      default route.  This
   allows route will either time-out or be withdrawn.

   Each ITR can thus observe the other ITRs at presence or lack of a default route
   originated by the site others to determine one of the Locators
   has gone unreachable.

   The Locators Locator Status Bits it sets
   for them.

   RLOCs 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 encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit numbered as 0.  So,
   for bit.  For example, if the ITR with locator an RLOC
   listed as in the 3rd Locator position in of the Map-Reply goes down, down (ordinal value
   2), then all other ITRs at the site will
   have clear the 3rd least significant
   bit from (xxxx x0xx) of the right cleared (the bit that corresponds to
   ordinal 2). Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will look check for a any change in
   the
   Loc-Reach-Bits value. Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to the Locator an RLOC that has just gone
   unreachable. is indicated as
   down.  It can start will only resume using the Locator again when the bit that
   corresponds to RLOC if the Locator goes from 0 corresponding Loc-
   Status-Bit returns to a value of 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 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.

   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 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
   reachability problem as traffic may be unidirectional.  That is, to a specific locator is
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator from the
   ETR receiving traffic at cached
   locator.  RLOC Probing can also provide RTT estimates between a site may not may not pair
   of locators which can be the same device useful for network management purposes as
   an ITR which transmits traffic from that site or
   well as for selecting low delay paths.  The major disadvantage of
   RLOC Probing is in the site number of control messages required and the
   amount of bandwidth used to site
   traffic is unidirectional so there is no ITR returning traffic.

   Note that other locator reachability mechanisms obtain those benefits, especially if the
   requirement for failure detection times are being researched very small.

   Continued research and can be used testing will attempt to compliment or even override characterize the Echo Nonce
   Algorithm.
   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.

   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 more secure to reach an authoritative ETR,
   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 24-bit Nonce field in the LISP encapsulation header. header and a
   64-bit Nonce field in the LISP control message.  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 have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   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,  Two are the Echo-Noncing and
        RLOC-Probing algorithms which is are documented in this
        specification.  The other two are third is 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.

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

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.

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, Sam Hartman, Michael Hofling, and Pedro Marques.

   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-18--646128056 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-18--646128056 Content-Disposition: attachment; filename=draft-ietf-lisp-04.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-04.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: March 13, 2010 D. Lewis cisco Systems September 9, 2009 Locator/ID Separation Protocol (LISP) (PROPOSED) draft-ietf-lisp-04.txt (NOT SUBMITTED) 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 March 13, 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. Farinacci, et al. Expires March 13, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 . . . . . . . . . . . . . . . . 36 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 37 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 39 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 41 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 42 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 43 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 44 7. Router Performance Considerations . . . . . . . . . . . . . . 46 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 47 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 48 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 48 Farinacci, et al. Expires March 13, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 49 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 50 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 51 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 51 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 51 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 53 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 53 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 55 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 55 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 57 12. Security Considerations . . . . . . . . . . . . . . . . . . . 58 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 59 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 14.1. Normative References . . . . . . . . . . . . . . . . . . . 62 14.2. Informative References . . . . . . . . . . . . . . . . . . 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 Farinacci, et al. Expires March 13, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 13, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 13, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 13, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 13, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 statically 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 prepends 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 statically configured. Farinacci, et al. Expires March 13, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 prepends 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 Farinacci, et al. Expires March 13, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 13, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | | Farinacci, et al. Expires March 13, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer 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 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 MAY be transmitted as zero by an ITR and when received by an ETR, MUST accept the packet for decapsulation. 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 decapsulation, 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. 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. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See section Section 6.3.1 for details. Farinacci, et al. Expires March 13, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. E: this is the echo-nonce-request bit. When this bit is set to 1, the N bit must be 1. 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. rflags: this 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 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. When the E-bit is clear but the N-bit is set, an ITR is either echoing a previously requested echo-nonce or providing a random nonce. See section Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least 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 outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Type of Service field (with one caveat, see below). When doing Re-encapsulated Tunneling: Farinacci, et al. Expires March 13, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer 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: Farinacci, et al. Expires March 13, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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 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 Farinacci, et al. Expires March 13, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires March 13, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 | | + 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. Farinacci, et al. Expires March 13, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D1 |A|M|P|S| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . 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: Farinacci, et al. Expires March 13, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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 Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: An 8-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 Farinacci, et al. Expires March 13, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request, it may originate a "verifying Map-Request", addressed to the original ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map-Request" to the original Map-Request source. If Farinacci, et al. Expires March 13, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 not, then it MUST send it to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" 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=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | 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. See section Section 6.3.2 for more details. Farinacci, et al. Expires March 13, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 E: Indicates that the ETR which sends this Map-Reply message is advertising that the site 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: An 8-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. 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. Farinacci, et al. Expires March 13, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 M: this bit is reserved for use by the LISP mobile-node design documented in [LISP-MN]. 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. Farinacci, et al. Expires March 13, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 13, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 [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 [RFC4302] is: Farinacci, et al. Expires March 13, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 SHA-1 or SHA-128 HMAC. The Map-Register message format is: Farinacci, et al. Expires March 13, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D3 |P| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | 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: This 8-byte 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. Farinacci, et al. Expires March 13, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o A "gleaned" map-cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. Farinacci, et al. Expires March 13, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the 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 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 Farinacci, et al. Expires March 13, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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 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 Farinacci, et al. Expires March 13, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 nonce echo, it sets the 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 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 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. 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. Farinacci, et al. Expires March 13, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 obtain those benefits, especially if the 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. Farinacci, et al. Expires March 13, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 13, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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-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-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-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. Farinacci, et al. Expires March 13, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the 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 ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- prefix uses is the one copied from the SMR 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 Farinacci, et al. Expires March 13, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 the loc-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending 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 more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. Farinacci, et al. Expires March 13, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 13, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, Farinacci, et al. Expires March 13, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 13, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 13, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 13, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 13, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. 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. Farinacci, et al. Expires March 13, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Interoperable implementations have been available since the beginning of 2009. We are trying to converge on a packet format so implementations can converge on the -04 and later drafts. 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. Farinacci, et al. Expires March 13, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 13, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts 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. Farinacci, et al. Expires March 13, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. [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, Farinacci, et al. Expires March 13, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 September 2007. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 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. Farinacci, et al. Expires March 13, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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-02.txt (work in progress), 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. Farinacci, et al. Expires March 13, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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. Farinacci, et al. Expires March 13, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, and Pedro Marques. 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. Farinacci, et al. Expires March 13, 2010 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 13, 2010 [Page 67] =0C --Apple-Mail-18--646128056 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-18--646128056-- From tme@americafree.tv Wed Sep 9 16:50: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 12A633A6A4D for ; Wed, 9 Sep 2009 16:50:41 -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 DVv23MiIC4yK for ; Wed, 9 Sep 2009 16:50:40 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 332393A6A41 for ; Wed, 9 Sep 2009 16:50:40 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 477A04B08880; Wed, 9 Sep 2009 19:51:13 -0400 (EDT) Message-Id: From: Marshall Eubanks 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 v936) Date: Wed, 9 Sep 2009 19:51:12 -0400 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Wednesday updated diff file for the lisp-04 proposed changes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 09 Sep 2009 23:50:41 -0000 One thing in 5.3 : UDP Checksum: this field MAY be transmitted as zero by an ITR and when received by an ETR, MUST accept the packet for decapsulation. There is something missing here, how about when received by an ETR, the ETR MUST accept the packet for decapsulation. 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 decapsulation, otherwise, it is silently dropped. I would do s/decapsulation,/decapsulation;/ but that is truly a nit. 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. On Sep 9, 2009, at 7:29 PM, Dino Farinacci wrote: > Here is today's diff file. The only change from the Tuesday diff > file is to change the 32-bit nonce length from the Map-Request, Map- > Reply, and Map-Register messages to 64-bits in length. > > Thanks, > Dino/Dave/Darrel/Vince > > > > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From mrw@sandstorm.net Wed Sep 9 17:00: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 DB1D23A6887 for ; Wed, 9 Sep 2009 17:00: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 OM9Pg0HFkGyl for ; Wed, 9 Sep 2009 17:00:32 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 030043A67F4 for ; Wed, 9 Sep 2009 17:00:31 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8A00jxn017845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2009 20:00:45 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <5130788F-962A-4DBA-AC88-E5F6B78849F9@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: Wed, 9 Sep 2009 20:00:44 -0400 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 00:00:32 -0000 Hi Darrel, On Sep 9, 2009, at 5:32 PM, Darrel Lewis (darlewis) wrote: > he specification's behavior. >> >> As I mentioned in private mail... If the security of LISP >> depends on >> ITRs doing this sort of rate limiting, we should make sure to >> mention >> this in the security considerations section. > > Margaret, the security considerations section in draft-ietf-lisp-03 > says, in part: > > 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. I thought that this text was talking about implementations rate limiting what they transmit, but I now see that it says "to the control plane". I'm not sure if there is a clearer way to say this that would have avoided my misunderstanding... Maybe "The prevention of DoS and map-cache spoofing attacks will depend on implementations rate limiting the number of control packets that are received and processed by their data plane."? I am also not sure what "data-triggered Map-Replies" are. Did you mean "data-triggered Map-Requests"? Margaret From mrw@sandstorm.net Wed Sep 9 17:02: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 CA8223A67F4 for ; Wed, 9 Sep 2009 17:02:12 -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 teCox8G3+CAx for ; Wed, 9 Sep 2009 17:02:12 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 081383A6887 for ; Wed, 9 Sep 2009 17:02:11 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8A02gnk017950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2009 20:02:42 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <2585D442-ADAC-44BC-8084-933CB6B5B71E@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, 9 Sep 2009 20:02:41 -0400 References: <2585D442-ADAC-44BC-8084-933CB6B5B71E@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] We have converged on 64 bits! X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 00:02:12 -0000 Thanks, Dino! This resolves my issue that has been using the subject "32-bit nonce in map request insufficient". I don't think there has been an issue opened for it yet, but if it has been opened, this closes it, IMO. Margaret On Sep 9, 2009, at 7:17 PM, Dino Farinacci wrote: > Like many have said, it doesn't matter if the attack can happen or > not. Making the change of the *control* nonce from 32-bits to 64- > bits is an easy enough change. > > I consulted with many of the advocates and opposers to the 64-bit > nonce and we have converged on changing from 32 to 64. > > I hope no one else has a problem with this action. I will post the > Wed diff file in another email with the change to reflect this action. > > Thanks, > Dino > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From mrw@sandstorm.net Wed Sep 9 17:19: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 791EC3A69EE for ; Wed, 9 Sep 2009 17:19:53 -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 IcZcVugykVEj for ; Wed, 9 Sep 2009 17:19:52 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 8690C3A69A7 for ; Wed, 9 Sep 2009 17:19:52 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8A0KMSo018354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2009 20:20:22 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <51619D2E-0A54-42B8-90CA-1579DF71B2DE@sandstorm.net> From: Margaret Wasserman To: Margaret Wasserman In-Reply-To: <5130788F-962A-4DBA-AC88-E5F6B78849F9@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, 9 Sep 2009 20:20:22 -0400 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <5130788F-962A-4DBA-AC88-E5F6B78849F9@sandstorm.net> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 00:19:53 -0000 On Sep 9, 2009, at 8:00 PM, Margaret Wasserman wrote: >> >> 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. > > I thought that this text was talking about implementations rate > limiting what they transmit, but I now see that it says "to the > control plane". I'm not sure if there is a clearer way to say this > that would have avoided my misunderstanding... Maybe "The > prevention of DoS and map-cache spoofing attacks will depend on > implementations rate limiting the number of control packets that are > received and processed by their data plane."? s/data plane./control plane. Margaret From mrw@sandstorm.net Wed Sep 9 17:52: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 B38883A6A8C for ; Wed, 9 Sep 2009 17:52:20 -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 FV4CGgtq6Wg8 for ; Wed, 9 Sep 2009 17:52:20 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id D2F203A6889 for ; Wed, 9 Sep 2009 17:52:19 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8A0qcu1019235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2009 20:52:39 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@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, 9 Sep 2009 20:52:37 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> X-Mailer: Apple Mail (2.935.3) 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: Thu, 10 Sep 2009 00:52:20 -0000 Hi Dino, On Sep 1, 2009, at 11:40 AM, Dino Farinacci wrote: >> My personal preferences are >> >> 1) Joel's text with Margaret's updates saying receivers SHOULD >> verify checksums >> 2) Joel's text with typo corrections >> 3) Margaret's short text above with the additional of "LISP ITRs >> MAY send a zero checksum" >> 4) Margaret's text in the thread about closing issues #9, #10 and >> #12 > > How about Joel and Margaret get together and write the text and I > will include it. Provided it is detailed and accurate enough. Joel's > text was not specific enough to implement from. Joel and I came up with the following text: UDP Checksum: An ITR MAY set this field to 0 in both IPv4 and IPv6 outer headers [RFC 768, UDP-TUNNEL]. If the ITR does not set this field to 0, it MUST be set to a valid UDP checksum value. Upon receipt, an ETR MUST accept IPv4 and IPv6 packets with an outer header UDP checksum of 0, and process them normally. If an ETR receives a packet with a non-zero value in the UDP checksum field, it MAY choose to ignore the UDP checksum value, and treat the packet as if it had a 0 checksum. If it an ETR does compute the received UDP checksum, it SHOULD discard packets with invalid non-zero UDP checksums. If anyone has concerns about this text, please let us know. Margaret From christopher.morrow@gmail.com Wed Sep 9 20:33: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 3AD4F3A6848 for ; Wed, 9 Sep 2009 20:33: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=[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 0KSBfKFy5s8D for ; Wed, 9 Sep 2009 20:33:07 -0700 (PDT) Received: from mail-qy0-f171.google.com (mail-qy0-f171.google.com [209.85.221.171]) by core3.amsl.com (Postfix) with ESMTP id 30DEB3A67ED for ; Wed, 9 Sep 2009 20:33:07 -0700 (PDT) Received: by qyk1 with SMTP id 1so470667qyk.22 for ; Wed, 09 Sep 2009 20:33:38 -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=36yu7LgIeTVxof+ks+0ivtaSrLsOmRH2KoHMwB51EiM=; b=RSO2SIlFzkIl5SDA7Wa6+GDkpdSsc0314YYX+1I4zMThegVVjvRv/NKR+LinrSUdXx oVFmwEk2gQ6WM4flIeLHNHmOeth15Q2JwRwQ9MmM1Tir7PZQh7u1XbyDH/iiK9semeLW hax5T26ScXMqGcWdYsjkTJEzF3pTpbd2TqOnw= 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=FQPClJkY6q29Ywra41HsJMsIbDH/6YAOoGePeOMRdenjBUYPHLkxl2SSgceoWXDEii dEPoLn8aEFCu/3gRXIiDxwZxfMFw9XhdNfnyqHumf8piGJ8fdG7DH33T7j1St0WFyr5w YN3Dl3/S2CPUdSadiWUp6NpWXLD3mVjXJqzw0= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.50.11 with SMTP id x11mr954517qaf.248.1252553618272; Wed, 09 Sep 2009 20:33:38 -0700 (PDT) In-Reply-To: <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> Date: Wed, 9 Sep 2009 23:33:38 -0400 X-Google-Sender-Auth: a6890ad44e79bb53 Message-ID: <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> From: Christopher Morrow 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] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 03:33:08 -0000 On Wed, Sep 9, 2009 at 4:37 PM, Margaret Wasserman wrote= : > > On Sep 9, 2009, at 3:18 PM, Darrel Lewis (darlewis) wrote: >>> >>> Hi Darrel, >>> >>> On Sep 9, 2009, at 12:06 PM, Darrel Lewis (darlewis) wrote: >>>> >>>> A bunch, as in several thousand? =A0Remember these map replies will be >>>> rate limited, and the fact that they have incorrect nonce's logged. >>> >>> In the attack we are describing, "these map replies" are >>> being sent by >>> an attacker (possibly from multiple remote ETRs) to insert a spoofed >>> map-cache entry in an ITR. =A0I realize that the LISP spec says >>> that the >>> sender should rate limit its replies, but attackers don't typically >>> follow that sort of advice. >>> >> >> These map replies are rate limited by the receiving ITR, either >> specifically by LISP, or more genreally by such mechanisms as Control >> Plane Policing, not by the attacker. I'm not relying or expecting on the >> attacker following the specification's behavior. > > As I mentioned in private mail... =A0If the security of LISP depends on I= TRs > doing this sort of rate limiting, we should make sure to mention this in = the > security considerations section. also, please, please, please mention that making the nonce a sequential number isn't a good plan, nor is using a prng of poor quality. Let's not incur the same sets of issues TCP has had with seq#. > Personally, though, I think that it would be better to just increase the > nonce size to 64-bits. =A0Then we will quickly go from quibbling about wh= ether > it takes days, weeks or months to break the nonce-based security to all > agreeing that it would take longer than the expected market lifetime of > silicon-based chips... =A0I really don't see that using a 64-bit nonce in provided that my above note is also adhered to, if you just seq+1 to get the next nonce to use... your bit numbers are meaningless :( > control-plane packets has any significant cost. It does cost in header space, right? and potentially this cost is also in chips/hardware that may have to look more bits into a header to make a decision, though I believe the NONCE is more targetted to the RP/RE/smarts of a router than the line-card/forwarding-parts, right? -chris From mrw@sandstorm.net Wed Sep 9 20:38: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 1A52B3A68B0 for ; Wed, 9 Sep 2009 20:38:17 -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 e8m5E57bDtYv for ; Wed, 9 Sep 2009 20:38:16 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 31D9E3A68C8 for ; Wed, 9 Sep 2009 20:38:15 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8A3cc6Y026463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2009 23:38:38 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Christopher Morrow In-Reply-To: <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@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, 9 Sep 2009 23:38:37 -0400 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 03:38:17 -0000 On Sep 9, 2009, at 11:33 PM, Christopher Morrow wrote: > > also, please, please, please mention that making the nonce a > sequential number isn't a good plan, nor is using a prng of poor > quality. Let's not incur the same sets of issues TCP has had with > seq#. Yes, we need to say something about using a good source of random numbers. I think there is an RFC we can reference with advice about that, but I'll have to look up the number tomorrow. > > >> Personally, though, I think that it would be better to just >> increase the >> nonce size to 64-bits. Then we will quickly go from quibbling >> about whether >> it takes days, weeks or months to break the nonce-based security to >> all >> agreeing that it would take longer than the expected market >> lifetime of >> silicon-based chips... I really don't see that using a 64-bit >> nonce in > > provided that my above note is also adhered to, if you just seq+1 to > get the next nonce to use... your bit numbers are meaningless :( True. > > >> control-plane packets has any significant cost. > > It does cost in header space, right? and potentially this cost is also > in chips/hardware that may have to look more bits into a header to > make a decision, though I believe the NONCE is more targetted to the > RP/RE/smarts of a router than the line-card/forwarding-parts, right? Yes, we are only talking about the nonce in the control-plane packets -- map registration, map request, map reply, etc. The LISP data header currently has a 24-bit nonce, but that nonce is not the subject of this discussion. Increasing the size of the data header could have significant impact along the lines you mention, but increasing the size of the control messages should not (IMO) cause any serious issues. Margaret From christopher.morrow@gmail.com Wed Sep 9 20:41: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 A651D3A69D5 for ; Wed, 9 Sep 2009 20:41:35 -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 OqbVGrNPcOFm for ; Wed, 9 Sep 2009 20:41:29 -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 4171D3A68B4 for ; Wed, 9 Sep 2009 20:41:29 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so1533375qwi.31 for ; Wed, 09 Sep 2009 20:41:59 -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=XXJk9jjDXF9fwYOAylK1gg7fBIxxw5AzDOge6MdCvec=; b=Okjq3V5yd5c9MGZUFLIyGTFt9h2sl8A+9bl/DqmB7lPOJMY9ugpLjE2kWvnQBHV1Gn wbfid/AoSVltvRnzBrPSQRBHEx7FqRMJJN/VVol+bF/RE1s7q2pVOmD8QH4xKnI1drWZ +NhRb8eMiT7UAIyPQVUSUMmG4BUFKWWOENzxA= 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=Wv9PmOkve57hVD3GgQ5kxEGzscRDNQkcE6hwilpMyMR7YXUyZSi4d9Wc2v2lKNQ5yR KBeszH+XwionFzp5oQ8Gam1dTjOkPIOt+1onsLpiFVHna85I8IHGyxUc5oH6zgS9RMec aZfTE7yMZoPCMeSIRMmuW83rETz4HbiVwAD2U= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.93.77 with SMTP id u13mr960262qam.226.1252554118809; Wed, 09 Sep 2009 20:41:58 -0700 (PDT) In-Reply-To: References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> Date: Wed, 9 Sep 2009 23:41:58 -0400 X-Google-Sender-Auth: a119e97d03778965 Message-ID: <75cb24520909092041l3c125856u93b9c317aed3333a@mail.gmail.com> From: Christopher Morrow 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] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 03:41:36 -0000 On Wed, Sep 9, 2009 at 11:38 PM, Margaret Wasserman wrot= e: > > On Sep 9, 2009, at 11:33 PM, Christopher Morrow wrote: >> >> also, please, please, please mention that making the nonce a >> sequential number isn't a good plan, nor is using a prng of poor >> quality. Let's not incur the same sets of issues TCP has had with >> seq#. > > Yes, we need to say something about using a good source of random numbers= . > =A0I think there is an RFC we can reference with advice about that, but I= 'll > have to look up the number tomorrow. ok, cool.. perhaps it's ne related to TCP even :) >> >> >>> Personally, though, I think that it would be better to just increase th= e >>> nonce size to 64-bits. =A0Then we will quickly go from quibbling about >>> whether >>> it takes days, weeks or months to break the nonce-based security to all >>> agreeing that it would take longer than the expected market lifetime of >>> silicon-based chips... =A0I really don't see that using a 64-bit nonce = in >> >> provided that my above note is also adhered to, if you just seq+1 to >> get the next nonce to use... your bit numbers are meaningless :( > > True. I also forgot to say that... given the box will likely fall over before you hit even a 2^32 number of packets I'm not sure there's a win in 2^64. Especially if the nonce isn't very long-lived, the time to stay under the rate-limit threshold (hitting it will have other mal-effects), will be compressed so 2^32 really is quite a few packets in this context. >> >> >>> control-plane packets has any significant cost. >> >> It does cost in header space, right? and potentially this cost is also >> in chips/hardware that may have to look more bits into a header to >> make a decision, though I believe the NONCE is more targetted to the >> RP/RE/smarts of a router than the line-card/forwarding-parts, right? > > Yes, we are only talking about the nonce in the control-plane packets -- = map great, thanks. -chris From dino@cisco.com Wed Sep 9 21: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 EA6233A68E5 for ; Wed, 9 Sep 2009 21:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 gtcA9-aqPn8X for ; Wed, 9 Sep 2009 21:22:44 -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 1E1363A68C8 for ; Wed, 9 Sep 2009 21:22:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHocqEqrR7O6/2dsb2JhbADEUohDAZBfBYI7gV0 X-IronPort-AV: E=Sophos;i="4.44,361,1249257600"; d="scan'208";a="239689808" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 10 Sep 2009 04:23:17 +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 n8A4NHwx030301; Wed, 9 Sep 2009 21:23:17 -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 n8A4NHPi025035; Thu, 10 Sep 2009 04:23:17 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, 9 Sep 2009 21:23:17 -0700 Received: from [192.168.1.2] ([10.21.72.96]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 21:23:17 -0700 Message-Id: From: Dino Farinacci 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 v936) Date: Wed, 9 Sep 2009 21:23:16 -0700 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Sep 2009 04:23:17.0283 (UTC) FILETIME=[6BAA5730:01CA31CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1464; t=1252556597; x=1253420597; 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]=20Wednesday=20updated=20diff=20f ile=20for=20the=20lisp-04=20proposed=20changes |Sender:=20; bh=Z7U1QLUCUd522ftfZ4NqElyz52xfPF4rDhZcX8GNHhU=; b=PwMpPDpwkLW5EBxzLYqL19p6WFqFbxCsjWTJGbC+HHldkTc53WitSf0gjK MmNdbbpl5zvHOZOR8K1hZaCrnYpCPilKP4wqAfV5r2ZErhhAyrwxYExDbbY1 KoBqXSYHfL; 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] Wednesday updated diff file for the lisp-04 proposed changes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 04:22:45 -0000 Consider it changed Marshall. Dino On Sep 9, 2009, at 4:51 PM, Marshall Eubanks wrote: > One thing in 5.3 : > > UDP Checksum: this field MAY be transmitted as zero by an ITR and > when received by an ETR, MUST accept the packet for decapsulation. > > There is something missing here, how about > > when received by an ETR, the ETR MUST accept the packet for > decapsulation. > > 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 decapsulation, otherwise, it is silently dropped. > > I would do > s/decapsulation,/decapsulation;/ > but that is truly a nit. > > 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. > > > > > > > On Sep 9, 2009, at 7:29 PM, Dino Farinacci wrote: > >> Here is today's diff file. The only change from the Tuesday diff >> file is to change the 32-bit nonce length from the Map-Request, Map- >> Reply, and Map-Register messages to 64-bits in length. >> >> Thanks, >> Dino/Dave/Darrel/Vince >> >> >> >> >> >> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > From darlewis@cisco.com Wed Sep 9 21:25: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 46F4D3A6831 for ; Wed, 9 Sep 2009 21:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 VqvujKuA4xsY for ; Wed, 9 Sep 2009 21:25:43 -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 5AA3B3A65A6 for ; Wed, 9 Sep 2009 21:25:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAD8cqEqrR7MV/2dsb2JhbADEU4hDAZBfBYQY X-IronPort-AV: E=Sophos;i="4.44,361,1249257600"; d="scan'208";a="188642518" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 10 Sep 2009 04:26:17 +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 n8A4QH22023118; Wed, 9 Sep 2009 21:26:17 -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 n8A4QHq2026997; Thu, 10 Sep 2009 04:26:17 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); Wed, 9 Sep 2009 21:26:17 -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, 9 Sep 2009 21:26:11 -0700 Message-ID: In-Reply-To: <4AA82219.6030409@joelhalpern.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] 32-bit nonce in map request insufficient Thread-Index: AcoxlvNKYTTLZDV9SxeveP+FCzWJKwAN6MbA References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <4AA82219.6030409@joelhalpern.com> From: "Darrel Lewis (darlewis)" To: "Joel M. Halpern" X-OriginalArrivalTime: 10 Sep 2009 04:26:17.0360 (UTC) FILETIME=[D6FFE900:01CA31CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1315; t=1252556777; x=1253420777; 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]=2032-bit=20nonce=20in=20map=20re quest=20insufficient |Sender:=20; bh=rlkNKINa4jP8iYinLcN2UXUh0m+cGh8jbHcDsJ7HCCQ=; b=SPa6v2yAY6IQaN5Uqxz36EBorbum67LWXXUgtbrujc6YuTaZ7clTdDQrX4 ntYhu37esp9qXZYRO30CdT1jzjGv/QlDaqs0Czgxh3Poe8XDRUv2uCw3gOiv 1XpCR1G3/hJoUCO01jC63xHA3CWCwo5SzotmsxKWeDG7ieC+gH8lM=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org, Noel Chiappa , Margaret Wasserman Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 04:25:44 -0000 =20 >=20 > At the very least, I would think it needs to indicate that=20 > rate limiting=20 > should apply to both the generation and the processing of=20 > such messages. >=20 Thanks Joel, I'll add the language you suggest. I don't want to be too specific because such recommendations are very dependant on the device capabilities how exactly LISP is implemented.=20 -Darrel > Yours, > Joel >=20 > Darrel Lewis (darlewis) wrote: > > he specification's behavior. > >> As I mentioned in private mail... If the security of LISP=20 > >> depends on =20 > >> ITRs doing this sort of rate limiting, we should make sure to=20 > >> mention =20 > >> this in the security considerations section. > >=20 > > Margaret, the security considerations section in draft-ietf-lisp-03 > > says, in part: > >=20 > > DoS attack prevention will depend on implementations=20 > rate-limiting > > Map-Requests and Map-Replies to the control plane as=20 > well as rate- > > limiting the number of data-triggered Map-Replies. > >=20 > > Do you think this is sufficient? If not, can you propose=20 > further text? > >=20 > > -Darrel > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > >=20 >=20 From dino@cisco.com Wed Sep 9 21:49: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 8DF1F3A6892 for ; Wed, 9 Sep 2009 21:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 pi-CqaV4TRMO for ; Wed, 9 Sep 2009 21:49: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 3DA053A681A for ; Wed, 9 Sep 2009 21:49:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFYiqEqrR7PD/2dsb2JhbADEN4hDAZBiBYI7gV2BWQ X-IronPort-AV: E=Sophos;i="4.44,361,1249257600"; d="scan'208";a="239698010" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 10 Sep 2009 04:49:39 +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 n8A4ndgq000505; Wed, 9 Sep 2009 21:49:39 -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 n8A4ndgL014953; Thu, 10 Sep 2009 04:49:39 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, 9 Sep 2009 21:49:39 -0700 Received: from [192.168.1.2] ([10.21.72.96]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 21:49:38 -0700 Message-Id: <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <985F0D74-73CA-48CC-8F75-EC8C55042C81@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, 9 Sep 2009 21:49:38 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Sep 2009 04:49:39.0022 (UTC) FILETIME=[1A748EE0:01CA31D2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3867; t=1252558179; x=1253422179; 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]=20Suggested=20UDP=20checksum=20t ext |Sender:=20; bh=g9xEj94OS7o8SX+YAPVF8OBdhKCqE2AymBRR4yAwFtA=; b=Q/rvBTpYEYdJL/Z31gkWp/mH9wCoUJWIpqDRMRpDyCGDw05V+K2K6MTdkU qitdF+UTffFQ8DPAQThBk4PcMzyCcAgLe6dw7UoUKHfIybJNajG2cbCDOe3T a8mF75sKNm; 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] 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: Thu, 10 Sep 2009 04:49:06 -0000 Well I thought what we had was pretty good. I will include it below so others can compare. But see my specific comments below. > Joel and I came up with the following text: > > UDP Checksum: An ITR MAY set this field to 0 in both IPv4 and IPv6 > outer headers [RFC 768, UDP-TUNNEL]. If the ITR does First off, this first sentence is misleading. It makes one think the UDP checksum is in the IPv4 and IPv6 header or leads one to believe the checksum in the IPv4 header is part of this description. It also makes me think there are two headers by the reference to "outer headers". Talking about IPv4 and IPv6 in parallel leads to the confusion. > not set this field to 0, it MUST be set to a valid UDP > checksum value. Upon receipt, an ETR MUST accept IPv4 What is a valid UDP checksum. I didn't like that in previous text that was proposed. The checksum is a computation that is performed. That is what is placed in this field. The receiver computes a checksum to compare against this one to determine if the checksum in the packet is valid. > and IPv6 packets with an outer header UDP checksum of 0, > and process them normally. If an ETR receives a packet "process them normally" IMO is not specific enough. Unless you want to define what abnormal processing is. ;-) > with a non-zero value in the UDP checksum field, it MAY > choose to ignore the UDP checksum value, and treat the > packet as if it had a 0 checksum. If it an ETR does > compute the "If it an ETR" doesn't parse well so the text as is needs improvement. > received UDP checksum, it SHOULD discard packets with > invalid > non-zero UDP checksums. > > If anyone has concerns about this text, please let us know. Compare it to what is in the latest diff (with Marhsall's two editorial changes): UDP Checksum: this field MAY be transmitted as zero by an ITR and when received by an ETR, it MUST accept the packet for decapsulation. 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 decapsulation; 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. And let me annotate why the text is better and sufficient on a sentence by sentence basis: > UDP Checksum: this field MAY be transmitted as zero by an ITR and > when received by an ETR, it MUST accept the packet for > decapsulation. The first sentence indicates the zero checksum case. Tells you who puts it in and the level of conformance that should be placed on it. Then it says what the receiver should do and the level of conformance that should occur. > When an ITR transmits a non-zero value, an ETR MAY > verify the checksum value. If the checksum is verified, the Then the next sentence indicates what to do for non-zero values. > packet is accepted for decapsulation; otherwise, it is silently > dropped. Note, even when the UDP checksum is transmitted as > zero The third sentence indicates what happens when the checksum is good and when it is bad, for non-zero values. > an intervening NAT device can recalculate the checksum and > rewrite > the UDP checksum field to non-zero. See draft [UDP-TUNNELS] for > details. And the final sentence talks about the NAT corner case. I think we can't do better than this current text. I move to keep it the way it is. Dino From dino@cisco.com Wed Sep 9 23:53: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 B218F3A69E4 for ; Wed, 9 Sep 2009 23:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 dwgq0sz4OoDg for ; Wed, 9 Sep 2009 23:53:10 -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 A08AE3A698D for ; Wed, 9 Sep 2009 23:53:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOo/qEqrR7PD/2dsb2JhbADEJ4hDAZBVBYQY X-IronPort-AV: E=Sophos;i="4.44,362,1249257600"; d="scan'208";a="203274298" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 10 Sep 2009 06:53:33 +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 n8A6rViK001129; Wed, 9 Sep 2009 23:53:31 -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 n8A6rVCk020312; Thu, 10 Sep 2009 06:53:31 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); Wed, 9 Sep 2009 23:53:30 -0700 Received: from [192.168.1.2] ([10.21.72.96]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 23:53:30 -0700 Message-Id: <8E3B561B-4650-452E-9E51-AB53EBFACE62@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 v936) Date: Wed, 9 Sep 2009 23:53:30 -0700 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Sep 2009 06:53:30.0530 (UTC) FILETIME=[67FAB020:01CA31E3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=772; t=1252565611; x=1253429611; 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]=2032-bit=20nonce=20in=20map=20re quest=20insufficient |Sender:=20; bh=z4HdRsasyty/ESsJXlyxTeqTZwIPSao0iD2qaODfA9k=; b=IQDmBc25KS153P2r+EN4vJWC+CQcV6spEYVVSUpyHWc99bNvCC3aopHrav dwnzsedZAGis+iV6blNSlm5yk9IfvSXSHSXqCXk6c+3jR5oxh8y3tAdJxsGn T/qfFNhnFC; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 06:53:11 -0000 > On Sep 9, 2009, at 11:33 PM, Christopher Morrow wrote: >> >> also, please, please, please mention that making the nonce a >> sequential number isn't a good plan, nor is using a prng of poor >> quality. Let's not incur the same sets of issues TCP has had with >> seq#. > > Yes, we need to say something about using a good source of random > numbers. I think there is an RFC we can reference with advice about > that, but I'll have to look up the number tomorrow. Chris, how about I add this text to the spec: Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. A suggested source for good random number generation can be found in [RFC1750]. Dino From jmh@joelhalpern.com Thu Sep 10 05:53: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 130A13A67B2 for ; Thu, 10 Sep 2009 05:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.841 X-Spam-Level: X-Spam-Status: No, score=-2.841 tagged_above=-999 required=5 tests=[AWL=-0.242, 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 cv7Tm1nuDqbp for ; Thu, 10 Sep 2009 05:53:33 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 5406A3A67F8 for ; Thu, 10 Sep 2009 05:53:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 7DCDE32316BD; Thu, 10 Sep 2009 05:54:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-12.clppva.btas.verizon.net [71.161.50.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id C21903228088; Thu, 10 Sep 2009 05:54:07 -0700 (PDT) Message-ID: <4AA8F6EE.7000702@joelhalpern.com> Date: Thu, 10 Sep 2009 08:54:06 -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> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> In-Reply-To: <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" , Margaret Wasserman 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: Thu, 10 Sep 2009 12:53:34 -0000 I am willing to work from this text (sorry, I had lost track of it. You had sent it to the list.) However, to claim "We can't do better" is not appropriate. There are multiple hanging pronouns and unspecified antecedents which are actually confusing. Dino Farinacci wrote: ... > UDP Checksum: this field MAY be transmitted as zero by an ITR and > when received by an ETR, it MUST accept the packet for > decapsulation. 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 decapsulation; 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. ... > I think we can't do better than this current text. I move to keep it the > way it is. > > Dino Using that as a base: UDP Checksum: this field MAY be transmitted as zero by an ITR. When a packet with a zero UDP checksum is received by an ETR, the ITR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP Checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. 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. Feel free to wordsmith further if needed. Joel From jmh@joelhalpern.com Thu Sep 10 05:56: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 BAD9C3A68F4 for ; Thu, 10 Sep 2009 05:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 1tPaq2DkEpEa for ; Thu, 10 Sep 2009 05:56:30 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 1C3CD3A67F8 for ; Thu, 10 Sep 2009 05:56:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 5AC343228088; Thu, 10 Sep 2009 05:57:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-12.clppva.btas.verizon.net [71.161.50.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 70FD53231747; Thu, 10 Sep 2009 05:57:04 -0700 (PDT) Message-ID: <4AA8F79E.1020104@joelhalpern.com> Date: Thu, 10 Sep 2009 08:57:02 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> In-Reply-To: <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org, Noel Chiappa , Margaret Wasserman Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 12:56:30 -0000 I would suggest RFC 4086 (which obsoleted 1750). Joel Dino Farinacci wrote: >> On Sep 9, 2009, at 11:33 PM, Christopher Morrow wrote: >>> >>> also, please, please, please mention that making the nonce a >>> sequential number isn't a good plan, nor is using a prng of poor >>> quality. Let's not incur the same sets of issues TCP has had with >>> seq#. >> >> Yes, we need to say something about using a good source of random >> numbers. I think there is an RFC we can reference with advice about >> that, but I'll have to look up the number tomorrow. > > Chris, how about I add this text to the spec: > > Nonce: An 8-byte random value created by the sender of the Map- > Request. This nonce will be returned in the Map-Reply. A > suggested source for good random number generation can be found in > [RFC1750]. > > Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From mrw@sandstorm.net Thu Sep 10 06: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 2B54D3A6B03 for ; Thu, 10 Sep 2009 06:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 DKEIedTZ8boL for ; Thu, 10 Sep 2009 06:58:36 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 21E563A693A for ; Thu, 10 Sep 2009 06:58:24 -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 n8ADweDw054435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Sep 2009 09:58:41 -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: Thu, 10 Sep 2009 09:58:41 -0400 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: [lisp] Randomness Requirements for Nonce X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 13:58:37 -0000 On Sep 9, 2009, at 11:38 PM, Margaret Wasserman wrote: > > Yes, we need to say something about using a good source of random > numbers. I think there is an RFC we can reference with advice about > that, but I'll have to look up the number tomorrow. The document I mentioned is RFC 4086: Randomness Requirements for Security. Since the LISP nonce (in the control packets, anyway) is a security nonce, I think we should state that the nonce should be generated using a source of random numbers that meets the requirements in RFC 4086. Margaret From mrw@sandstorm.net Thu Sep 10 07:19: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 0261228C153 for ; Thu, 10 Sep 2009 07:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 Wd8Dd00FbMuK for ; Thu, 10 Sep 2009 07:19:12 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 168923A68B3 for ; Thu, 10 Sep 2009 07:19:11 -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 n8AEJfgY055388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Sep 2009 10:19:41 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <8C8C24C1-884C-4C21-AF67-3C5ABDBDE6DC@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <2E0A736E-79E1-44B4-8562-7C778354EAAD@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: Thu, 10 Sep 2009 10:19:41 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> X-Mailer: Apple Mail (2.935.3) 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: Thu, 10 Sep 2009 14:19:13 -0000 On Sep 10, 2009, at 12:49 AM, Dino Farinacci wrote: > Well I thought what we had was pretty good. I will include it below > so others can compare. But see my specific comments below. > >> Joel and I came up with the following text: >> >> UDP Checksum: An ITR MAY set this field to 0 in both IPv4 and IPv6 >> outer headers [RFC 768, UDP-TUNNEL]. If the ITR does > > First off, this first sentence is misleading. It makes one think the > UDP checksum is in the IPv4 and IPv6 header or leads one to believe > the checksum in the IPv4 header is part of this description. Can you suggest rewording that would still make it clear that this applies to both IPv4 and IPv6 encapsulations? Perhaps "An ITR may set this field to 0 in both IPv4 and IPv6 encapsulations to indicate that a UDP checksum has not been calculated [RFC 768, UDP-TUNNEL]." ? > > It also makes me think there are two headers by the reference to > "outer headers". Talking about IPv4 and IPv6 in parallel leads to > the confusion. > >> not set this field to 0, it MUST be set to a valid UDP >> checksum value. Upon receipt, an ETR MUST accept IPv4 > > What is a valid UDP checksum. I didn't like that in previous text > that was proposed. The checksum is a computation that is performed. > That is what is placed in this field. The receiver computes a > checksum to compare against this one to determine if the checksum in > the packet is valid. s/valid/correctly calculated? > > >> and IPv6 packets with an outer header UDP checksum of 0, >> and process them normally. If an ETR receives a packet > > "process them normally" IMO is not specific enough. Unless you want > to define what abnormal processing is. ;-) :-). We could change this to "should accept the packet for decapsulation", if you find that clearer. > > >> with a non-zero value in the UDP checksum field, it MAY >> choose to ignore the UDP checksum value, and treat the >> packet as if it had a 0 checksum. If it an ETR does >> compute the > > "If it an ETR" doesn't parse well so the text as is needs improvement. s/If it an/If an > > >> received UDP checksum, it SHOULD discard packets with >> invalid >> non-zero UDP checksums. > >> >> If anyone has concerns about this text, please let us know. > > Compare it to what is in the latest diff (with Marhsall's two > editorial changes): > > UDP Checksum: this field MAY be transmitted as zero by an ITR and > when received by an ETR, it MUST accept the packet for > decapsulation. When an ITR transmits a non-zero value, an ETR > MAY > verify the checksum value. The "it" in your first sentence is awkward. I understand that you are referring to the ETR, but on initial parsing it seems to refer to the UDP checksum field, as that is subject of the previous clause. More importantly, you are saying that an ETR "MAY verify", which is different from what I think the WG had agreed upon, which is that an ETR MAY ignore non-zero checksums. If we state it as "MAY ignore", then we aren't forced to state a requirement level (MAY or SHOULD) for verifying them. If you do want to phrase it this way, then I think we should say that "an ETR SHOULD verify the checksum value." > If the checksum is verified, the > packet is accepted for decapsulation; 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. > > And let me annotate why the text is better and sufficient on a > sentence by sentence basis: > >> UDP Checksum: this field MAY be transmitted as zero by an ITR and >> when received by an ETR, it MUST accept the packet for >> decapsulation. > > The first sentence indicates the zero checksum case. Tells you who > puts it in and the level of conformance that should be placed on it. > Then it says what the receiver should do and the level of > conformance that should occur. The first sentence does not reference UDP-TUNNEL, and does make it clear that you can use a zero checksum in IPv6, so I consider this to be ambiguous for the IPv6 case. > > >> When an ITR transmits a non-zero value, an ETR MAY >> verify the checksum value. If the checksum is verified, the > > Then the next sentence indicates what to do for non-zero values. > Also, you say "may verify" the checksum, using verify as the process > of checking, then you say "verified", indicating that the checksum > was correct, but I think that "verified" in this context is at least > as vague as "valid". You could say "If the checksum is correct" or > "If the checksum verification process indicates that the packet has > not been corrupted..." if you want to go all the way. As indicated above, I don't think this matches what we had agreed to say. Also, you say "may verify" the checksum, using verify as the process of checking, then you say "verified", indicating that the checksum was correct, but I think that "verified" in this case is more vague than "valid". You could say "If the checksum is correct" or, if you want to go all the way, you could replace "verify" with "calculate a UDP checksum for the packet as described in [RFC 768] and [RFC 2460]" and say "if the checksum in the packet matches the calculated UDP checksum". But, I think we're going kind of crazy a that point, because we're essentially re-writing what it means to check a checksum. > >> packet is accepted for decapsulation; otherwise, it is silently >> dropped. Note, even when the UDP checksum is transmitted as >> zero > > The third sentence indicates what happens when the checksum is good > and when it is bad, for non-zero values. > >> an intervening NAT device can recalculate the checksum and >> rewrite >> the UDP checksum field to non-zero. See draft [UDP-TUNNELS] for >> details. > > And the final sentence talks about the NAT corner case. I don't like the idea of including the NAT case here. For one thing, this could be interepretted as _allowing_ NATs to do this. If we want to mention the "NAT corner case" as you put it, we should do so in a separate paragraph, and we should make it clear that recalculating the UDP checksum in forwarded packets is a _bug_ in these NATs, as it gives the assurance of end-to-end integrity protection when that has not been provided. > > I think we can't do better than this current text. I move to keep it > the way it is. I was responding to a message where you asked me and Joel to provide UDP checksum text for the document. So, I guess I move that we use the text that you asked me and Joel to provide. Margaret From mrw@sandstorm.net Thu Sep 10 07:21: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 9E94128C19D for ; Thu, 10 Sep 2009 07:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 f0HhQIvftWka for ; Thu, 10 Sep 2009 07:21:17 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id C3BAB28C1A4 for ; Thu, 10 Sep 2009 07:21:16 -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 n8AELhEP055510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Sep 2009 10:21:43 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <8E3B561B-4650-452E-9E51-AB53EBFACE62@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: Thu, 10 Sep 2009 10:21:43 -0400 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 14:21:17 -0000 On Sep 10, 2009, at 2:53 AM, Dino Farinacci wrote: > > Nonce: An 8-byte random value created by the sender of the Map- > Request. This nonce will be returned in the Map-Reply. A > suggested source for good random number generation can be found > in > [RFC1750]. That isn't the right RFC. You should cite RFC 4086. Also, because this is s security-sensitive nonce, I think that we should state that "the nonce MUST be generated using a source of random numbers that meets the requirements in RFC 4086", not just suggest that implementations use a good random number generator. From christopher.morrow@gmail.com Thu Sep 10 07:24: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 CA70D3A680E for ; Thu, 10 Sep 2009 07:24:37 -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 2TzWButY3nWR for ; Thu, 10 Sep 2009 07:24:37 -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 0C37728C0ED for ; Thu, 10 Sep 2009 07:24:36 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so53581qwi.31 for ; Thu, 10 Sep 2009 07:25:07 -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=Mqg1x1TuRKxIM/+O6XOl7kiH/QYqaduhHIMWJXoq5yE=; b=b2/QzxkiYFspo5X+wpnhs2pzfdVPKEIeM03z1mmZ4bajKpvoHdU9xMi04B/H5udR0W V1kkMAPJ2xap/twfTu/TDtn0YeQuejiUaAMIcPkOGRWH7LW6fUw+H3CzOlhx5oJD+xkd nmdmeuJqHQWScvYC3G7CTap9+j6aLVvUhBZ/8= 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=IQ/UvxA3N8ljbf7MpSqiYj/qlxMVE74NwDNaxTpyw0awtapvr3ByvxW1zvWOauDxbY DAYCTwRgeq7nm+vRvplgzEBqmtmvrmt4g20vTrprbAxTWZZEqtKP8923Xx0i/h5xSWwc HzW8a8SPV0hvyHVLaIYM7yl2gCrJhszi88JOk= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.93.77 with SMTP id u13mr1357585qam.226.1252592707402; Thu, 10 Sep 2009 07:25:07 -0700 (PDT) In-Reply-To: References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> Date: Thu, 10 Sep 2009 10:25:07 -0400 X-Google-Sender-Auth: d377ee238ff8dc59 Message-ID: <75cb24520909100725v7fe19145j9182188ec9bf6efc@mail.gmail.com> From: Christopher Morrow 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] Randomness Requirements for Nonce X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 14:24:37 -0000 On Thu, Sep 10, 2009 at 9:58 AM, Margaret Wasserman wrot= e: > > On Sep 9, 2009, at 11:38 PM, Margaret Wasserman wrote: >> >> Yes, we need to say something about using a good source of random number= s. >> =A0I think there is an RFC we can reference with advice about that, but = I'll >> have to look up the number tomorrow. > > The document I mentioned is RFC 4086: =A0Randomness Requirements for Secu= rity. > =A0Since the LISP nonce (in the control packets, anyway) is a security no= nce, > I think we should state that the nonce should be generated using a source= of > random numbers that meets the requirements in RFC 4086. yes please. From mrw@sandstorm.net Thu Sep 10 07:24: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 F2BAA28C1A9 for ; Thu, 10 Sep 2009 07:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 9p6oDezupNVN for ; Thu, 10 Sep 2009 07:24:44 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id DA33E28C198 for ; Thu, 10 Sep 2009 07:24:43 -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 n8AEPFSZ055607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Sep 2009 10:25:15 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: "Joel M. Halpern" In-Reply-To: <4AA8F6EE.7000702@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, 10 Sep 2009 10:25:15 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> <4AA8F6EE.7000702@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) 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: Thu, 10 Sep 2009 14:24:45 -0000 On Sep 10, 2009, at 8:54 AM, Joel M. Halpern wrote: > > UDP Checksum: this field MAY be transmitted as zero by an ITR. > When a packet with a zero UDP checksum is received by an ETR, > the ITR MUST accept the packet for decapsulation. When an ITR > transmits a non-zero value for the UDP Checksum, it MUST send a > correctly computed value in this field. When an ETR receives a > packet with a non-zero checksum, it MAY choose to verify the > checksum value. If it chooses to perform such verification, and > the verification fails, the packet MUST be silently dropped. > If the ETR chooses not to perform the verification, or performs > the verification successfully, the packet MUST be accepted for > decapsulation. 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. > > Feel free to wordsmith further if needed. This is well-written, and what is says is close to good enough, I think. I have only three issues: (1) It should make it clear that we are allowing 0 UDP checksums in IPv6, as well as IPv4. Perhaps by adding "in both the IPv4 and IPv6 encapsulations." to the first sentence? (2) IMO, it should cite UDP-TUNNELS where it says that we can sent 0 checksums in IPv6. It should also cite RFC 768 (the UDP RFC), I think. (3) I would prefer that the NAT text move to a different paragraph, and that we make it clear that this is a situation that may be encountered during operations, not an allowed behavior. Margaret From christopher.morrow@gmail.com Thu Sep 10 07:25: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 BA9B028C1A1 for ; Thu, 10 Sep 2009 07:25:50 -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 0ckAitIvIziP for ; Thu, 10 Sep 2009 07:25:50 -0700 (PDT) Received: from mail-qy0-f177.google.com (mail-qy0-f177.google.com [209.85.221.177]) by core3.amsl.com (Postfix) with ESMTP id EA26228C180 for ; Thu, 10 Sep 2009 07:25:49 -0700 (PDT) Received: by qyk7 with SMTP id 7so6142qyk.18 for ; Thu, 10 Sep 2009 07:26: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=rV6GP80swIBgrxpvsgWSeg4LFotLoPg6rIFRlKRAvPc=; b=MgYce5FsG9aSsFcRS6cum63mhUSg5xVaFTbrIKJgARySplywmfzfqkcCBBXzcf76jm /mRP3gnz8ZusB2LALgWrAkZ/yhTDHkWA0krFDChCCgZFwUYGHeghmgZ/q++rBy0FQ8uk IANCcKEgdzix6WiuiAdbSQGeiQTAj9t6Bxtn8= 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=q0hHNt6pGYeZwH6D5whzL36mptIZwqzolO8oWkUDrNU74AkJUuJ0yiTx06GmoqU1EX +q0SZvHdl0Cy8zgkKu8ePzWn6/yvgpbHiiApVrMFUnCkfWbL1PtTMHxp/ttRgrMqhlQ4 5nux3+EQSQ8WYfkV+4b7EUL4C19rDAy5I1AJs= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.109.208 with SMTP id k16mr1371028qap.224.1252592783945; Thu, 10 Sep 2009 07:26:23 -0700 (PDT) In-Reply-To: References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> Date: Thu, 10 Sep 2009 10:26:23 -0400 X-Google-Sender-Auth: 3b110b5eb0f1a226 Message-ID: <75cb24520909100726l10a038fcw7432f29ec36f7f9f@mail.gmail.com> From: Christopher Morrow 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] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 14:25:50 -0000 On Thu, Sep 10, 2009 at 10:21 AM, Margaret Wasserman wro= te: > > On Sep 10, 2009, at 2:53 AM, Dino Farinacci wrote: >> >> =A0Nonce: =A0An 8-byte random value created by the sender of the Map- >> =A0 =A0 Request. =A0This nonce will be returned in the Map-Reply. =A0A >> =A0 =A0 suggested source for good random number generation can be found = in >> =A0 =A0 [RFC1750]. > > That isn't the right RFC. =A0You should cite RFC 4086. > > Also, because this is s security-sensitive nonce, I think that we should > state that "the nonce MUST be generated using a source of random numbers > that meets the requirements in RFC 4086", not just suggest that > implementations use a good random number generator. Dino, yup just switching the rfc reference as margaret noted seems good to = me. From dino@cisco.com Thu Sep 10 09:30: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 4B87E28C166 for ; Thu, 10 Sep 2009 09:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 rnXL9CuJKxjV for ; Thu, 10 Sep 2009 09:30:16 -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 E357128C139 for ; Thu, 10 Sep 2009 09:30:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC/GqEqrR7MV/2dsb2JhbADGSIhGAZBBBYQY X-IronPort-AV: E=Sophos;i="4.44,365,1249257600"; d="scan'208";a="42741870" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 10 Sep 2009 16:30:48 +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 n8AGUmkZ002672; Thu, 10 Sep 2009 09:30: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 n8AGUmei010472; Thu, 10 Sep 2009 16:30:48 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); Thu, 10 Sep 2009 09:30:47 -0700 Received: from [192.168.1.2] ([10.21.123.192]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 09:30:47 -0700 Message-Id: <81363CF5-431B-42C4-BA71-AF7B036AB913@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 v936) Date: Thu, 10 Sep 2009 09:30:47 -0700 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Sep 2009 16:30:47.0546 (UTC) FILETIME=[0D3FE5A0:01CA3234] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=682; t=1252600248; x=1253464248; 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]=2032-bit=20nonce=20in=20map=20re quest=20insufficient |Sender:=20; bh=Q9/noeYVS3u2X/Q531+Qq1DcuJprJmlmCV8cMLSqLlA=; b=EuSPyO2PVJpPc4W2v14r0IGEMDpggSGOJQ90NB64Cp5MBRyESyn3C++AxM 5fabMfM3OqkQ5BCyM8DhwYH2OVU1JrLWfF1moYP9rnFnOztpdRDIKMxaNlJk C19NWmIIZplgjQw0FYCioH8TdBrW78K2LgsO0kYefpbMPxcVvJBPY=; 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] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 16:30:18 -0000 > On Sep 10, 2009, at 2:53 AM, Dino Farinacci wrote: >> >> Nonce: An 8-byte random value created by the sender of the Map- >> Request. This nonce will be returned in the Map-Reply. A >> suggested source for good random number generation can be found >> in >> [RFC1750]. > > That isn't the right RFC. You should cite RFC 4086. > > Also, because this is s security-sensitive nonce, I think that we > should state that "the nonce MUST be generated using a source of > random numbers that meets the requirements in RFC 4086", not just > suggest that implementations use a good random number generator. How about SHOULD instead of MUST? Dino From hartmans@mit.edu Thu Sep 10 09:50: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 644613A6B50 for ; Thu, 10 Sep 2009 09:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 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 ArVcgzreiEFv for ; Thu, 10 Sep 2009 09:50:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 76E003A6B14 for ; Thu, 10 Sep 2009 09:50:40 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2C96F51CC; Thu, 10 Sep 2009 12:50:57 -0400 (EDT) To: Margaret Wasserman References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> From: Sam Hartman Date: Thu, 10 Sep 2009 12:50:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Noel Chiappa , lisp@ietf.org Subject: [lisp] text suggestion for random nonces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 16:50:41 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> On Sep 10, 2009, at 2:53 AM, Dino Farinacci wrote: >> > Nonce: An 8-byte random value created by the sender of the Map- >> Request. This nonce will be returned in the Map-Reply. A >> suggested source for good random number generation can be found >> in [RFC1750]. Margaret> That isn't the right RFC. You should cite RFC 4086. Margaret> Also, because this is s security-sensitive nonce, I Margaret> think that we should state that "the nonce MUST be Margaret> generated using a source of random numbers that meets Margaret> the requirements in RFC 4086", not just suggest that Margaret> implementations use a good random number Margaret> generator Hmm. I didn't think 4086 gave requirements so much as advice. >From the latest IPsec specs we have The security of this protocol is critically dependent on the randomness of the randomly chosen parameters. These should be generated by a strong random or properly seeded pseudo-random source (see [RFC4086]). Implementers should take care to ensure that use of random numbers for both keys and nonces is engineered in a fashion that does not undermine the security of the keys. I'd do something like. The security of the LISP mapping protocol depends critically on the strength of the nonce in the map request and reply messages. These nonces MUST be generated by a properly seeded pseudo-random (or strong random) source. See RFC 4086 for advice on generating security-sensitive random data. I think LISP wants a pseudo-random source because a strong random source is with current hardware going to be highly impractical from a performance standpoint. RFC 4086 should be a normative reference. From mrw@sandstorm.net Thu Sep 10 09:53: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 42CE43A6866 for ; Thu, 10 Sep 2009 09:53:52 -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 HdL2MNCt+eOO for ; Thu, 10 Sep 2009 09:53:51 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 4EB9F3A6B65 for ; Thu, 10 Sep 2009 09:53:35 -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 n8AGrxJO061709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Sep 2009 12:53:59 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <2C932ED3-2B75-4EA2-8AC7-6CD4AFD83059@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <81363CF5-431B-42C4-BA71-AF7B036AB913@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: Thu, 10 Sep 2009 12:53:58 -0400 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> <81363CF5-431B-42C4-BA71-AF7B036AB913@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] 32-bit nonce in map request insufficient X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 16:53:52 -0000 On Sep 10, 2009, at 12:30 PM, Dino Farinacci wrote: >> On Sep 10, 2009, at 2:53 AM, Dino Farinacci wrote: >>> >>> Nonce: An 8-byte random value created by the sender of the Map- >>> Request. This nonce will be returned in the Map-Reply. A >>> suggested source for good random number generation can be found >>> in >>> [RFC1750]. >> >> That isn't the right RFC. You should cite RFC 4086. >> >> Also, because this is s security-sensitive nonce, I think that we >> should state that "the nonce MUST be generated using a source of >> random numbers that meets the requirements in RFC 4086", not just >> suggest that implementations use a good random number generator. > > How about SHOULD instead of MUST? That works for me. Margaret From mrw@sandstorm.net Thu Sep 10 09:56: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 588ED3A6A57 for ; Thu, 10 Sep 2009 09:56:11 -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 n+hMPNwGXx2b for ; Thu, 10 Sep 2009 09:56:10 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id E97CB3A6866 for ; Thu, 10 Sep 2009 09:56:09 -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 n8AGuhff061858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Sep 2009 12:56:43 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <1B87791B-983C-4A79-9428-ED160896CD65@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: Thu, 10 Sep 2009 12:56:43 -0400 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] text suggestion for random nonces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 16:56:11 -0000 On Sep 10, 2009, at 12:50 PM, Sam Hartman wrote: > The security of the LISP mapping protocol depends critically on the > strength of the nonce in the map request and reply messages. These > nonces MUST be generated by a properly seeded pseudo-random (or strong > random) source. See RFC 4086 for advice on generating > security-sensitive random data. This wording would be fine with me. I'd also be find with the "MUST" in the above wording being changed to a "SHOULD". The important points, to me, are that we stress that this is a security-sensitive nonce, and that the security of the system depends on good random number generation (a la RFC 4086). Margaret From hartmans@mit.edu Thu Sep 10 10: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 4430428C197 for ; Thu, 10 Sep 2009 10:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 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 o4hvk8wu2-dm for ; Thu, 10 Sep 2009 10:00: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 8B9043A69F7 for ; Thu, 10 Sep 2009 10:00:35 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A8F6351CC; Thu, 10 Sep 2009 13:00:52 -0400 (EDT) To: Margaret Wasserman References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> <1B87791B-983C-4A79-9428-ED160896CD65@sandstorm.net> From: Sam Hartman Date: Thu, 10 Sep 2009 13:00:52 -0400 In-Reply-To: <1B87791B-983C-4A79-9428-ED160896CD65@sandstorm.net> (Margaret Wasserman's message of "Thu\, 10 Sep 2009 12\:56\:43 -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: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] text suggestion for random nonces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 17:00:36 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> On Sep 10, 2009, at 12:50 PM, Sam Hartman wrote: >> The security of the LISP mapping protocol depends critically on >> the strength of the nonce in the map request and reply >> messages. These nonces MUST be generated by a properly seeded >> pseudo-random (or strong random) source. See RFC 4086 for >> advice on generating security-sensitive random data. Margaret> This wording would be fine with me. I'd also be find Margaret> with the "MUST" in the above wording being changed to a Margaret> "SHOULD". I'd prefer MUST, but I could live with SHOULD. I was quoting from a source that used lower case should to state fairly strong requirements, and in the translation musted because I thought that was consistent with the original intent. From damien.saucez@uclouvain.be Thu Sep 10 10:16: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 14A8628C0D8 for ; Thu, 10 Sep 2009 10:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, 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 vMhMmvmDtcZe for ; Thu, 10 Sep 2009 10:16:47 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id D395328C10D for ; Thu, 10 Sep 2009 10:16:46 -0700 (PDT) Received: from [130.104.228.15] (sleipnier-lite.dhcp.info.ucl.ac.be [130.104.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 841CAE8DA8; Thu, 10 Sep 2009 19:17:05 +0200 (CEST) Message-ID: <4AA93490.9010906@uclouvain.be> Date: Thu, 10 Sep 2009 19:17:04 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Margaret Wasserman References: <20090813144010.3BBA26BE556@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 841CAE8DA8.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: Noel Chiappa , 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, 10 Sep 2009 17:16:48 -0000 Sorry for re-opening this thread. Margaret Wasserman wrote: > > 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. Well, control-traffic to negotiate the version is a good idea and definitely has to be studied. However, a version number field is still helpful. For example, without a version field, gleaning won't work. Gleaning is used to avoid wasting time waiting for a mapping, you then send packets without any control-plane version negotiation. If you have the version in the LISP header, it is easy, you know the maximum LISP version you can use with the destination. In addition, with the version field, you can even simplify the "negotiation protocol" to the minimum. A sends a Map-Request for B (with the maximum version you can support, just in case of crazy pre-mapping fetching from B) and the Map-Reply from B contains the maximum version that is supported by B's eTRs. Traffic can then be sent from A to B. When B has to send traffic to A, it sends a Map-Request to A and receives the version that is supported by A, B can then send traffic correctly to A. Regards, Damien Saucez > Margaret > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From lear@cisco.com Thu Sep 10 10:20: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 1144128C0D8 for ; Thu, 10 Sep 2009 10:20:24 -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 OngZZaskbqvG for ; Thu, 10 Sep 2009 10:20:23 -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 C4F0F3A6A1D for ; Thu, 10 Sep 2009 10:20:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8AAFvSqEqQ/uCLe2dsb2JhbACBU5lrAQEWJAarEohGAZBHBYQYimE X-IronPort-AV: E=Sophos;i="4.44,365,1249257600"; d="scan'208";a="49100255" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Sep 2009 17:20:56 +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 n8AHKufS025534; Thu, 10 Sep 2009 19:20:56 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp6505.cisco.com [10.61.89.104]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8AHKuZP011220; Thu, 10 Sep 2009 17:20:56 GMT Message-ID: <4AA93578.9060102@cisco.com> Date: Thu, 10 Sep 2009 19:20:56 +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: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@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=743; t=1252603256; x=1253467256; 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]=20text=20suggestion=20for=20rand om=20nonces |Sender:=20; bh=8qSQ/fcITmWrO1kFPUT9yvx29OOfdIpbVFkshdCkQ1k=; b=Mx+sUhICwSBVVhQANqF8CWI6YP2wC7MnslHZV5b0CMbOsMq39SicNT2bLe y3LrM+Kp8jSlnwODqePu8ifxL0JolKMkZx2kGri5v9MFs5nKbir5TuylBhC4 i0oZiSnC25; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: lisp@ietf.org, Noel Chiappa , Margaret Wasserman Subject: Re: [lisp] text suggestion for random nonces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 17:20:24 -0000 On 9/10/09 6:50 PM, Sam Hartman wrote: > I'd do something like. > > The security of the LISP mapping protocol depends critically on the > strength of the nonce in the map request and reply messages. These > nonces MUST be generated by a properly seeded pseudo-random (or strong > random) source. See RFC 4086 for advice on generating > security-sensitive random data. > > I think LISP wants a pseudo-random source because a strong random > source is with current hardware going to be highly impractical from a > performance standpoint. RFC 4086 should be a normative reference. > This seems like good text, Sam. It's amazing how many times implementations get that stuff wrong (and it's so easy to get wrong). Eliot From damien.saucez@uclouvain.be Thu Sep 10 10:54: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 E96BF28C13C for ; Thu, 10 Sep 2009 10:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 FkUGHlTOrshV for ; Thu, 10 Sep 2009 10:54:16 -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 6D2E028C123 for ; Thu, 10 Sep 2009 10:54:16 -0700 (PDT) Received: from [130.104.228.15] (sleipnier-lite.dhcp.info.ucl.ac.be [130.104.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 5E9FD1C5BCD; Thu, 10 Sep 2009 19:54:44 +0200 (CEST) Message-ID: <4AA93D66.4020704@uclouvain.be> Date: Thu, 10 Sep 2009 19:54:46 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Noel Chiappa References: <20090904152138.D22FD6BE5F8@mercury.lcs.mit.edu> In-Reply-To: <20090904152138.D22FD6BE5F8@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 5E9FD1C5BCD.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] [#16]: Desire to expand data plane for map versioning or handle in the control plane X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 10 Sep 2009 17:54:18 -0000 Noel Chiappa wrote: > > From: Margaret Wasserman > > > I'd prefer that we use short-enough TTLs to allow new mapping entries > > to be detected in a reasonably short period of time without an explicit > > signalling mechanism. > > Well, it's certainly true that DNS seems to do OK without a mechanism for > detecting outdated mappings, so perhaps this is a non-issue. I'd be a bit > wary of craking the TTLs _way_ down, though - it could cause a rather large > traffic load. > > > If there is concern that this would result in too much mapping > > traffic > > Mindreader! :-) > > > > we could work on a mechanism to extend the TTL (and suppress subsequent > > mapping lookups) when there is ongoing successful communication. > > Then, you change the meaning of TTL. A solution is to have a TTL A for the mapping and a TTL B for the connectivity check. On one hand, a request MUST me send if A expires and traffic has to be sent. On the other hand, a connectivity check has to be sent after B expires except if traffic has been seen within this period. See the following for all the discussion about the "ongoing traffic tests". Versioning could help but will not give the solution. Regards, Damien Saucez > Interesting idea. I thought about this for a while, and we can do something > (although I think it needs either a new control message, or some incredibly > hairy user traffic analysis), but there are fundamental limits on what we can > do via this path. > > The thing is that just because an xTR is up and reachable - which is what all > the various existing mechanisms give us - that doesn't mean that a mapping > that uses it is correct, i.e. "ongoing successful communication". In other > words, even if you can successfully send a packet for EID D from ITR Is to > ETR Ed, and Ed is up and working, that doesn't mean that Ed is the right ETR. > > To truly check for "ongoing successful communication", we'd need to be able > to ensure that traffic reaching Ed for D is actually getting to D, and that > implies either i) some sort of deep analysis of user-data traffic (e.g. to > watch for TCP ACKs), or ii) for Ed to tell Is that Ed is _not_ an ETR through > which D is reachable. (A NACK is preferred to an ACK, for obvious reasons.) > > (OK, OK, so the latter is not actually making sure the traffic gets all the > way through to D - but to me it's not reasonable to expect LISP to verify > that, e.g. interior site routing is working; all it should be required to be > responsible for is making sure that the _LISP_ stuff is working OK.) > > I'm not too big on the 'deep inspection' path, so that leaves the other; we'd > need to define a LISP error message (we don't seem to have one at the moment) > which says 'this is the wrong ETR for that EID'. Of course, that would be a > DoS attack vector, so the response at the ITR, on receiving it, would be just > to start a resolution cycle to refresh the mapping. > > (BTW, what do ETRs do at the moment, if they get a packet which they are not > the correct ETR for? I assume they unwrap it, try and forward it, and > depending on how the code is written, it may either get re-wrapped and send > to an ETR, or forwarded to a PITR.) > > > Still, this whole approach has a limit though - which is that it can say > nothing about whether the _mapping_ is up-to-date, simply that Ed considers > itself a viable ETR for D. LISP contains a number of features for > load-sharing, for primary and backup ETRs, etc, and this method can't detect > any changes in the mapping as a whole (at least, not that I can see). > > I think the only way to do that would be something like versioning; whether > that's done in a separate control-plane interaction, or piggy-backed on > user-data traffic, is a separate question. > > (Note that it could also be either 'forward' or 'backward'; i.e. the ITR could > tell the ETR what mapping it's using for the destination EID, and the ETR > would notify the ITR if it's old; or the ETR could tell the ITR what the > latest mapping is for that EID, and the ITR would have to notice if its > mapping is outdated.) > > But maybe I'm missing something? > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From tme@americafree.tv Thu Sep 10 11: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 B4A053A6915 for ; Thu, 10 Sep 2009 11:54:46 -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 2YboX69eZJb0 for ; Thu, 10 Sep 2009 11:54:45 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 8FDD23A6B47 for ; Thu, 10 Sep 2009 11:54:45 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 5C5184B1D9A5; Thu, 10 Sep 2009 14:55:00 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Dino Farinacci In-Reply-To: <2E0A736E-79E1-44B4-8562-7C778354EAAD@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: Thu, 10 Sep 2009 14:54:58 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" , Margaret Wasserman 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: Thu, 10 Sep 2009 18:54:46 -0000 On Sep 10, 2009, at 12:49 AM, Dino Farinacci wrote: > Well I thought what we had was pretty good. I will include it below > so others can compare. But see my specific comments below. > >> Joel and I came up with the following text: >> >> UDP Checksum: An ITR MAY set this field to 0 in both IPv4 and IPv6 >> outer headers [RFC 768, UDP-TUNNEL]. If the ITR does > > First off, this first sentence is misleading. It makes one think the > UDP checksum is in the IPv4 and IPv6 header or leads one to believe > the checksum in the IPv4 header is part of this description. > > It also makes me think there are two headers by the reference to > "outer headers". Talking about IPv4 and IPv6 in parallel leads to > the confusion. > >> not set this field to 0, it MUST be set to a valid UDP >> checksum value. Upon receipt, an ETR MUST accept IPv4 > > What is a valid UDP checksum. I didn't like that in previous text > that was proposed. The checksum is a computation that is performed. > That is what is placed in this field. The receiver computes a > checksum to compare against this one to determine if the checksum in > the packet is valid. > >> and IPv6 packets with an outer header UDP checksum of 0, >> and process them normally. If an ETR receives a packet > > "process them normally" IMO is not specific enough. Unless you want > to define what abnormal processing is. ;-) > >> with a non-zero value in the UDP checksum field, it MAY >> choose to ignore the UDP checksum value, and treat the >> packet as if it had a 0 checksum. If it an ETR does >> compute the > > "If it an ETR" doesn't parse well so the text as is needs improvement. > >> received UDP checksum, it SHOULD discard packets with >> invalid >> non-zero UDP checksums. > >> >> If anyone has concerns about this text, please let us know. > > Compare it to what is in the latest diff (with Marhsall's two > editorial changes): > > UDP Checksum: this field MAY be transmitted as zero by an ITR and > when received by an ETR, it MUST accept the packet for s/it/the ETR/ (which "it" is meant might confuse some). Regards Marshall > decapsulation. 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 decapsulation; 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. > > And let me annotate why the text is better and sufficient on a > sentence by sentence basis: > >> UDP Checksum: this field MAY be transmitted as zero by an ITR and >> when received by an ETR, it MUST accept the packet for >> decapsulation. > > The first sentence indicates the zero checksum case. Tells you who > puts it in and the level of conformance that should be placed on it. > Then it says what the receiver should do and the level of > conformance that should occur. > >> When an ITR transmits a non-zero value, an ETR MAY >> verify the checksum value. If the checksum is verified, the > > Then the next sentence indicates what to do for non-zero values. > >> packet is accepted for decapsulation; otherwise, it is silently >> dropped. Note, even when the UDP checksum is transmitted as >> zero > > The third sentence indicates what happens when the checksum is good > and when it is bad, for non-zero values. > >> an intervening NAT device can recalculate the checksum and >> rewrite >> the UDP checksum field to non-zero. See draft [UDP-TUNNELS] for >> details. > > And the final sentence talks about the NAT corner case. > > I think we can't do better than this current text. I move to keep it > the way it is. > > Dino > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From tme@americafree.tv Thu Sep 10 17:11: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 516913A6993 for ; Thu, 10 Sep 2009 17:11:35 -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 gmKzB1PJAIfh for ; Thu, 10 Sep 2009 17:11:34 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 687C03A67CC for ; Thu, 10 Sep 2009 17:11:34 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id C30884B2536A; Thu, 10 Sep 2009 20:12:08 -0400 (EDT) Message-Id: <33A6F94F-E9D2-4E6B-BDAA-F7E632AED81D@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: Thu, 10 Sep 2009 20:12:06 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> <4AA8F6EE.7000702@joelhalpern.com> X-Mailer: Apple Mail (2.936) 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: Fri, 11 Sep 2009 00:11:35 -0000 I agree with Margaret about referencing both RFC 768 and the draft when zero checksums first appear. On Sep 10, 2009, at 10:25 AM, Margaret Wasserman wrote: > > On Sep 10, 2009, at 8:54 AM, Joel M. Halpern wrote: How about >> >> UDP Checksum: this field MAY be transmitted as zero by an ITR. s/ITR/ITR in either IPv4 or IPv6 [RFC 768, UDP-TUNNEL]/ I would suggest this change in Dino's variant of this text as well, for the same reason. Marshall >> When a packet with a zero UDP checksum is received by an ETR, >> the ITR MUST accept the packet for decapsulation. When an ITR >> transmits a non-zero value for the UDP Checksum, it MUST send a >> correctly computed value in this field. When an ETR receives a >> packet with a non-zero checksum, it MAY choose to verify the >> checksum value. If it chooses to perform such verification, and >> the verification fails, the packet MUST be silently dropped. >> If the ETR chooses not to perform the verification, or performs >> the verification successfully, the packet MUST be accepted for >> decapsulation. 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. >> >> Feel free to wordsmith further if needed. > > This is well-written, and what is says is close to good enough, I > think. I have only three issues: > > (1) It should make it clear that we are allowing 0 UDP checksums in > IPv6, as well as IPv4. Perhaps by adding "in both the IPv4 and IPv6 > encapsulations." to the first sentence? > > (2) IMO, it should cite UDP-TUNNELS where it says that we can sent 0 > checksums in IPv6. It should also cite RFC 768 (the UDP RFC), I > think. > > (3) I would prefer that the NAT text move to a different paragraph, > and that we make it clear that this is a situation that may be > encountered during operations, not an allowed behavior. > > Margaret > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Thu Sep 10 22:22: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 A76D63A69CE for ; Thu, 10 Sep 2009 22:22:11 -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 i7vRbOr41mU4 for ; Thu, 10 Sep 2009 22:22: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 4CFBC3A692E for ; Thu, 10 Sep 2009 22:22:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,368,1249257600"; d="scan'208";a="386521289" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Sep 2009 05:22:47 +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 n8B5MlMl021451; Thu, 10 Sep 2009 22:22:47 -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 n8B5Mlp9000863; Fri, 11 Sep 2009 05:22:47 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, 10 Sep 2009 22:22:46 -0700 Received: from [192.168.1.2] ([10.21.72.92]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 22:22:45 -0700 Message-Id: <1600AB62-6155-48B0-A086-C63FFE6F075D@cisco.com> From: Dino Farinacci To: Eliot Lear In-Reply-To: <4AA93578.9060102@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: Thu, 10 Sep 2009 22:22:45 -0700 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> <4AA93578.9060102@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 05:22:46.0256 (UTC) FILETIME=[E55A2700:01CA329F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1209; t=1252646567; x=1253510567; 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]=20text=20suggestion=20for=20rand om=20nonces |Sender:=20; bh=/sYiAqFbAO1N45G+1jD7gobvTS6A49mcM1IM5PjQmB8=; b=z1D3vDT0JiMNwb6fX/zAy30IRCbk4SCOIEkgSAc+onJF1C6c2ttLf/wE2E I+22B3OMtLCgTcCOWhxZieSMa3DBCv4NDb7OsPaKsW+KS/i5W6wwABkJooCe 4o/KLD//hH; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Margaret Wasserman , lisp@ietf.org, Noel Chiappa Subject: Re: [lisp] text suggestion for random nonces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 05:22:11 -0000 I will include Sam's text with a SHOULD. Since the attack is going to be rare with a 64-bit guess, any random number generator will be fairly good IMO. But we can suggest the RFC 4086. I'll update the diffs with this text. Thanks all. Dino On Sep 10, 2009, at 10:20 AM, Eliot Lear wrote: > On 9/10/09 6:50 PM, Sam Hartman wrote: >> I'd do something like. >> >> The security of the LISP mapping protocol depends critically on the >> strength of the nonce in the map request and reply messages. These >> nonces MUST be generated by a properly seeded pseudo-random (or >> strong >> random) source. See RFC 4086 for advice on generating >> security-sensitive random data. >> >> I think LISP wants a pseudo-random source because a strong random >> source is with current hardware going to be highly impractical from a >> performance standpoint. RFC 4086 should be a normative reference. >> > > This seems like good text, Sam. It's amazing how many times > implementations get that stuff wrong (and it's so easy to get wrong). > > Eliot > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Thu Sep 10 22:34: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 07F3D3A691E for ; Thu, 10 Sep 2009 22:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 uUGDa5ottW3m for ; Thu, 10 Sep 2009 22:34:06 -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 107CA3A6827 for ; Thu, 10 Sep 2009 22:34:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,368,1249257600"; d="scan'208";a="386527143" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Sep 2009 05:34:39 +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 n8B5YdtP026046; Thu, 10 Sep 2009 22:34:39 -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 n8B5YdSX006988; Fri, 11 Sep 2009 05:34:39 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, 10 Sep 2009 22:34:39 -0700 Received: from [192.168.1.2] ([10.21.72.92]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 22:34:38 -0700 Message-Id: <06D7085E-9F24-495B-97E8-B00E1042ABD8@cisco.com> From: Dino Farinacci To: Dino Farinacci In-Reply-To: <1600AB62-6155-48B0-A086-C63FFE6F075D@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: Thu, 10 Sep 2009 22:34:37 -0700 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> <4AA93578.9060102@cisco.com> <1600AB62-6155-48B0-A086-C63FFE6F075D@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 05:34:38.0776 (UTC) FILETIME=[8E0C1380:01CA32A1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2096; t=1252647279; x=1253511279; 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]=20text=20suggestion=20for=20rand om=20nonces |Sender:=20; bh=qukrngdY++kLGOJg/CLOrXR5mRV8vsIxuk9BP7ZS5b4=; b=TVG3Pt9Ipn0ZEiAAKMqLCG/X2RbAiAJ5nr+1lJ9yhI3P4CJUpcyicC0WTL U9lj+vUSNueAqCjkvn6BVJIczsk5Iw5UogM/GqfCdyjbD5RVm+4HW8pLE8jZ IF8x2fMk8xRraxXt1c2lgKpdiNW+O6ickhXx3hAQSPHG0G1ACBlho=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Noel Chiappa , lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] text suggestion for random nonces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 05:34:07 -0000 By the way, I change the text a bit because a Map-Reply doesn't have a "nonce generation" but echos the nonce from the Map-Request. So this is what I'd include: Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. Okay? Dino On Sep 10, 2009, at 10:22 PM, Dino Farinacci wrote: > I will include Sam's text with a SHOULD. Since the attack is going > to be rare with a 64-bit guess, any random number generator will be > fairly good IMO. But we can suggest the RFC 4086. > > I'll update the diffs with this text. Thanks all. > > Dino > > On Sep 10, 2009, at 10:20 AM, Eliot Lear wrote: > >> On 9/10/09 6:50 PM, Sam Hartman wrote: >>> I'd do something like. >>> >>> The security of the LISP mapping protocol depends critically on the >>> strength of the nonce in the map request and reply messages. These >>> nonces MUST be generated by a properly seeded pseudo-random (or >>> strong >>> random) source. See RFC 4086 for advice on generating >>> security-sensitive random data. >>> >>> I think LISP wants a pseudo-random source because a strong random >>> source is with current hardware going to be highly impractical >>> from a >>> performance standpoint. RFC 4086 should be a normative reference. >>> >> >> This seems like good text, Sam. It's amazing how many times >> implementations get that stuff wrong (and it's so easy to get wrong). >> >> Eliot >> _______________________________________________ >> 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 dino@cisco.com Thu Sep 10 23:19: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 DC1B73A681A for ; Thu, 10 Sep 2009 23:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 3E4P17W2Rn+k for ; Thu, 10 Sep 2009 23:19:08 -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 F20653A6784 for ; Thu, 10 Sep 2009 23:19:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHeIqUqrR7MV/2dsb2JhbADEMIhGAZArBYI7gV2BWQ X-IronPort-AV: E=Sophos;i="4.44,369,1249257600"; d="scan'208";a="386549393" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Sep 2009 06:19:31 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8B6JVhN017311; Thu, 10 Sep 2009 23:19:31 -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 n8B6JVTV009463; Fri, 11 Sep 2009 06:19:31 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, 10 Sep 2009 23:19:31 -0700 Received: from [192.168.1.2] ([10.21.72.92]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 23:19:30 -0700 Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AA8F6EE.7000702@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: Thu, 10 Sep 2009 23:19:30 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> <4AA8F6EE.7000702@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 06:19:31.0066 (UTC) FILETIME=[D2C6EDA0:01CA32A7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2142; t=1252649971; x=1253513971; 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]=20Suggested=20UDP=20checksum=20t ext |Sender:=20; bh=tc/inqEcGdg+U1oOxSvbwvPAxF3LlyvKyo89TwcNcp8=; b=QarJldYSipQWjM9ZIWqUwZh5d6tcaLh2d1NtIK0ZWzymn0aCU4r44aLyne Bxsk1jM6E+Zzozyl168KYM2wjsvfee6/P8n6ir/2O2hUGpNsjuxwAaKaXRwM NDp8gDJdaQ6Qh3LqvdUbOy5QyidpVMgKqezuqhXtt84xLSYfP6C0I=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "lisp@ietf.org" , Margaret Wasserman 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: Fri, 11 Sep 2009 06:19:08 -0000 > Using that as a base: > > UDP Checksum: this field MAY be transmitted as zero by an ITR. > When a packet with a zero UDP checksum is received by an ETR, > the ITR MUST accept the packet for decapsulation. When an ITR ITRs don't decapsulate. > transmits a non-zero value for the UDP Checksum, it MUST send a > correctly computed value in this field. When an ETR receives a > packet with a non-zero checksum, it MAY choose to verify the > checksum value. If it chooses to perform such verification, and > the verification fails, the packet MUST be silently dropped. > If the ETR chooses not to perform the verification, or performs > the verification successfully, the packet MUST be accepted for > decapsulation. 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. > > Feel free to wordsmith further if needed. > Joel Okay, so here is what I have to capture Margaret and Marshall's comments: UDP Checksum: this field MAY be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. 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. Thanks all, Dino From dino@cisco.com Thu Sep 10 23:30: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 4A7223A69B2 for ; Thu, 10 Sep 2009 23:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1ExgjQJxcu0 for ; Thu, 10 Sep 2009 23:30:30 -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 D27773A686E for ; Thu, 10 Sep 2009 23:30:29 -0700 (PDT) X-Files: rfcdiff-lisp-03-to-04.html, draft-ietf-lisp-04.txt : 165852, 151164 X-IronPort-AV: E=Sophos;i="4.44,369,1249257600"; d="txt'?html'217?scan'217,208,217";a="386554978" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 11 Sep 2009 06:31:06 +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 n8B6V6UT013612 for ; Thu, 10 Sep 2009 23:31:06 -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 n8B6V61I009850 for ; Fri, 11 Sep 2009 06:31:06 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, 10 Sep 2009 23:31:06 -0700 Received: from [192.168.1.2] ([10.21.72.92]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 23:31:05 -0700 Message-Id: <0A259189-5D0A-44E9-BCBB-6698BA057BF6@cisco.com> From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-40--534441808 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 10 Sep 2009 23:31:04 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 06:31:05.0560 (UTC) FILETIME=[70BA4D80:01CA32A9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=325152; t=1252650666; x=1253514666; 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:=20Thursday=20updated=20diff=20file=20for=20the=20 lisp-04=20proposed=20changes |Sender:=20; bh=ZTQrmSmQMdHUyx9X5dKqr7oDe8BTp56gQkIx/4TFDko=; b=cOYgqTBEFHFRY2FFUigkx1GubeL3k3Jo+6VXc0//7BXaiOk9dnApAZndAe oHYDjmNcp6OrGN/L4iF3Gr7PyzWgnguj1Q/SP3MzTzwHwc1xMC9MwH4GKcvu 5wOW0FPPue; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [lisp] Thursday updated diff file for the lisp-04 proposed changes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 06:30:30 -0000 --Apple-Mail-40--534441808 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Includes 2 changes from the Wednesday diffs: (1) Word-smithing of the UDP Checksum field from the data encapsulation header. (2) Refer to good random number generators from RFC 4086 for the 64- bit Map-Request Nonce. If I receive no comments by noon PDT tomorrow, I will post the draft with the proposed changes you find in the diff file enclosed. I will change the header of the draft to not include "(PROPOSED) draft-ietf- lisp-04.txt (NOT SUBMITTED)" before submission. Thanks, Dino/Dave/Darrel/Vince --Apple-Mail-40--534441808 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 14, 2010                                         D. Lewis
                                                           cisco Systems
                                                           July 27,
                                                      September 10, 2009

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

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 14, 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 22
       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 36
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 36 37
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 38 39
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 39 41
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 40 42
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 40 43
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 41 44
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 43 46
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 44 47
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 45 48
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 45 48
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 46 49
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 47 50
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 51
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 51
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 48 51
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 50 53
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 50 53
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 53
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 53
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 52 55
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 52 55
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 54 57
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 55 58
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 56 59
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 62
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 59 62
     14.2. Informative References . . . . . . . . . . . . . . . . . . 60 63
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 63 66
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 67

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 statically 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 prepends 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
      statically 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 prepends 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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

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

   OH

   Outer 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 and ignored on
      receipt zero by an ITR for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
      packet with a zero UDP checksum is received by an ETR, the ETR. ETR
      MUST accept the packet for decapsulation.  When an ITR transmits a
      non-zero value for the UDP checksum, it MUST send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.

      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.

   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

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

   LISP Locator Reach Bits:  in the LISP header are nonce-present bit.  When this bit is set by an ITR to
      indicate to an 1, the
      low-order 24-bits of the first 32-bits of the LISP header contains
      a Nonce.  See section Section 6.3.1 for details.

   L: this is the Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are in use.

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1.  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.

   rflags:  this 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
      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.  When the E-bit is clear but the N-bit
      is set, an ITR is either echoing a previously requested echo-nonce
      or providing a random nonce.  See section Section 6.3.1 for more
      details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the reachability up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator
      Reach Status Bits are numbered from 0 to n-1 from the right least
      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 is
      reachable. 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 Reach Status Bits
      setting in an encapsulated packet MUST reflect the mapping for the
      EID-prefix that the inner-header source EID address matches.

   S: this is

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the Solicit-Map-Request (SMR) bit.  See section
      Section 6.5.2 for details.

   E: this is the echo-nonce-request bit.  See section Section 6.3.1 for
      details.

   rsvd-flags:  this 6-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.
      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 is set to solicit the other side to send a Map-
      Request containing this nonce.  See section Section 6.5.2 for
      details.

   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 inner header Time to Live
      field.

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

   When doing Re-encapsulated Tunneling:

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

   o  The new OH outer header Type of Service field SHOULD be copied from
      the stripped OH header Type of Service field (with one caveat, see
      below)..
      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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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 Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record count. Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  A 4-byte  An 8-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  The
      security of the "Source EID Address" field.

   ITR-AFI:  Address family LISP mapping protocol depends critically on the
      strength of the "Originating ITR RLOC nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   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.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request, it may
   originate a "verifying Map-Request", addressed to the original ITR.
   If the ETR has a map-cache entry that matches the "piggybacked" EID
   and the RLOC is in the locator-set for the entry, then it may send
   the "verifying Map-Request" to the original Map-Request source.  If
   not, then it MUST send it to the "piggybacked" EID.  Doing this
   forces the "verifying Map-Request" to go through the mapping database
   system to reach the authoritative source of information about that
   EID, guarding against RLOC-spoofing in in the "piggybacked" 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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
      advertising that the site 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 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request
      that is echoed here in this Nonce field of the Map-Reply. 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.

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

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

   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: this bit is reserved for use by the LISP mobile-node design
      documented in [LISP-MN].

   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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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  This 8-byte 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, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply and or that stored in the database
   mapping service does not database system provide any reachability status information for Locators.  This is done outside RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the mapping service.  See Routing Locator Reachability Algorithms described in the
   next section for details. section.

6.3.  Routing Locator Reachability

   There are 4 methods

   Several mechanisms for determining when a Locator is either
   reachable or has become unreachable:

   1.  Locator RLOC reachability is determined by an ETR by examining are currently
   defined:

   1.  An ETR may examine the Loc-Status-Bits in the
       Loc-Reach-Bits from a LISP header of a an
       encapsulated data packet
       which received from an ITR.  If the ETR is provided by
       also acting as an ITR when an and has traffic to return to the original
       ITR encapsulates data.

   2.  Locator unreachability is determined by site, it can use this status information to help select an
       RLOC.

   2.  An ITR by receiving may receive an ICMP Network or ICMP Host Unreachable messages.
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  Locator unreachability  An ITR which participates in the global routing system can also be determined by
       determine that an BGP-enabled
       ITR when there RLOC is down if no prefix matching a Locator address from the BGP RIB. RIB route exists that
       matches the RLOC IP address.

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

   5.  Locator reachability is determined by receiving  An ITR may receive a Map-Reply
       message from a ETR's Locator address ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  Locator reachability can also be determined by receiving packets  When an ETR receives an encapsulated by packet from an ITR, the ITR assigned to
       source RLOC from the locator address. outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   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 an encapsulating ITR closest to the Locators at the source about
   reachability for all ETRs at the site.  The  CE-based ITRs at the source
   site can determine reachability when running their
   IGP at the site.  When relative to each other using the ITRs are deployed on CE routers, typically site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route is injected into the site's IGP from each of the
   ITRs. site IGP.

   o  If an ITR goes down, the CE-PE link goes down, fails or if the upstream link to its PE
   router goes down, the CE router withdraws the fails, its
      default route.  This
   allows route will either time-out or be withdrawn.

   Each ITR can thus observe the other ITRs at presence or lack of a default route
   originated by the site others to determine one of the Locators
   has gone unreachable.

   The Locators Locator Status Bits it sets
   for them.

   RLOCs 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 encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit numbered as 0.  So,
   for bit.  For example, if the ITR with locator an RLOC
   listed as in the 3rd Locator position in of the Map-Reply goes down, down (ordinal value
   2), then all other ITRs at the site will
   have clear the 3rd least significant
   bit from (xxxx x0xx) of the right cleared (the bit that corresponds to
   ordinal 2). Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will look check for a any change in
   the
   Loc-Reach-Bits value. Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to the Locator an RLOC that has just gone
   unreachable. is indicated as
   down.  It can start will only resume using the Locator again when the bit that
   corresponds to RLOC if the Locator goes from 0 corresponding Loc-
   Status-Bit returns to a value of 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 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 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 which transmits traffic from that site or to determine when the site path to site
   traffic is unidirectional so there a specific locator is no ITR returning traffic.

   Note that other
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator reachability mechanisms are being researched
   and 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.

   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 more secure to reach an authoritative ETR,
   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 24-bit Nonce field in the LISP encapsulation header. header and a
   64-bit Nonce field in the LISP control message.  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 have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   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,  Two are the Echo-Noncing and
        RLOC-Probing algorithms which is are documented in this
        specification.  The other two are third is 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.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

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

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

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.

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, Sam Hartman, Michael Hofling, and Pedro Marques.

   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-40--534441808 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-40--534441808 Content-Disposition: attachment; filename=draft-ietf-lisp-04.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-04.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: March 14, 2010 D. Lewis cisco Systems September 10, 2009 Locator/ID Separation Protocol (LISP) (PROPOSED) draft-ietf-lisp-04.txt (NOT SUBMITTED) 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 March 14, 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. Farinacci, et al. Expires March 14, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . 36 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 37 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 39 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 41 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 42 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 43 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 44 7. Router Performance Considerations . . . . . . . . . . . . . . 46 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 47 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 48 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 48 Farinacci, et al. Expires March 14, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 49 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 50 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 51 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 51 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 51 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 53 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 53 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 55 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 55 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 57 12. Security Considerations . . . . . . . . . . . . . . . . . . . 58 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 59 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 14.1. Normative References . . . . . . . . . . . . . . . . . . . 62 14.2. Informative References . . . . . . . . . . . . . . . . . . 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 Farinacci, et al. Expires March 14, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 14, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 14, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 14, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 14, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 statically 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 prepends 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 statically configured. Farinacci, et al. Expires March 14, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 prepends 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 Farinacci, et al. Expires March 14, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 14, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | | Farinacci, et al. Expires March 14, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer 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 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 MAY be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. 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. Farinacci, et al. Expires March 14, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See section Section 6.3.1 for details. L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. E: this is the echo-nonce-request bit. When this bit is set to 1, the N bit must be 1. 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. rflags: this 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 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. When the E-bit is clear but the N-bit is set, an ITR is either echoing a previously requested echo-nonce or providing a random nonce. See section Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least 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: Farinacci, et al. Expires March 14, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o The outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Type of Service field (with one caveat, see below). When doing Re-encapsulated Tunneling: o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer 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. Farinacci, et al. Expires March 14, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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]: Farinacci, et al. Expires March 14, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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. Farinacci, et al. Expires March 14, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires March 14, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 | | + 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. Farinacci, et al. Expires March 14, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D1 |A|M|P|S| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . 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: Farinacci, et al. Expires March 14, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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 Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. 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. Farinacci, et al. Expires March 14, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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. An ITR that is configured with mapping database information (i.e. it Farinacci, et al. Expires March 14, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request, it may originate a "verifying Map-Request", addressed to the original ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map-Request" to the original Map-Request source. If not, then it MUST send it to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" 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=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | 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: Farinacci, et al. Expires March 14, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. See section Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is advertising that the site 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 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of 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. 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. Farinacci, et al. Expires March 14, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 (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: this bit is reserved for use by the LISP mobile-node design documented in [LISP-MN]. 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 Farinacci, et al. Expires March 14, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 14, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 [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 [RFC4302] is: Farinacci, et al. Expires March 14, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 SHA-1 or SHA-128 HMAC. The Map-Register message format is: Farinacci, et al. Expires March 14, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D3 |P| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | 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: This 8-byte 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. Farinacci, et al. Expires March 14, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o A "gleaned" map-cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. Farinacci, et al. Expires March 14, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the 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 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 Farinacci, et al. Expires March 14, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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 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 Farinacci, et al. Expires March 14, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 nonce echo, it sets the 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 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 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. 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. Farinacci, et al. Expires March 14, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 obtain those benefits, especially if the 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. Farinacci, et al. Expires March 14, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 14, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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-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-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-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. Farinacci, et al. Expires March 14, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the 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 ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- prefix uses is the one copied from the SMR 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 Farinacci, et al. Expires March 14, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 the loc-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending 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 more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. Farinacci, et al. Expires March 14, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 14, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, Farinacci, et al. Expires March 14, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 14, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 14, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 14, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 14, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. 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. Farinacci, et al. Expires March 14, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Interoperable implementations have been available since the beginning of 2009. We are trying to converge on a packet format so implementations can converge on the -04 and later drafts. 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. Farinacci, et al. Expires March 14, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts 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. Farinacci, et al. Expires March 14, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. [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. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [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. Farinacci, et al. Expires March 14, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 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), Farinacci, et al. Expires March 14, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-02.txt (work in progress), 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", Farinacci, et al. Expires March 14, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 14, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, and Pedro Marques. 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. Farinacci, et al. Expires March 14, 2010 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 14, 2010 [Page 67] =0C --Apple-Mail-40--534441808 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-40--534441808-- From dino@cisco.com Fri Sep 11 01:18: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 A7AE03A6A46 for ; Fri, 11 Sep 2009 01:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 26USN+q7vFjH for ; Fri, 11 Sep 2009 01:18:58 -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 5B1EE3A69B6 for ; Fri, 11 Sep 2009 01:18:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANOkqUqrR7PE/2dsb2JhbADEJYhGAZAgBYQY X-IronPort-AV: E=Sophos;i="4.44,369,1249257600"; d="scan'208";a="188966026" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 11 Sep 2009 08:19:13 +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 n8B8JDU0016155; Fri, 11 Sep 2009 01:19:13 -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 n8B8JDLW029108; Fri, 11 Sep 2009 08:19:13 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); Fri, 11 Sep 2009 01:19:12 -0700 Received: from [192.168.1.2] ([10.21.72.92]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 01:19:12 -0700 Message-Id: <2736426C-E9AC-49B2-AC64-2DC0A1CA07BF@cisco.com> From: Dino Farinacci To: Damien Saucez In-Reply-To: <4AA93490.9010906@uclouvain.be> 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, 11 Sep 2009 01:19:12 -0700 References: <20090813144010.3BBA26BE556@mercury.lcs.mit.edu> <4AA93490.9010906@uclouvain.be> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 08:19:12.0697 (UTC) FILETIME=[8B5CDA90:01CA32B8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2744; t=1252657153; x=1253521153; 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[#5]=20LISP=20protocol=20versi on |Sender:=20; bh=kkiMaFVv9F+dlqV5DauIe8ttgzBwIp3WofuEiQ1AcMc=; b=ircHYb32XiT79kiVhXNzCYAby+3fBGeH513FaWCGTpWlGMRFpae8eE6RQY ua/PFOEEAzvKUXqg3Vzj0FzWc3t2nocbL7ykMsLu2IkNlbuodrttoqqDx1q/ FhnJ5jERr8; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org, Noel Chiappa , 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: Fri, 11 Sep 2009 08:18:59 -0000 > Well, control-traffic to negotiate the version is a good idea and > definitely has to be studied. However, a version number field is > still helpful. For example, without a version field, gleaning won't > work. Gleaning is used to avoid wasting time waiting for a mapping, > you then send packets without any control-plane version negotiation. > If you have the version in the LISP header, it is easy, you know the > maximum LISP version you can use with the destination. What type of gleaning are you referring to Damien? Data gleaning or gleaning the mapping data from a received Map-Request? > In addition, with the version field, you can even simplify the > "negotiation protocol" to the minimum. A sends a Map-Request for B > (with the maximum version you can support, just in case of crazy pre- > mapping fetching from B) and the Map-Reply from B contains the > maximum version that is supported by B's eTRs. Traffic can then be > sent from A to B. When B has to send traffic to A, it sends a Map- > Request to A and receives the version that is supported by A, B can > then send traffic correctly to A. I don't think it needs to be this complicated. Let me show you with an example. Say you have a map-cache entry that looks like this: 10.0.0.0/8 -> {L1, p1, w50}, {L2, p1, w50} That is what the current mapping database entries look like in xTRs L1 and L2. Now let's say the site wants to change to active-backup rather than active-active. So then both L1 and L2 are changed to have this: 10.0.0.0/8 -> {L1, p1, w50}, {L2, p2, w50} So what happens is that the new mapping is registered with the map- server. So non-cachers that want to talk to this site will get the active-backup mapping. Existing cachers need to change from the active- active mapping to the active-backup mapping. So either L1 or L2 can do the following: (1) When they are RLOC-probed by cachers, they return the active- backup mapping. (2) They each send SMR-based Map-Requests which causes verifying Map- Requests to be received. L1 and L2 then send Map-Replies with the active-backup mapping. or: (3) Wait for the clock-sweep operational time-outs of the map-cache entries. What I am trying to show here is that there is exactly 2 versions. The old one and the new one. If a 3rd mapping was created, there is no reason for cachers to know about the 2nd mapping because the 3rd mapping is the latest and greatest. And you don't care if some cachers have the 1st mapping or the 2nd mapping cached. All they need is to get the 3rd mapping. Therefore version numbers are not needed in the data plane for the control plane. Dino From damien.saucez@uclouvain.be Fri Sep 11 01:44: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 C89343A6897 for ; Fri, 11 Sep 2009 01:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 DQYMHiSCuLjd for ; Fri, 11 Sep 2009 01:44:14 -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 AF94E3A680D for ; Fri, 11 Sep 2009 01:44:13 -0700 (PDT) Received: from [130.104.228.15] (sleipnier-lite.dhcp.info.ucl.ac.be [130.104.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 509451C5E25; Fri, 11 Sep 2009 10:43:59 +0200 (CEST) Message-ID: <4AAA0DCE.7060701@uclouvain.be> Date: Fri, 11 Sep 2009 10:43:58 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Dino Farinacci References: <20090813144010.3BBA26BE556@mercury.lcs.mit.edu> <4AA93490.9010906@uclouvain.be> <2736426C-E9AC-49B2-AC64-2DC0A1CA07BF@cisco.com> In-Reply-To: <2736426C-E9AC-49B2-AC64-2DC0A1CA07BF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 509451C5E25.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org, Noel Chiappa , 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: Fri, 11 Sep 2009 08:44:20 -0000 Dino, Dino Farinacci wrote: >> Well, control-traffic to negotiate the version is a good idea and >> definitely has to be studied. However, a version number field is >> still helpful. For example, without a version field, gleaning won't >> work. Gleaning is used to avoid wasting time waiting for a mapping, >> you then send packets without any control-plane version negotiation. >> If you have the version in the LISP header, it is easy, you know the >> maximum LISP version you can use with the destination. > > What type of gleaning are you referring to Damien? Data gleaning or > gleaning the mapping data from a received Map-Request? > data gleaning. >> In addition, with the version field, you can even simplify the >> "negotiation protocol" to the minimum. A sends a Map-Request for B >> (with the maximum version you can support, just in case of crazy >> pre-mapping fetching from B) and the Map-Reply from B contains the >> maximum version that is supported by B's eTRs. Traffic can then be >> sent from A to B. When B has to send traffic to A, it sends a >> Map-Request to A and receives the version that is supported by A, B >> can then send traffic correctly to A. > Oops, I think that we are not in sync, by version, I mean LISP protocol version, not mapping version. Or, if you prefer, how to know the meaning of each bit without having completely negotiated it before. Cheers, Damien Saucez > I don't think it needs to be this complicated. Let me show you with an > example. > > Say you have a map-cache entry that looks like this: > > 10.0.0.0/8 -> {L1, p1, w50}, {L2, p1, w50} > > That is what the current mapping database entries look like in xTRs L1 > and L2. Now let's say the site wants to change to active-backup rather > than active-active. So then both L1 and L2 are changed to have this: > > 10.0.0.0/8 -> {L1, p1, w50}, {L2, p2, w50} > > So what happens is that the new mapping is registered with the > map-server. So non-cachers that want to talk to this site will get the > active-backup mapping. Existing cachers need to change from the > active-active mapping to the active-backup mapping. So either L1 or L2 > can do the following: > > (1) When they are RLOC-probed by cachers, they return the > active-backup mapping. > (2) They each send SMR-based Map-Requests which causes verifying > Map-Requests to be received. L1 and L2 then send Map-Replies with the > active-backup mapping. > > or: > > (3) Wait for the clock-sweep operational time-outs of the map-cache > entries. > > What I am trying to show here is that there is exactly 2 versions. The > old one and the new one. > > If a 3rd mapping was created, there is no reason for cachers to know > about the 2nd mapping because the 3rd mapping is the latest and > greatest. And you don't care if some cachers have the 1st mapping or > the 2nd mapping cached. All they need is to get the 3rd mapping. > > Therefore version numbers are not needed in the data plane for the > control plane. > > Dino > > From dino@cisco.com Fri Sep 11 01:55: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 768ED3A67B1 for ; Fri, 11 Sep 2009 01:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 hAKlNpM3KNcz for ; Fri, 11 Sep 2009 01:55:04 -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 53D253A6891 for ; Fri, 11 Sep 2009 01:55:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAH+tqUqrR7O6/2dsb2JhbADDeohGAZAgBYI7IQKBOg X-IronPort-AV: E=Sophos;i="4.44,369,1249257600"; d="scan'208";a="203711731" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 11 Sep 2009 08:55:41 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8B8tfdk010331; Fri, 11 Sep 2009 01:55:41 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n8B8tfMZ028570; Fri, 11 Sep 2009 08:55:41 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, 11 Sep 2009 01:55:41 -0700 Received: from [192.168.1.2] ([10.21.72.92]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 01:55:40 -0700 Message-Id: <07BD5CB8-7FE6-4799-BA63-BA05E0399465@cisco.com> From: Dino Farinacci To: Damien Saucez In-Reply-To: <4AAA0DCE.7060701@uclouvain.be> 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, 11 Sep 2009 01:55:40 -0700 References: <20090813144010.3BBA26BE556@mercury.lcs.mit.edu> <4AA93490.9010906@uclouvain.be> <2736426C-E9AC-49B2-AC64-2DC0A1CA07BF@cisco.com> <4AAA0DCE.7060701@uclouvain.be> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 08:55:40.0679 (UTC) FILETIME=[A3806970:01CA32BD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3861; t=1252659341; x=1253523341; 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]=20[#5]=20LISP=20protocol=20versi on |Sender:=20; bh=5BPVd3o67qFbkk9fTeLvTeiBPlMcXbeHNbGp1HPMjsY=; b=ARVeIuzEqe8cQr4hzVkNOb/CY8d4ayAzF5kyY4KDEux1XgkSHQRtirUi+T GKJi0F6p1JQLE43J94gYj+X9qMiqbqZ0/ZhK3wSb49QMIv38AQel/7wKSEmf ct/+y8eLQZ; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org, Noel Chiappa , 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: Fri, 11 Sep 2009 08:55:05 -0000 > Dino, > > Dino Farinacci wrote: >>> Well, control-traffic to negotiate the version is a good idea and >>> definitely has to be studied. However, a version number field is >>> still helpful. For example, without a version field, gleaning >>> won't work. Gleaning is used to avoid wasting time waiting for a >>> mapping, you then send packets without any control-plane version >>> negotiation. If you have the version in the LISP header, it is >>> easy, you know the maximum LISP version you can use with the >>> destination. >> >> What type of gleaning are you referring to Damien? Data gleaning or >> gleaning the mapping data from a received Map-Request? >> > data gleaning. But you can't trust the encapsulator if you don't verify the EID. That is, if you have an encapsulator that uses its own address for sending from an EID that doesn't belong to it, you don't want to return traffic to that locator for the given EID. That encapsulator can put any version number it wanted to in the data packet, so how do you trust it? >>> In addition, with the version field, you can even simplify the >>> "negotiation protocol" to the minimum. A sends a Map-Request for B >>> (with the maximum version you can support, just in case of crazy >>> pre-mapping fetching from B) and the Map-Reply from B contains the >>> maximum version that is supported by B's eTRs. Traffic can then be >>> sent from A to B. When B has to send traffic to A, it sends a Map- >>> Request to A and receives the version that is supported by A, B >>> can then send traffic correctly to A. >> > Oops, I think that we are not in sync, by version, I mean LISP > protocol version, not mapping version. Or, if you prefer, how to > know the meaning of each bit without having completely negotiated it > before. Okay. ;-) You really don't want to negotiate, because that could take multiple packet exchanges. You don't want to be dropping packets for multiple RTT times. But at least you know how I feel about mapping versioning. Cheers, Dino > > Cheers, > > Damien Saucez >> I don't think it needs to be this complicated. Let me show you with >> an example. >> >> Say you have a map-cache entry that looks like this: >> >> 10.0.0.0/8 -> {L1, p1, w50}, {L2, p1, w50} >> >> That is what the current mapping database entries look like in xTRs >> L1 and L2. Now let's say the site wants to change to active-backup >> rather than active-active. So then both L1 and L2 are changed to >> have this: >> >> 10.0.0.0/8 -> {L1, p1, w50}, {L2, p2, w50} >> >> So what happens is that the new mapping is registered with the map- >> server. So non-cachers that want to talk to this site will get the >> active-backup mapping. Existing cachers need to change from the >> active-active mapping to the active-backup mapping. So either L1 or >> L2 can do the following: >> >> (1) When they are RLOC-probed by cachers, they return the active- >> backup mapping. >> (2) They each send SMR-based Map-Requests which causes verifying >> Map-Requests to be received. L1 and L2 then send Map-Replies with >> the active-backup mapping. >> >> or: >> >> (3) Wait for the clock-sweep operational time-outs of the map-cache >> entries. >> >> What I am trying to show here is that there is exactly 2 versions. >> The old one and the new one. >> >> If a 3rd mapping was created, there is no reason for cachers to >> know about the 2nd mapping because the 3rd mapping is the latest >> and greatest. And you don't care if some cachers have the 1st >> mapping or the 2nd mapping cached. All they need is to get the 3rd >> mapping. >> >> Therefore version numbers are not needed in the data plane for the >> control plane. >> >> Dino >> >> > From damien.saucez@uclouvain.be Fri Sep 11 02:12: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 CD2CD3A6957 for ; Fri, 11 Sep 2009 02:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 0PaM6a31bG8V for ; Fri, 11 Sep 2009 02:12:28 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 833253A6924 for ; Fri, 11 Sep 2009 02:12:28 -0700 (PDT) Received: from [130.104.228.15] (sleipnier-lite.dhcp.info.ucl.ac.be [130.104.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 42829E900E; Fri, 11 Sep 2009 11:12:18 +0200 (CEST) Message-ID: <4AAA1470.4010009@uclouvain.be> Date: Fri, 11 Sep 2009 11:12:16 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Dino Farinacci References: <20090813144010.3BBA26BE556@mercury.lcs.mit.edu> <4AA93490.9010906@uclouvain.be> <2736426C-E9AC-49B2-AC64-2DC0A1CA07BF@cisco.com> <4AAA0DCE.7060701@uclouvain.be> <07BD5CB8-7FE6-4799-BA63-BA05E0399465@cisco.com> In-Reply-To: <07BD5CB8-7FE6-4799-BA63-BA05E0399465@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 42829E900E.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org, Noel Chiappa , 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: Fri, 11 Sep 2009 09:12:29 -0000 Dino Farinacci wrote: >> Dino, >> >> Dino Farinacci wrote: >>>> Well, control-traffic to negotiate the version is a good idea and >>>> definitely has to be studied. However, a version number field is >>>> still helpful. For example, without a version field, gleaning won't >>>> work. Gleaning is used to avoid wasting time waiting for a mapping, >>>> you then send packets without any control-plane version >>>> negotiation. If you have the version in the LISP header, it is >>>> easy, you know the maximum LISP version you can use with the >>>> destination. >>> >>> What type of gleaning are you referring to Damien? Data gleaning or >>> gleaning the mapping data from a received Map-Request? >>> >> data gleaning. > > But you can't trust the encapsulator if you don't verify the EID. That > is, if you have an encapsulator that uses its own address for sending > from an EID that doesn't belong to it, you don't want to return > traffic to that locator for the given EID. > > That encapsulator can put any version number it wanted to in the data > packet, so how do you trust it? > agree, versioning is a hint (like Reach-bits were). >>>> In addition, with the version field, you can even simplify the >>>> "negotiation protocol" to the minimum. A sends a Map-Request for B >>>> (with the maximum version you can support, just in case of crazy >>>> pre-mapping fetching from B) and the Map-Reply from B contains the >>>> maximum version that is supported by B's eTRs. Traffic can then be >>>> sent from A to B. When B has to send traffic to A, it sends a >>>> Map-Request to A and receives the version that is supported by A, B >>>> can then send traffic correctly to A. >>> >> Oops, I think that we are not in sync, by version, I mean LISP >> protocol version, not mapping version. Or, if you prefer, how to know >> the meaning of each bit without having completely negotiated it before. > > Okay. ;-) > > You really don't want to negotiate, because that could take multiple > packet exchanges. You don't want to be dropping packets for multiple > RTT times. > > But at least you know how I feel about mapping versioning. > That's been clear for a long time ;-) Regards, Damien Saucez > Cheers, > Dino > >> >> Cheers, >> >> Damien Saucez >>> I don't think it needs to be this complicated. Let me show you with >>> an example. >>> >>> Say you have a map-cache entry that looks like this: >>> >>> 10.0.0.0/8 -> {L1, p1, w50}, {L2, p1, w50} >>> >>> That is what the current mapping database entries look like in xTRs >>> L1 and L2. Now let's say the site wants to change to active-backup >>> rather than active-active. So then both L1 and L2 are changed to >>> have this: >>> >>> 10.0.0.0/8 -> {L1, p1, w50}, {L2, p2, w50} >>> >>> So what happens is that the new mapping is registered with the >>> map-server. So non-cachers that want to talk to this site will get >>> the active-backup mapping. Existing cachers need to change from the >>> active-active mapping to the active-backup mapping. So either L1 or >>> L2 can do the following: >>> >>> (1) When they are RLOC-probed by cachers, they return the >>> active-backup mapping. >>> (2) They each send SMR-based Map-Requests which causes verifying >>> Map-Requests to be received. L1 and L2 then send Map-Replies with >>> the active-backup mapping. >>> >>> or: >>> >>> (3) Wait for the clock-sweep operational time-outs of the map-cache >>> entries. >>> >>> What I am trying to show here is that there is exactly 2 versions. >>> The old one and the new one. >>> >>> If a 3rd mapping was created, there is no reason for cachers to know >>> about the 2nd mapping because the 3rd mapping is the latest and >>> greatest. And you don't care if some cachers have the 1st mapping or >>> the 2nd mapping cached. All they need is to get the 3rd mapping. >>> >>> Therefore version numbers are not needed in the data plane for the >>> control plane. >>> >>> Dino >>> >>> >> > From tme@americafree.tv Fri Sep 11 04:46: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 2ECB73A6A1A for ; Fri, 11 Sep 2009 04:46:51 -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 adl-zib20SRo for ; Fri, 11 Sep 2009 04:46:50 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 0852A3A6821 for ; Fri, 11 Sep 2009 04:46:50 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id D164A4B357BF; Fri, 11 Sep 2009 07:47:26 -0400 (EDT) Message-Id: <57746047-7A61-48CD-953D-2D6AD7E7C780@americafree.tv> From: Marshall Eubanks To: Dino Farinacci In-Reply-To: <1600AB62-6155-48B0-A086-C63FFE6F075D@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: Fri, 11 Sep 2009 07:47:25 -0400 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> <4AA93578.9060102@cisco.com> <1600AB62-6155-48B0-A086-C63FFE6F075D@cisco.com> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] text suggestion for random nonces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 11:46:51 -0000 On Sep 11, 2009, at 1:22 AM, Dino Farinacci wrote: > I will include Sam's text with a SHOULD. Since the attack is going > to be rare with a 64-bit guess, any random number generator will be > fairly good IMO. But we can suggest the RFC 4086. If you are going to use a should, I would provide more advice for the non-compliant - how about adding : > > I'll update the diffs with this text. Thanks all. > > Dino > > On Sep 10, 2009, at 10:20 AM, Eliot Lear wrote: > >> On 9/10/09 6:50 PM, Sam Hartman wrote: >>> I'd do something like. >>> >>> The security of the LISP mapping protocol depends critically on the >>> strength of the nonce in the map request and reply messages. These >>> nonces MUST be generated by a properly seeded pseudo-random (or >>> strong >>> random) source. Nonces MUST NOT be generated by easy to guess methods such as a simple sequence number or system time code. >>> See RFC 4086 for advice on generating >>> security-sensitive random data. >>> >>> I think LISP wants a pseudo-random source because a strong random >>> source is with current hardware going to be highly impractical >>> from a >>> performance standpoint. RFC 4086 should be a normative reference. I agree with that. My understanding is that on some systems the supply of truly random bits is pretty limited. Also, can someone tell me why "pre-play" attacks are not an issue ? (See Sections 4 and 10 of draft-ietf-manet-smf-09; Section 6.4 of RFC 4418 discusses measures against the more familiar replay attacks.) In this context, a pre-play attack would be a response from an attacker to a Map-request that arrives before the true response from the EID. If I am running a multi-mega-node botnet, why shouldn't I have my bots listen for passing traffic, find any LISP Map Requests, and respond immediately, thereby possibly preempting the true EID and if so allowing for the same sorts of mischief as in Sam and Margaret's nonce guessing attack ? This would work any time my bots were on a large flat LAN or on a wireless network with either the EID or the ITR. Particularly if my bot was on the network with the ITR, the false response (with the correct nonce) could easily arrive before the true one. As UDP is unreliable, my response might even be the only one that arrived. I could probably also spoof the EID IP address and adjust TTLs to mimic the true response. It seems to me that this could be detected easily (the ITR starts a timer with a window at the sending of each Map-request, listens for duplicate but disagreeing Mao-replies during the duration of the window) but mere rejection of duplicate Nonce responses would allow for an easy LISP DOS (as the good Map-reply would be thrown out with the bad). I don't see any way to stop this without a shared secret. If there is a shared secret, then the treatment of the Nonce should probably be changed (ITR sends the Nonce, EID replies with the Nonce hashed together with the shared secret). Regards Marshall >>> >> >> This seems like good text, Sam. It's amazing how many times >> implementations get that stuff wrong (and it's so easy to get wrong). >> >> Eliot >> _______________________________________________ >> 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 Fri Sep 11 06:06: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 206593A6A16 for ; Fri, 11 Sep 2009 06:06:00 -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 JMqrIO0x-RBC for ; Fri, 11 Sep 2009 06:05:59 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4E3293A69A2 for ; Fri, 11 Sep 2009 06:05:59 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C1E8A51CD; Fri, 11 Sep 2009 09:06:15 -0400 (EDT) To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <14EB3D92-A53B-4EF2-ietf-AC25-4479C7D19B16@cisco.com> From: Sam Hartman Date: Fri, 11 Sep 2009 09:06:15 -0400 In-Reply-To: <14EB3D92-A53B-4EF2-AC25-4479C7D19B16@cisco.com> (Dino Farinacci's message of "Mon\, 7 Sep 2009 17\:15\:25 -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 X-Mailman-Approved-At: Fri, 11 Sep 2009 06:18:07 -0700 Cc: lisp@ietf.org Subject: [lisp] #2: IPsec or just IPsec headers; sha-1 size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 13:06:00 -0000 >>>>> "Dino" == Dino Farinacci writes: >> Dino> * Indicate SHA1 can be used as well for Map-Registers. >> >> Note that the text is still broken. The IPsec sha-1 is 96-bits >> long not 128-bits long. Also, according to some software I'm >> using but not verified with the spec, 0 is an illegal SPI. >> However this change is small and is supported by WG discussion. Dino> There is no reference to SHA-1 being 128 bits. Or do you Dino> mean the reference to SHA-128 should be changed to SHA-256. You claim that the value in the AH header for the ICV (in RFC 4302 terms) is 16 bytes long. AS far as I can tell reading 4302 and 2404 it's 96 bits long. Dino> We do not say we use IPsec in the document. We say we use Dino> the IPsec header format (i.e. AH). That's not going to work. You either need to use IPsec or not; you cannot borrow IPsec headers and codepoints without actually using IPsec. There are significant process problems with this: this is the sort of issue that created the T-MPLS mess between the ITU and IETF. More importantly though, it means I cannot use LISP and IPsec on the same system or they stop on each other. From mrw@sandstorm.net Fri Sep 11 06: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 97EE03A6894 for ; Fri, 11 Sep 2009 06:21:27 -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 LbCcZiXNCu-V for ; Fri, 11 Sep 2009 06:21:26 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id ACC283A6892 for ; Fri, 11 Sep 2009 06:21:26 -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 n8BDLxJj016934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Sep 2009 09:21:59 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <08E2E969-CE86-4755-B51C-307A4C80A347@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: Fri, 11 Sep 2009 09:21:59 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> <4AA8F6EE.7000702@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) 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: Fri, 11 Sep 2009 13:21:27 -0000 Hi Dino, On Sep 11, 2009, at 2:19 AM, Dino Farinacci wrote: > > UDP Checksum: this field MAY be transmitted as zero by an ITR for > either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. > When a > packet with a zero UDP checksum is received by an ETR, the ETR > MUST accept the packet for decapsulation. When an ITR > transmits a > non-zero value for the UDP checksum, it MUST send a correctly > computed value in this field. When an ETR receives a packet with > a non-zero UDP checksum, it MAY choose to verify the checksum > value. If it chooses to perform such verification, and the > verification fails, the packet MUST be silently dropped. If the > ETR chooses not to perform the verification, or performs the > verification successfully, the packet MUST be accepted for > decapsulation. > > 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. The first paragraph is fine. I'd prefer to drop the second paragraph, as it isn't really possible for us to catalog every buggy implementation that might have bad implications for LISP. If the IETF does want to publish this operational information, I think this would be better discussed in a middle-box operations document where its implications could be discussed more broadly. If people insist on keeping this paragraph, though, I'd prefer: Note, there are some currently deployed, improperly implemented IPv4 NAT boxes that will recalculate a zero UDP checksum and overwrite it with a correct UDP checksum value. LISP implementors and operators may wish to consider the existence of this equipment in their implementation and deployment decisions regarding UDP checksums. This would make it clear that we are pointing out something about existing operational networks, and that we are neither condoning nor advocating NAT boxes that behave this way. Margaret From dino@cisco.com Fri Sep 11 09:10: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 610A53A6A4C for ; Fri, 11 Sep 2009 09:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 HuHxZ6FBAX2W for ; Fri, 11 Sep 2009 09:10:13 -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 B8FB828C1A2 for ; Fri, 11 Sep 2009 09:10:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,371,1249257600"; d="scan'208";a="240567719" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 11 Sep 2009 16:10:45 +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 n8BGAjNQ011681; Fri, 11 Sep 2009 09:10:45 -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 n8BGAiJQ001682; Fri, 11 Sep 2009 16:10:44 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); Fri, 11 Sep 2009 09:10:44 -0700 Received: from [192.168.1.2] ([10.21.75.162]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 09:10:43 -0700 Message-Id: <7190D2CC-A7BC-435C-BC69-87F4003A7260@cisco.com> From: Dino Farinacci To: Marshall Eubanks In-Reply-To: <57746047-7A61-48CD-953D-2D6AD7E7C780@americafree.tv> 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, 11 Sep 2009 09:10:43 -0700 References: <20090909040029.45A236BE60C@mercury.lcs.mit.edu> <717F91B4-9E76-4204-A70A-CB5E8EBAD2A3@sandstorm.net> <44B4743A-32FA-401E-99BB-A026A6059243@sandstorm.net> <75cb24520909092033p7d7cec74g3bb5240c4ac3b542@mail.gmail.com> <8E3B561B-4650-452E-9E51-AB53EBFACE62@cisco.com> <4AA93578.9060102@cisco.com> <1600AB62-6155-48B0-A086-C63FFE6F075D@cisco.com> <57746047-7A61-48CD-953D-2D6AD7E7C780@americafree.tv> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 16:10:43.0841 (UTC) FILETIME=[6A32D710:01CA32FA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4164; t=1252685445; x=1253549445; 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]=20text=20suggestion=20for=20rand om=20nonces |Sender:=20; bh=8dqq1uCTwWYj7TTDW0i0Z1KDmFkGKbPQvCZEEc6PGSo=; b=A62GI9nYor0kxWgwuuEJg+XRd+PGWZc8UmGIuUAan+kJElQJUY2XxRuyPV Ys/CfVtrpzezqN930q5WthYYEuoiJ/IxDMDUKncVkQtatGl0nFvchQi8+WjS vV1/OpSaCT; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Noel Chiappa , lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] text suggestion for random nonces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 16:10:16 -0000 I would prefer to keep the text the way it is Marshall. We have addressed Chris' comment which was to not use a dumb or predictable random number generator, like a sequential allocator or a non-granular data-stamp. I would like to leave it to the implementors to decide what type of random number generator to use. But having a suggested reference is good for implementators to evaluate. Dino On Sep 11, 2009, at 4:47 AM, Marshall Eubanks wrote: > > On Sep 11, 2009, at 1:22 AM, Dino Farinacci wrote: > >> I will include Sam's text with a SHOULD. Since the attack is going >> to be rare with a 64-bit guess, any random number generator will be >> fairly good IMO. But we can suggest the RFC 4086. > > If you are going to use a should, I would provide more advice for > the non-compliant - how about adding : > >> >> I'll update the diffs with this text. Thanks all. >> >> Dino >> >> On Sep 10, 2009, at 10:20 AM, Eliot Lear wrote: >> >>> On 9/10/09 6:50 PM, Sam Hartman wrote: >>>> I'd do something like. >>>> >>>> The security of the LISP mapping protocol depends critically on the >>>> strength of the nonce in the map request and reply messages. These >>>> nonces MUST be generated by a properly seeded pseudo-random (or >>>> strong >>>> random) source. > > Nonces MUST NOT be generated by easy to guess methods such as a > simple sequence number or system time code. > >>>> See RFC 4086 for advice on generating >>>> security-sensitive random data. >>>> >>>> I think LISP wants a pseudo-random source because a strong random >>>> source is with current hardware going to be highly impractical >>>> from a >>>> performance standpoint. RFC 4086 should be a normative reference. > > I agree with that. My understanding is that on some systems the > supply of truly random bits is pretty limited. > > Also, can someone tell me why "pre-play" attacks are not an issue ? > (See Sections 4 and 10 of draft-ietf-manet-smf-09; Section 6.4 of > RFC 4418 discusses measures against the more familiar replay > attacks.) In this context, a pre-play attack would be a response > from an attacker to a Map-request that arrives before the true > response from the EID. > > If I am running a multi-mega-node botnet, why shouldn't I have my > bots listen for passing traffic, find any LISP Map Requests, and > respond immediately, thereby possibly preempting the true EID and if > so allowing for the same sorts of mischief as in Sam and Margaret's > nonce guessing attack ? This would work any time my bots were on a > large flat LAN or on a wireless network with either the EID or the > ITR. Particularly if my bot was on the network with the ITR, the > false response (with the correct nonce) could easily arrive before > the true one. As UDP is unreliable, my response might even be the > only one that arrived. I could probably also spoof the EID IP > address and adjust TTLs to mimic the true response. > > It seems to me that this could be detected easily (the ITR starts a > timer with a window at the sending of each Map-request, listens for > duplicate but disagreeing Mao-replies during the duration of the > window) but mere rejection of duplicate Nonce responses would allow > for an easy LISP DOS (as the good Map-reply would be thrown out with > the bad). > > I don't see any way to stop this without a shared secret. If there > is a shared secret, then the treatment of the Nonce should probably > be changed (ITR sends the Nonce, EID replies with the Nonce hashed > together with the shared secret). > > Regards > Marshall > > >>>> >>> >>> This seems like good text, Sam. It's amazing how many times >>> implementations get that stuff wrong (and it's so easy to get >>> wrong). >>> >>> Eliot >>> _______________________________________________ >>> 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 dino@cisco.com Fri Sep 11 09:11: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 DFFF43A6AF4 for ; Fri, 11 Sep 2009 09:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 OqRH9ejS609O for ; Fri, 11 Sep 2009 09:11: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 1720D3A6AC0 for ; Fri, 11 Sep 2009 09:11:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACcUqkqrR7PE/2dsb2JhbADFIYhIAZAJBYQY X-IronPort-AV: E=Sophos;i="4.44,371,1249257600"; d="scan'208";a="189079052" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 11 Sep 2009 16:12:17 +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 n8BGCHvY014984; Fri, 11 Sep 2009 09:12:17 -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 n8BGCHwj017375; Fri, 11 Sep 2009 16:12:17 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); Fri, 11 Sep 2009 09:12:17 -0700 Received: from [192.168.1.2] ([10.21.75.162]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 09:12:16 -0700 Message-Id: <78C38CB9-E5F1-4DB6-971F-24F84872D2A8@cisco.com> From: Dino Farinacci To: Damien Saucez In-Reply-To: <4AAA1470.4010009@uclouvain.be> 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, 11 Sep 2009 09:12:16 -0700 References: <20090813144010.3BBA26BE556@mercury.lcs.mit.edu> <4AA93490.9010906@uclouvain.be> <2736426C-E9AC-49B2-AC64-2DC0A1CA07BF@cisco.com> <4AAA0DCE.7060701@uclouvain.be> <07BD5CB8-7FE6-4799-BA63-BA05E0399465@cisco.com> <4AAA1470.4010009@uclouvain.be> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 16:12:17.0199 (UTC) FILETIME=[A1D823F0:01CA32FA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1317; t=1252685537; x=1253549537; 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[#5]=20LISP=20protocol=20versi on |Sender:=20; bh=dcUzmwytrebnUwPQFKm5gsyCknnWDqr4gD80H5yuTds=; b=EcGi45MBgXgLf7NcxeoLiaGZdnoeqz+ogCUI519tPhwoCI4L357JlW/NV5 nqniPpKJfOHgaFUJtYiNaRtdzwUlLUChijj8FwyMRKR2fzFUK7DNxPnDXvl3 vvq+AeNOeU; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org, Noel Chiappa , 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: Fri, 11 Sep 2009 16:11:41 -0000 >>>>> In addition, with the version field, you can even simplify the >>>>> "negotiation protocol" to the minimum. A sends a Map-Request for >>>>> B (with the maximum version you can support, just in case of >>>>> crazy pre-mapping fetching from B) and the Map-Reply from B >>>>> contains the maximum version that is supported by B's eTRs. >>>>> Traffic can then be sent from A to B. When B has to send traffic >>>>> to A, it sends a Map-Request to A and receives the version that >>>>> is supported by A, B can then send traffic correctly to A. >>>> >>> Oops, I think that we are not in sync, by version, I mean LISP >>> protocol version, not mapping version. Or, if you prefer, how to >>> know the meaning of each bit without having completely negotiated >>> it before. >> >> Okay. ;-) >> >> You really don't want to negotiate, because that could take >> multiple packet exchanges. You don't want to be dropping packets >> for multiple RTT times. >> >> But at least you know how I feel about mapping versioning. >> > That's been clear for a long time ;-) I want to make it perfectly clear, I still would like to see studies on this. Because we can all learn and understand the value/cost tradeoffs. I think what you guys are doing is a great effort! Dino From dino@cisco.com Fri Sep 11 09:14: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 A91863A6922 for ; Fri, 11 Sep 2009 09:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 loUjMBlpWRhH for ; Fri, 11 Sep 2009 09:14:52 -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 E4C263A682E for ; Fri, 11 Sep 2009 09:14:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACcUqkqrR7O6/2dsb2JhbADFIYhIAZAJBYQYimU X-IronPort-AV: E=Sophos;i="4.44,371,1249257600"; d="scan'208";a="189080250" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 11 Sep 2009 16:15:29 +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 n8BGFThi002544; Fri, 11 Sep 2009 09:15:29 -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 n8BGFTIu012921; Fri, 11 Sep 2009 16:15:29 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, 11 Sep 2009 09:15:29 -0700 Received: from [192.168.1.2] ([10.21.75.162]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 09:15:29 -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 v936) Date: Fri, 11 Sep 2009 09:15:28 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <14EB3D92-A53B-4EF2-ietf-AC25-4479C7D19B16@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 16:15:29.0224 (UTC) FILETIME=[144CD480:01CA32FB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=642; t=1252685729; x=1253549729; 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#2=3A=20IPsec=20or=20just=20IPsec=20hea ders=3B=20sha-1=20size |Sender:=20; bh=ZLmHwFdbC5Ir7ooVjQKwS2dtURINCzBfLM33LVYiFGg=; b=xNEwnoXUUmUvDwua/cOTsxk4y17hpmM99rHy8GtZRvZqaxq9yTWP+tYwDl CyDg2v4KHXc/owJrIaeI2ekuve5Z64vZiVgeKtmVP11cTTP8Kh6mVlIdXl13 VzQgM5ZdzI; 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] #2: IPsec or just IPsec headers; sha-1 size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 16:14:52 -0000 > That's not going to work. You either need to use IPsec or not; you > cannot borrow IPsec headers and codepoints without actually using > IPsec. There are significant process problems with this: this is the So what does this mean specifically? If the spec says Map-Registers use the AH header format from the IPsec spec what does "using IPsec" mean from your point of view? > sort of issue that created the T-MPLS mess between the ITU and IETF. > More importantly though, it means I cannot use LISP and IPsec on the > same system or they stop on each other. Why does it mean that. You have to explain more Sam. Dino From dino@cisco.com Fri Sep 11 09:58: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 1C7E93A6834 for ; Fri, 11 Sep 2009 09:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 XBtudP8klWCB for ; Fri, 11 Sep 2009 09:58: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 170283A6813 for ; Fri, 11 Sep 2009 09:58:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACsfqkqrR7O6/2dsb2JhbADFH4hIAZAMBYI7gV2BWQ X-IronPort-AV: E=Sophos;i="4.44,371,1249257600"; d="scan'208";a="240588591" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 11 Sep 2009 16:58:56 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8BGwt6N023309; Fri, 11 Sep 2009 09:58:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n8BGwtOT027732; Fri, 11 Sep 2009 16:58:55 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); Fri, 11 Sep 2009 09:58:54 -0700 Received: from [192.168.1.2] ([10.21.75.162]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 09:58:54 -0700 Message-Id: <00F147AF-A9D7-41DE-83A9-83892CE42E42@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <08E2E969-CE86-4755-B51C-307A4C80A347@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: Fri, 11 Sep 2009 09:58:52 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> <4AA8F6EE.7000702@joelhalpern.com> <08E2E969-CE86-4755-B51C-307A4C80A347@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 16:58:54.0476 (UTC) FILETIME=[2526BCC0:01CA3301] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2654; t=1252688335; x=1253552335; 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=Js4OqE5ixDlOVeLEqDDd+A6q8RdXxvzh0540xL0Y38A=; b=XHIMVqCaqD7u4ekqyKJovJheEkRB1BQoijJzM3XABaJkudu31TWqwSkjIJ 9vyz8vYkw8nXWpNchFd/viHW81byzihkLiQWXQG6lfj5CYsQ8RXDnjyxGoMY u4nHNwgtoa; 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: Fri, 11 Sep 2009 16:58:19 -0000 > Hi Dino, > > On Sep 11, 2009, at 2:19 AM, Dino Farinacci wrote: >> >> UDP Checksum: this field MAY be transmitted as zero by an ITR for >> either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. >> When a >> packet with a zero UDP checksum is received by an ETR, the ETR >> MUST accept the packet for decapsulation. When an ITR >> transmits a >> non-zero value for the UDP checksum, it MUST send a correctly >> computed value in this field. When an ETR receives a packet with >> a non-zero UDP checksum, it MAY choose to verify the checksum >> value. If it chooses to perform such verification, and the >> verification fails, the packet MUST be silently dropped. If the >> ETR chooses not to perform the verification, or performs the >> verification successfully, the packet MUST be accepted for >> decapsulation. >> >> 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. > > The first paragraph is fine. > > I'd prefer to drop the second paragraph, as it isn't really possible > for us to catalog every buggy implementation that might have bad > implications for LISP. If the IETF does want to publish this > operational information, I think this would be better discussed in a > middle-box operations document where its implications could be > discussed more broadly. Well you mentioned in a previous email that if we were going to keep it to make it a separate paragraph. I wanted to keep it because it gives another justification why ETRs MAY ignore the UDP checksum. > If people insist on keeping this paragraph, though, I'd prefer: > > Note, there are some currently deployed, improperly implemented IPv4 > NAT boxes that will recalculate a Well I don't think it is necessarily improper. If NATs are changing IP addresses in UDP headers they have to change the UDP checksum to reflect the address change. I'd rather not put in text that judges this. > zero UDP checksum and overwrite it with a correct UDP checksum > value. LISP implementors and operators may wish to consider the > existence of this equipment in their implementation and deployment > decisions regarding UDP checksums. > > This would make it clear that we are pointing out something about > existing operational networks, and that we are neither condoning nor > advocating NAT boxes that behave this way. I believe the existing paragraph conveys this too. Dino > > Margaret > > > > > From mrw@sandstorm.net Fri Sep 11 10: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 10AEA28C1BC for ; Fri, 11 Sep 2009 10:09:46 -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 B05xHRifYEki for ; Fri, 11 Sep 2009 10:09:45 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 258A33A68B9 for ; Fri, 11 Sep 2009 10:09:44 -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 n8BH9wvu028889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Sep 2009 13:09:59 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <00F147AF-A9D7-41DE-83A9-83892CE42E42@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: Fri, 11 Sep 2009 13:09:58 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> <4AA8F6EE.7000702@joelhalpern.com> <08E2E969-CE86-4755-B51C-307A4C80A347@sandstorm.net> <00F147AF-A9D7-41DE-83A9-83892CE42E42@cisco.com> X-Mailer: Apple Mail (2.935.3) 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: Fri, 11 Sep 2009 17:09:46 -0000 On Sep 11, 2009, at 12:58 PM, Dino Farinacci wrote: >> >> Note, there are some currently deployed, improperly implemented >> IPv4 NAT boxes that will recalculate a > > Well I don't think it is necessarily improper. If NATs are changing > IP addresses in UDP headers they have to change the UDP checksum to > reflect the address change. No, they don't. They should incrementally update the checksum, so it remains an end-to-end integrity protection mechanism. If they write a correct checksum over a zero value, they are giving the illusion that the packet was end-to-end protected when it was not, which might be problematic for some applications. Even worse, if they re-write non- zero values with new, correct values, they could be incorrectly asserting that the packet has not been corrupted when it already was. > > I'd rather not put in text that judges this. > > >> zero UDP checksum and overwrite it with a correct UDP checksum >> value. LISP implementors and operators may wish to consider the >> existence of this equipment in their implementation and deployment >> decisions regarding UDP checksums. >> >> This would make it clear that we are pointing out something about >> existing operational networks, and that we are neither condoning >> nor advocating NAT boxes that behave this way. > > I believe the existing paragraph conveys this too. The existing paragraph says that NATs _may_ do this, as though it is okay (in the LISP universe) for them to do so, which is not something that I think we should. At the very least, you should change the sentence to say that they _some currently deployed IPv4 NATs do_ this (not that they may do it), so that it is clear we are talking about an operational issue with currently deployed hardware. The existing paragraph also doesn't make it clear that the NATs overwrite the checksum with a correct UDP checksum value for the packet they are transmitting, which lead to a lot of confusion in the LISP WG earlier. Margaret From dino@cisco.com Fri Sep 11 10:29: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 ED07D28C1B7 for ; Fri, 11 Sep 2009 10:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 v3IWTyGMv5q0 for ; Fri, 11 Sep 2009 10:29:21 -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 01C3928C202 for ; Fri, 11 Sep 2009 10:29:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADMmqkqrR7PD/2dsb2JhbADFHohIAZASBYQYgVk X-IronPort-AV: E=Sophos;i="4.44,371,1249257600"; d="scan'208";a="203882262" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 11 Sep 2009 17:29:58 +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 n8BHTwgq031118; Fri, 11 Sep 2009 10:29:58 -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 n8BHTweA029625; Fri, 11 Sep 2009 17:29:58 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, 11 Sep 2009 10:29:58 -0700 Received: from [192.168.1.2] ([10.21.75.162]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 10:29:58 -0700 Message-Id: <65E7853A-1868-4BDC-902B-4E08B352BBF5@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 v936) Date: Fri, 11 Sep 2009 10:29:57 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> <4AA8F6EE.7000702@joelhalpern.com> <08E2E969-CE86-4755-B51C-307A4C80A347@sandstorm.net> <00F147AF-A9D7-41DE-83A9-83892CE42E42@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 17:29:58.0281 (UTC) FILETIME=[7C10CF90:01CA3305] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2444; t=1252690198; x=1253554198; 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]=20Suggested=20UDP=20checksum=20t ext |Sender:=20; bh=h+qf31hxxnP8e0pA+qCGyApb9WQFEzIY3hjizdsdj2A=; b=SA4Iv5SugbyeltsviNruLD080/9yNFE/c01JP2G0PYOkLfed55WiF6URUl HERJfGC5H/vxyDa3tUumgRkvb/ERzvmws8tEOBBOAIdVpMvUgzSm5X/pULyD mIqfbr9hDL; 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] 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: Fri, 11 Sep 2009 17:29:22 -0000 > On Sep 11, 2009, at 12:58 PM, Dino Farinacci wrote: >>> >>> Note, there are some currently deployed, improperly implemented >>> IPv4 NAT boxes that will recalculate a >> >> Well I don't think it is necessarily improper. If NATs are changing >> IP addresses in UDP headers they have to change the UDP checksum to >> reflect the address change. > > No, they don't. They should incrementally update the checksum, so > it remains an end-to-end integrity protection mechanism. If they > write a correct checksum over a zero value, they are giving the > illusion that the packet was end-to-end protected when it was not, > which might be problematic for some applications. Even worse, if > they re-write non-zero values with new, correct values, they could > be incorrectly asserting that the packet has not been corrupted when > it already was. We all know NATs are evil. And we shouldn't create any more NAT solutions. ;-) >> I'd rather not put in text that judges this. >> >> >>> zero UDP checksum and overwrite it with a correct UDP checksum >>> value. LISP implementors and operators may wish to consider the >>> existence of this equipment in their implementation and deployment >>> decisions regarding UDP checksums. >>> >>> This would make it clear that we are pointing out something about >>> existing operational networks, and that we are neither condoning >>> nor advocating NAT boxes that behave this way. >> >> I believe the existing paragraph conveys this too. > > The existing paragraph says that NATs _may_ do this, as though it is > okay (in the LISP universe) for them to do so, which is not > something that I think we should. At the very least, you should > change the sentence to say that they _some currently deployed IPv4 > NATs do_ this (not that they may do it), so that it is clear we are > talking about an operational issue with currently deployed hardware. > > The existing paragraph also doesn't make it clear that the NATs > overwrite the checksum with a correct UDP checksum value for the > packet they are transmitting, which lead to a lot of confusion in > the LISP WG earlier. Rather than saying more about this. I will remove the paragraph. The discussion it too complicated to me and the text doesn't add enough value. If the first parapgraph is conformed to, then we can deal with NATs. Dino From tme@americafree.tv Fri Sep 11 10:33: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 CB00628C19A for ; Fri, 11 Sep 2009 10:33:51 -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 dh2xhDXQE081 for ; Fri, 11 Sep 2009 10:33:50 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id C10DB28C1FC for ; Fri, 11 Sep 2009 10:33:50 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 2DF644B3DBCE; Fri, 11 Sep 2009 13:34:28 -0400 (EDT) Message-Id: 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: Fri, 11 Sep 2009 13:34:27 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> <4AA8F6EE.7000702@joelhalpern.com> <08E2E969-CE86-4755-B51C-307A4C80A347@sandstorm.net> <00F147AF-A9D7-41DE-83A9-83892CE42E42@cisco.com> X-Mailer: Apple Mail (2.936) 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: Fri, 11 Sep 2009 17:33:51 -0000 On Sep 11, 2009, at 1:09 PM, Margaret Wasserman wrote: > > On Sep 11, 2009, at 12:58 PM, Dino Farinacci wrote: >>> >>> Note, there are some currently deployed, improperly implemented >>> IPv4 NAT boxes that will recalculate a >> >> Well I don't think it is necessarily improper. If NATs are changing >> IP addresses in UDP headers they have to change the UDP checksum to >> reflect the address change. > > No, they don't. They should incrementally update the checksum, so > it remains an end-to-end integrity protection mechanism. If they > write a correct checksum over a zero value, they are giving the > illusion that the packet was end-to-end protected when it was not, > which might be problematic for some applications. Even worse, if > they re-write non-zero values with new, correct values, they could > be incorrectly asserting that the packet has not been corrupted when > it already was. >> >> I'd rather not put in text that judges this. >> >> >>> zero UDP checksum and overwrite it with a correct UDP checksum >>> value. LISP implementors and operators may wish to consider the >>> existence of this equipment in their implementation and deployment >>> decisions regarding UDP checksums. >>> >>> This would make it clear that we are pointing out something about >>> existing operational networks, and that we are neither condoning >>> nor advocating NAT boxes that behave this way. >> >> I believe the existing paragraph conveys this too. > > The existing paragraph says that NATs _may_ do this, as though it is > okay (in the LISP universe) for them to do so, which is not > something that I think we should. At the very least, you should > change the sentence to say that they _some currently deployed IPv4 > NATs do_ this (not that they may do it), so that it is clear we are > talking about an operational issue with currently deployed hardware. > First, could this paragraph go in the Security Section, which would make it clearer that its not something we want people to do ? Second, how about this tweak for the paragraph in the security section : Implementors should be aware that even when the UDP checksum is transmitted as zero, it is possible that intervening devices (such as NATs) recalculate the outer UDP checksum and rewrite that checksum field to non-zero. Integrity of the encapsulated data is provided by the UDP checksum in the inner packet [UDP-TUNNELS]. Regards Marshall > The existing paragraph also doesn't make it clear that the NATs > overwrite the checksum with a correct UDP checksum value for the > packet they are transmitting, which lead to a lot of confusion in > the LISP WG earlier. > > Margaret > > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From tme@americafree.tv Fri Sep 11 10:34: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 BED8E28C21C for ; Fri, 11 Sep 2009 10:34:47 -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 m0TrfOaY+6tm for ; Fri, 11 Sep 2009 10:34:46 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id C2E4D28C203 for ; Fri, 11 Sep 2009 10:34:46 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 7DDFE4B3DC3E; Fri, 11 Sep 2009 13:35:24 -0400 (EDT) Message-Id: <3AF37E20-73A3-45C4-AF1A-D7E49F307C5E@americafree.tv> From: Marshall Eubanks To: Dino Farinacci In-Reply-To: <65E7853A-1868-4BDC-902B-4E08B352BBF5@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: Fri, 11 Sep 2009 13:35:24 -0400 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> <2B145198-8A2D-411B-82AF-66BAA3C0DCFC@cisco.com> <985F0D74-73CA-48CC-8F75-EC8C55042C81@sandstorm.net> <2E0A736E-79E1-44B4-8562-7C778354EAAD@cisco.com> <4AA8F6EE.7000702@joelhalpern.com> <08E2E969-CE86-4755-B51C-307A4C80A347@sandstorm.net> <00F147AF-A9D7-41DE-83A9-83892CE42E42@cisco.com> <65E7853A-1868-4BDC-902B-4E08B352BBF5@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" , Margaret Wasserman 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: Fri, 11 Sep 2009 17:34:47 -0000 On Sep 11, 2009, at 1:29 PM, Dino Farinacci wrote: >> On Sep 11, 2009, at 12:58 PM, Dino Farinacci wrote: >>>> >>>> Note, there are some currently deployed, improperly implemented >>>> IPv4 NAT boxes that will recalculate a >>> >>> Well I don't think it is necessarily improper. If NATs are >>> changing IP addresses in UDP headers they have to change the UDP >>> checksum to reflect the address change. >> >> No, they don't. They should incrementally update the checksum, so >> it remains an end-to-end integrity protection mechanism. If they >> write a correct checksum over a zero value, they are giving the >> illusion that the packet was end-to-end protected when it was not, >> which might be problematic for some applications. Even worse, if >> they re-write non-zero values with new, correct values, they could >> be incorrectly asserting that the packet has not been corrupted >> when it already was. > > We all know NATs are evil. And we shouldn't create any more NAT > solutions. ;-) > >>> I'd rather not put in text that judges this. >>> >>> >>>> zero UDP checksum and overwrite it with a correct UDP checksum >>>> value. LISP implementors and operators may wish to consider the >>>> existence of this equipment in their implementation and >>>> deployment decisions regarding UDP checksums. >>>> >>>> This would make it clear that we are pointing out something about >>>> existing operational networks, and that we are neither condoning >>>> nor advocating NAT boxes that behave this way. >>> >>> I believe the existing paragraph conveys this too. >> >> The existing paragraph says that NATs _may_ do this, as though it >> is okay (in the LISP universe) for them to do so, which is not >> something that I think we should. At the very least, you should >> change the sentence to say that they _some currently deployed IPv4 >> NATs do_ this (not that they may do it), so that it is clear we are >> talking about an operational issue with currently deployed hardware. >> >> The existing paragraph also doesn't make it clear that the NATs >> overwrite the checksum with a correct UDP checksum value for the >> packet they are transmitting, which lead to a lot of confusion in >> the LISP WG earlier. > Despite the message I just sent, this WFM. Marshall > Rather than saying more about this. I will remove the paragraph. The > discussion it too complicated to me and the text doesn't add enough > value. If the first parapgraph is conformed to, then we can deal > with NATs. > > Dino > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jnc@mercury.lcs.mit.edu Fri Sep 11 12:19: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 E25A83A69FE for ; Fri, 11 Sep 2009 12:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, J_CHICKENPOX_22=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 O89Nps6KO33b for ; Fri, 11 Sep 2009 12:19:50 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 30FE33A6A5F for ; Fri, 11 Sep 2009 12:19:50 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 248A46BE574; Fri, 11 Sep 2009 15:20:25 -0400 (EDT) To: dino@cisco.com, lisp@ietf.org Message-Id: <20090911192025.248A46BE574@mercury.lcs.mit.edu> Date: Fri, 11 Sep 2009 15:20:25 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu 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: Fri, 11 Sep 2009 19:19:51 -0000 Dino, as requested: > From: "Joel M. Halpern" > UDP Checksum: this field MAY be transmitted as zero by an ITR. I'm OK with all the rest of this text, but would like to change this first "MAY" to "SHOULD". I have discussed this extensively offline with a couple of the 'usual suspects' in the WG, and they are OK with it. I can forward extracts of that exchange (which amounts to a long examination of the whole philosophy of checksums at various levels in the stack) to anyone who is interested, but the bottom line is that the UDP checksum in the encapsulation does not perform any useful function _for the encapsulated packet_, and I would like to make it plain to less-knowledgable readers that that is so, and changing from a MAY to a SHOULD does that, while changing reality on the ground little (the two terms are almost interchangeable, in terms of their effect). No0el From dino@cisco.com Fri Sep 11 12: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 8458E3A6962 for ; Fri, 11 Sep 2009 12:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 IsNXUPRH9dkH for ; Fri, 11 Sep 2009 12:26:09 -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 924BF3A6864 for ; Fri, 11 Sep 2009 12:26:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK5AqkqrR7PE/2dsb2JhbADFCIhIAZASBYQYimU X-IronPort-AV: E=Sophos;i="4.44,372,1249257600"; d="scan'208";a="189123278" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 11 Sep 2009 19:26: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 n8BJQlGJ021436; Fri, 11 Sep 2009 12:26: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 n8BJQlsA001782; Fri, 11 Sep 2009 19:26:47 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); Fri, 11 Sep 2009 12:26:47 -0700 Received: from [192.168.1.2] ([10.21.75.162]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 12:26:47 -0700 Message-Id: From: Dino Farinacci To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-Reply-To: <20090911192025.248A46BE574@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, 11 Sep 2009 12:26:46 -0700 References: <20090911192025.248A46BE574@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 19:26:47.0055 (UTC) FILETIME=[CD9ED9F0:01CA3315] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1502; t=1252697207; x=1253561207; 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]=20Suggested=20UDP=20checksum=20t ext |Sender:=20; bh=QmDQd+ztoGgT7YYtWtiOQemsOXsYbF/k+tfQaKWD52Y=; b=j7MDafP+tcIS4wxIi+6N/9mOGVmCTHFnETC7z/xEtAZhw+o10Y6J3MeU9C cXULuepKLuVl4RU+p8Fgz6sVhnm9Qblvr2jY4cyRv/p1CBR5DGtCkIvLsdeQ 8dCieY9V8X; 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] 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: Fri, 11 Sep 2009 19:26:10 -0000 > Dino, as requested: > >> From: "Joel M. Halpern" > >> UDP Checksum: this field MAY be transmitted as zero by an ITR. > > I'm OK with all the rest of this text, but would like to change this > first > "MAY" to "SHOULD". I have discussed this extensively offline with a > couple of > the 'usual suspects' in the WG, and they are OK with it. I can make this change but it doesn't really leave enough time for people to discuss it and we are at the deadline. Even though we have discussed this to death. So I propose this; (1) Make this change. (2) Post -04 now. There are a lot of changes and we need to post it. (3) Any other open issues can be addressed in the -05 spec which we can open up in the coming weeks. I hope that is reasonable for everyone. > I can forward extracts of that exchange (which amounts to a long > examination > of the whole philosophy of checksums at various levels in the stack) > to > anyone who is interested, but the bottom line is that the UDP > checksum in the > encapsulation does not perform any useful function _for the > encapsulated > packet_, and I would like to make it plain to less-knowledgable > readers that > that is so, and changing from a MAY to a SHOULD does that, while > changing > reality on the ground little (the two terms are almost > interchangeable, in > terms of their effect). I trust and believe you Noel. The question is solely on consensus. Dino From hartmans@mit.edu Fri Sep 11 12:34: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 2FBAD3A69DC for ; Fri, 11 Sep 2009 12:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 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 OvpfcOFK0xV6 for ; Fri, 11 Sep 2009 12:34: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 D179428C18D for ; Fri, 11 Sep 2009 12:34:29 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0BFA6452E; Fri, 11 Sep 2009 15:34:46 -0400 (EDT) To: Sam Hartman References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> From: Sam Hartman Date: Fri, 11 Sep 2009 15:34:46 -0400 In-Reply-To: (Sam Hartman's message of "Mon\, 07 Sep 2009 19\:45\:49 -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] Changes proposed in 04 that have not yet demonstrated WG consensus X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 19:34:31 -0000 >>>>> "Sam" == Sam Hartman writes: Dino, I've reviewed the issues I said we do not have consensus on and I think we now have enough discussion to call consensus on several. >>>>> "Dino" == Dino Farinacci writes: Sam> * How do deal with record count greater than 1 for a Sam> Map-Request. We have converged on the original text in Dino's proposal. Dino> * Margaret's comment on gleaning: Sam> I didn't see discussion of the text on the list; follow up Sam> required for issue #8. I believe this has been discussed enough that including the current text is a clear step forward. I'm not sure whether we're entirely done and am a bit behind on the discussion. Dino> * Add section on RLOC-probing per working group feedback. We're good here as well. Dino> * Change LISP header to allow a "Research Bit" so the Nonce Dino> and LSB fields can be turned off and used for another future Dino> purpose. For Luigi et al versioning convergence. * Add a Dino> N-bit to the data header suggested by Noel. Then the nonce Dino> field could be used when N is not 1. I think we're good here as well. I need to write up a resolution to #16 and friends, but I believe the text in Dino's current diff is something we've all said we can live with. From dino@cisco.com Fri Sep 11 12:41: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 59D313A69AD for ; Fri, 11 Sep 2009 12:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.537 X-Spam-Level: X-Spam-Status: No, score=-4.537 tagged_above=-999 required=5 tests=[AWL=-1.905, 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 sw3axkpW82-X for ; Fri, 11 Sep 2009 12:41:43 -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 CFD2228C18D for ; Fri, 11 Sep 2009 12:41:42 -0700 (PDT) X-Files: rfcdiff-lisp-03-to-04.html : 166437 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEFAKtEqkqrR7O6/2dsb2JhbACCJTHCIIhIASaPbgWCLgEECIFdgVmJDCc X-IronPort-AV: E=Sophos;i="4.44,372,1249257600"; d="html'217?scan'217,208,217";a="240652384" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 11 Sep 2009 19:42:16 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8BJgFU8030315; Fri, 11 Sep 2009 12:42:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n8BJgFet019802; Fri, 11 Sep 2009 19:42:15 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, 11 Sep 2009 12:42:15 -0700 Received: from [192.168.1.2] ([10.21.75.162]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 12:42:14 -0700 Message-Id: From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: multipart/mixed; boundary=Apple-Mail-49--486972776 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 11 Sep 2009 12:42:14 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 19:42:14.0457 (UTC) FILETIME=[F6652A90:01CA3317] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=171281; t=1252698135; x=1253562135; 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]=20Changes=20proposed=20in=2004=2 0that=20have=20not=20yet=20demonstrated=20WG=20=20consensus |Sender:=20; bh=Rq1ZdTW/QVwPtnT5hAwtQvel6BPjRdwzIIfDOiipbBo=; b=RsQXVDd7AgzrZgvxV6aHYEyCbtb+coT1iGM19xXqmvTCGbvOkZRok9yDxm YpkqyrOP//zICLoIo546QUeRHQBifs5y4RPQsYZbyOCIxKaOoikrSXUBtnOP vMgbWAGtjz; 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] Changes proposed in 04 that have not yet demonstrated WG consensus X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 19:41:53 -0000 --Apple-Mail-49--486972776 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Here are the latest diffs as of 5 minutes ago. Dino --Apple-Mail-49--486972776 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 15, 2010                                         D. Lewis
                                                           cisco Systems
                                                           July 27,
                                                      September 11, 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 15, 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 22
       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 36
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 36 37
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 38 39
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 39 41
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 40 42
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 40 43
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 41 44
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 43 46
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 44 47
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 45 48
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 45 48
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 46 49
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 47 50
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 51
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 51
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 48 51
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 50 53
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 50 53
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 53
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 53
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 52 55
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 52 55
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 54 57
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 55 58
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 56 59
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 62
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 59 62
     14.2. Informative References . . . . . . . . . . . . . . . . . . 60 63
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 63 66
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 67

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 statically 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 prepends 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
      statically 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 prepends 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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

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

   OH

   Outer 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 SHOULD be transmitted as 0 and ignored on
      receipt zero by the ETR.  Note, even when the an ITR for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
      packet with a zero UDP checksum is
      transmitted as 0 received by an intervening NAT device can recalculate ETR, the
      checksum and rewrite ETR
      MUST accept the UDP checksum field to non-zero.  For
      performance reasons, packet for decapsulation.  When an ITR transmits a
      non-zero value for the ETR UDP checksum, it MUST ignore send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not
      do a checksum computation. to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.

   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

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

   LISP Locator Reach Bits:  in the LISP header are nonce-present bit.  When this bit is set by an ITR to
      indicate to an ETR 1, the reachability
      low-order 24-bits of the Locators in first 32-bits of the LISP header contains
      a Nonce.  See section Section 6.3.1 for details.

   L: this is the Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are in use.

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1.  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.

   rflags:  this 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
      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.  When the E-bit is clear but the N-bit
      is set, an ITR is either echoing a previously requested echo-nonce
      or providing a random nonce.  See section Section 6.3.1 for more
      details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator
      Reach Status Bits are numbered from 0 to n-1 from the right least
      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 is
      reachable. 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 Reach Status Bits
      setting in an encapsulated packet MUST reflect the mapping for the
      EID-prefix that the inner-header source EID address matches.

   S: this is

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the Solicit-Map-Request (SMR) bit.  See section
      Section 6.5.2 for details.

   E: this is the echo-nonce-request bit.  See section Section 6.3.1 for
      details.

   rsvd-flags:  this 6-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.
      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 is set to solicit the other side to send a Map-
      Request containing this nonce.  See section Section 6.5.2 for
      details.

   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 inner header Time to Live
      field.

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

   When doing Re-encapsulated Tunneling:

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

   o  The new OH outer header Type of Service field SHOULD be copied from
      the stripped OH header Type of Service field (with one caveat, see
      below)..
      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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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 Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record count. Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  A 4-byte  An 8-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  The
      security of the "Source EID Address" field.

   ITR-AFI:  Address family LISP mapping protocol depends critically on the
      strength of the "Originating ITR nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   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.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request, it may
   originate a "verifying Map-Request", addressed to the original ITR.
   If the ETR has a map-cache entry that matches the "piggybacked" EID
   and the RLOC is in the locator-set for the entry, then it may send
   the "verifying Map-Request" to the original Map-Request source.  If
   not, then it MUST send it to the "piggybacked" EID.  Doing this
   forces the "verifying Map-Request" to go through the mapping database
   system to reach the authoritative source of information about that
   EID, guarding against RLOC-spoofing in in the "piggybacked" 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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
      advertising that the site 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 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request
      that is echoed here in this Nonce field of the Map-Reply. 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.

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

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

   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: this bit is reserved for use by the LISP mobile-node design
      documented in [LISP-MN].

   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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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  This 8-byte 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, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply and or that stored in the database
   mapping service does not database system provide any reachability status information for Locators.  This is done outside RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the mapping service.  See Routing Locator Reachability Algorithms described in the
   next section for details. section.

6.3.  Routing Locator Reachability

   There are 4 methods

   Several mechanisms for determining when a Locator is either
   reachable or has become unreachable:

   1.  Locator RLOC reachability is determined by an ETR by examining are currently
   defined:

   1.  An ETR may examine the Loc-Status-Bits in the
       Loc-Reach-Bits from a LISP header of a an
       encapsulated data packet
       which received from an ITR.  If the ETR is provided by
       also acting as an ITR when an and has traffic to return to the original
       ITR encapsulates data.

   2.  Locator unreachability is determined by site, it can use this status information to help select an
       RLOC.

   2.  An ITR by receiving may receive an ICMP Network or ICMP Host Unreachable messages.
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  Locator unreachability  An ITR which participates in the global routing system can also be determined by
       determine that an BGP-enabled
       ITR when there RLOC is down if no prefix matching a Locator address from the BGP RIB. RIB route exists that
       matches the RLOC IP address.

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

   5.  Locator reachability is determined by receiving  An ITR may receive a Map-Reply
       message from a ETR's Locator address ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  Locator reachability can also be determined by receiving packets  When an ETR receives an encapsulated by packet from an ITR, the ITR assigned to
       source RLOC from the locator address. outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   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 an encapsulating ITR closest to the Locators at the source about
   reachability for all ETRs at the site.  The  CE-based ITRs at the source
   site can determine reachability when running their
   IGP at the site.  When relative to each other using the ITRs are deployed on CE routers, typically site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route is injected into the site's IGP from each of the
   ITRs. site IGP.

   o  If an ITR goes down, the CE-PE link goes down, fails or if the upstream link to its PE
   router goes down, the CE router withdraws the fails, its
      default route.  This
   allows route will either time-out or be withdrawn.

   Each ITR can thus observe the other ITRs at presence or lack of a default route
   originated by the site others to determine one of the Locators
   has gone unreachable.

   The Locators Locator Status Bits it sets
   for them.

   RLOCs 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 encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit numbered as 0.  So,
   for bit.  For example, if the ITR with locator an RLOC
   listed as in the 3rd Locator position in of the Map-Reply goes down, down (ordinal value
   2), then all other ITRs at the site will
   have clear the 3rd least significant
   bit from (xxxx x0xx) of the right cleared (the bit that corresponds to
   ordinal 2). Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will look check for a any change in
   the
   Loc-Reach-Bits value. Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to the Locator an RLOC that has just gone
   unreachable. is indicated as
   down.  It can start will only resume using the Locator again when the bit that
   corresponds to RLOC if the Locator goes from 0 corresponding Loc-
   Status-Bit returns to a value of 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 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 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 which transmits traffic from that site or to determine when the site path to site
   traffic is unidirectional so there a specific locator is no ITR returning traffic.

   Note that other
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator reachability mechanisms are being researched
   and 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.

   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 more secure to reach an authoritative ETR,
   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 24-bit Nonce field in the LISP encapsulation header. header and a
   64-bit Nonce field in the LISP control message.  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 have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   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,  Two are the Echo-Noncing and
        RLOC-Probing algorithms which is are documented in this
        specification.  The other two are third is 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.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

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

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

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.

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, Sam Hartman, Michael Hofling, and Pedro Marques.

   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-49--486972776 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sep 11, 2009, at 12:34 PM, Sam Hartman wrote: >>>>>> "Sam" == Sam Hartman writes: > > Dino, I've reviewed the issues I said we do not have consensus on and > I think we now have enough discussion to call consensus on several. > >>>>>> "Dino" == Dino Farinacci writes: > Sam> * How do deal with record count greater than 1 for a > Sam> Map-Request. > > We have converged on the original text in Dino's proposal. > > Dino> * Margaret's comment on gleaning: > > Sam> I didn't see discussion of the text on the list; follow up > Sam> required for issue #8. > > I believe this has been discussed enough that including the current > text is a clear step forward. > I'm not sure whether we're entirely done and am a bit behind on the > discussion. > > Dino> * Add section on RLOC-probing per working group feedback. > > We're good here as well. > > > Dino> * Change LISP header to allow a "Research Bit" so the Nonce > Dino> and LSB fields can be turned off and used for another future > Dino> purpose. For Luigi et al versioning convergence. * Add a > Dino> N-bit to the data header suggested by Noel. Then the nonce > Dino> field could be used when N is not 1. > > > > I think we're good here as well. I need to write up a resolution to > #16 and friends, but I believe the text in Dino's current diff is > something we've all said we can live with. --Apple-Mail-49--486972776-- From hartmans@mit.edu Fri Sep 11 12:42: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 3E9AF28C1D1 for ; Fri, 11 Sep 2009 12:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 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 kOnQWmeHEefe for ; Fri, 11 Sep 2009 12:42:03 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id C523A28C18D for ; Fri, 11 Sep 2009 12:42:00 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 083AA452E; Fri, 11 Sep 2009 15:42:17 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Fri, 11 Sep 2009 15:42: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] Consensus Call: 64-bit nonce and randomness of nonce X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 19:42:07 -0000 Folks, we've had proposals for a 64-bit nonce and for text on nonce randomness that seem to have had WG support. Unless I hear objections by next Friday, September 17, I'm going to assume that we're happy with both of these changes. I think there is a bit of discussion still ongoing on the random nonce issue and we may end up making minor changes there. I suspect Dino will publish a draft including both of these items before then; if we make changes we can change them in 05. (I've asked editors to hold off on changes where we don't have consensus, and perhaps I should have done this here as well. Ultimately, I had to make a decision and couldn't convince myself that delay was the right course of action on these issues so I'm leaving it up to the editors.) From julienl@qualcomm.com Fri Sep 11 12:43: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 F23D03A67F0 for ; Fri, 11 Sep 2009 12:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.681 X-Spam-Level: X-Spam-Status: No, score=-103.681 tagged_above=-999 required=5 tests=[AWL=-1.082, BAYES_00=-2.599, 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 YdQPZB7TnASN for ; Fri, 11 Sep 2009 12:43:45 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D860528C172 for ; Fri, 11 Sep 2009 12:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1252698263; x=1284234263; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Dino=20Farinacci=20,=20Sam=20Hartm an=20|CC:=20"lisp@ietf.org"=20|Date:=20Fri,=2011=20Sep=202009=2012:44:19=20-0700 |Subject:=20RE:=20[lisp]=20#2:=20IPsec=20or=20just=20IPse c=20headers=3B=20sha-1=20size|Thread-Topic:=20[lisp]=20#2 :=20IPsec=20or=20just=20IPsec=20headers=3B=20sha-1=20size |Thread-Index:=20Acoy+xoBYJz3U1lNRZG1XInR5vLxtAAGfWJA |Message-ID:=20|References:=20<643940D7-D2 34-4E67-BC5E-F5DF3D078D83@cisco.com>=0D=0A=09=0D=0A=09<14EB3D92-A53B-4EF2-ietf-AC25-4479C 7D19B16@cisco.com>=0D=0A=09 =20 |In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-U S|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5738"=3B=20a=3D"23486805"; bh=UezybhYVS8wXuMQESRqa5ZZab7mH3G+jgHnl5p5QuzA=; b=STmu7mdB4jvKZ7csHV8ClXUl8Qip884pooPR3/16L/symvcyyhuEnJdK TBCPacOuBSUN/xOW4g8sCcRTLHyjupW1Pp0LRpWD1gG35UDAfoyIHu1w6 UjhLgRT5HSkrOFC1G4dW3xSonhyaM42sRwL+wZYK6FhQ0vCDf/rcDfRQl M=; X-IronPort-AV: E=McAfee;i="5300,2777,5738"; a="23486805" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Sep 2009 12:44:22 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n8BJiM1d014415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Sep 2009 12:44:22 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n8BJiLlr020345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Sep 2009 12:44:21 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 11 Sep 2009 12:44:21 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Fri, 11 Sep 2009 12:44:21 -0700 From: "Laganier, Julien" To: Dino Farinacci , Sam Hartman Date: Fri, 11 Sep 2009 12:44:19 -0700 Thread-Topic: [lisp] #2: IPsec or just IPsec headers; sha-1 size Thread-Index: Acoy+xoBYJz3U1lNRZG1XInR5vLxtAAGfWJA Message-ID: References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <14EB3D92-A53B-4EF2-ietf-AC25-4479C7D19B16@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] #2: IPsec or just IPsec headers; sha-1 size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 19:43:46 -0000 Hello Dino, Dino Farinacci wrote: >=20 > > That's not going to work. You either need to use IPsec or not; you > > cannot borrow IPsec headers and codepoints without actually using > > IPsec. There are significant process problems with this: this is the >=20 > So what does this mean specifically? It means that IPsec is a whole, it defines an access control model as well = as on-the-wire protocol syntax that support realization of the access contr= ol model. The access control features of IPsec are a central part to IPsec = and requires an IPsec implementation to process AH (and ESP) as specified b= y the IPsec architecture document (RFC 4301), because that's how the IPsec = access control features are enforced. If it does something different, the I= Psec access control model is not respected. IOW you can't have it "a la carte" and use the on-the-wire protocol without= the rest of it without compromising the access control feature of IPsec. So either AH is _always_ processed as per 4301 and you have an IPsec implem= entation, or it is not and you can't have an IPsec implementation on that n= ode. Which is what Sam points out below when he says "it means I cannot use= LISP and IPsec on the same system or they stop on each other." =20 Suppose the node uses IPsec as per RFC 4301 to protect some communications,= and the AH format to protect some LISP communications. How is the node sup= posed to process incoming AH packets, per 4301/IPsec or per LISP?=20 > If the spec says Map-Registers use the AH header format from the IPsec > spec what does "using IPsec" mean from your point of view? >=20 > > sort of issue that created the T-MPLS mess between the ITU and IETF. > > More importantly though, it means I cannot use LISP and IPsec on the > > same system or they stop on each other. >=20 > Why does it mean that. You have to explain more Sam. Hopefully I've answered that above. --julien From mrw@sandstorm.net Fri Sep 11 12:44: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 E9D0A28C1CF for ; Fri, 11 Sep 2009 12:44:05 -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 D1aOmzrRQhPO for ; Fri, 11 Sep 2009 12:44:04 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 72B7E3A692A for ; Fri, 11 Sep 2009 12:44:03 -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 n8BJi5Tv036265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Sep 2009 15:44:05 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <0CBBA3C8-CA9A-4846-8B1B-B00A28AD9B50@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090911192025.248A46BE574@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, 11 Sep 2009 15:44:05 -0400 References: <20090911192025.248A46BE574@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) 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: Fri, 11 Sep 2009 19:44:06 -0000 On Sep 11, 2009, at 3:20 PM, Noel Chiappa wrote: > >> UDP Checksum: this field MAY be transmitted as zero by an ITR. > > I'm OK with all the rest of this text, but would like to change this > first > "MAY" to "SHOULD". I have discussed this extensively offline with a > couple of > the 'usual suspects' in the WG, and they are OK with it. My actual statement was that I prefer MAY, but I am not going to lose sleep over it either way. I also personally prefer a "SHOULD" for IPv6 ETRs to accept incoming packets with a zero checksum (to support implementation on existing desktop systems), but I understand that others' opinions differ. One other thing that I _do_ think we need to understand before we can reach fully informed consensus on this issue is exactly what draft- eubanks-chimento... (AKA [UDP-TUNNEL] says (or, perhaps more importantly, what it doesn't say)... I only recently read UDP-TUNNELS well enough to know what it actually says in detail. It does _not_ say that a LISP ITR can use zero UDP checksums for all IPv6 encapsulated traffic. In particular, it places the following restrictions on the use of zero UDP checksums in IPv6/UDP tunnels: o An inner IPv4 packet with a UDP checksum equal to 0 must not be tunneled. o Non-IP inner packets must have a CRC or other mechanism for checking packet integrity. o Other tunneling protcocols that use the UDP checksum equal to 0 MUST NOT be tunneled themselves, even if more deeply encapsulated packets have checksums or other integrity checking mechanisms. So, the UDP-TUNNEL draft will require ITRs to inspect all packets that are being encapsulated to make sure that they have integrity checking enabled before encapsulating them in IPv6/UDP with a zero UDP checksum. Practically, this means that ITRs will have to be prepared to calculate UDP checksums for IPv6/UDP outer headers for all encapsulated packets that do not use TCP, SCTP or UDP with non-zero checksums. It will also require that UDP checksums be set to non-zero values whenever LISP is tunneled inside LISP. Has everyone else who is agreeing to the UDP checksum text read the UDP-TUNNEL draft? Are you comfortable with what it says? Do folks think we need to say something more specific about the [UDP- TUNNEL] requirements in the LISP document to make this clearer? Margaret From dino@cisco.com Fri Sep 11 12:53: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 0EAD928C0F0 for ; Fri, 11 Sep 2009 12:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAILb7nhOWCD for ; Fri, 11 Sep 2009 12:53: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 8FCA23A635F for ; Fri, 11 Sep 2009 12:53:38 -0700 (PDT) X-Files: rfcdiff-lisp-03-to-04.html, draft-ietf-lisp-04.txt : 166437, 150979 X-IronPort-AV: E=Sophos;i="4.44,372,1249257600"; d="txt'?html'217?scan'217,208,217";a="387000065" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Sep 2009 19:54:08 +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 n8BJs8qD012718 for ; Fri, 11 Sep 2009 12:54:08 -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 n8BJs8SB018315 for ; Fri, 11 Sep 2009 19:54:08 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, 11 Sep 2009 12:54:08 -0700 Received: from [192.168.1.2] ([10.21.75.162]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 12:54:07 -0700 Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-52--486260241 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 11 Sep 2009 12:54:06 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 19:54:07.0362 (UTC) FILETIME=[9F51D620:01CA3319] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=325210; t=1252698848; x=1253562848; 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:=20Any=20objections=20for=20posting=20draft-ietf-l isp-04.txt? |Sender:=20; bh=cHGCY6MG+9k76oY0MYt73R8dymfiYyChFiyZgkda9rY=; b=fAco+Mi+ghEr87ZSSWpIIQDVIuNuOOA9WcI+5Efp5u4CdyGddV3JgENjQl woOdy+4cKWPN4QP+a8pm/yTch5voSJw3eNElz7mUh5JKspO8SEQVwdtUiju+ DfwY47vYdVqVcBNb+ryxjAUbnfCdC/+oAjKzJ13Y8B+o6L4a9fKA4=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [lisp] Any objections for posting 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: Fri, 11 Sep 2009 19:53:39 -0000 --Apple-Mail-52--486260241 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The deadline has arrived (we are one hour past it). Anyone have objections to posting the -04 draft? We can start on a -05 revision in a few weeks for any additional issues? Dino --Apple-Mail-52--486260241 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 15, 2010                                         D. Lewis
                                                           cisco Systems
                                                           July 27,
                                                      September 11, 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 15, 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 22
       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 36
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 36 37
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 38 39
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 39 41
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 40 42
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 40 43
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 41 44
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 43 46
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 44 47
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 45 48
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 45 48
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 46 49
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 47 50
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 51
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 51
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 48 51
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 50 53
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 50 53
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 53
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 53
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 52 55
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 52 55
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 54 57
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 55 58
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 56 59
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 62
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 59 62
     14.2. Informative References . . . . . . . . . . . . . . . . . . 60 63
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 63 66
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 67

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 statically 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 prepends 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
      statically 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 prepends 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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

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

   OH

   Outer 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 SHOULD be transmitted as 0 and ignored on
      receipt zero by the ETR.  Note, even when the an ITR for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
      packet with a zero UDP checksum is
      transmitted as 0 received by an intervening NAT device can recalculate ETR, the
      checksum and rewrite ETR
      MUST accept the UDP checksum field to non-zero.  For
      performance reasons, packet for decapsulation.  When an ITR transmits a
      non-zero value for the ETR UDP checksum, it MUST ignore send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not
      do a checksum computation. to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.

   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

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

   LISP Locator Reach Bits:  in the LISP header are nonce-present bit.  When this bit is set by an ITR to
      indicate to an ETR 1, the reachability
      low-order 24-bits of the Locators in first 32-bits of the LISP header contains
      a Nonce.  See section Section 6.3.1 for details.

   L: this is the Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are in use.

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1.  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.

   rflags:  this 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
      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.  When the E-bit is clear but the N-bit
      is set, an ITR is either echoing a previously requested echo-nonce
      or providing a random nonce.  See section Section 6.3.1 for more
      details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator
      Reach Status Bits are numbered from 0 to n-1 from the right least
      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 is
      reachable. 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 Reach Status Bits
      setting in an encapsulated packet MUST reflect the mapping for the
      EID-prefix that the inner-header source EID address matches.

   S: this is

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the Solicit-Map-Request (SMR) bit.  See section
      Section 6.5.2 for details.

   E: this is the echo-nonce-request bit.  See section Section 6.3.1 for
      details.

   rsvd-flags:  this 6-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.
      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 is set to solicit the other side to send a Map-
      Request containing this nonce.  See section Section 6.5.2 for
      details.

   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 inner header Time to Live
      field.

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

   When doing Re-encapsulated Tunneling:

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

   o  The new OH outer header Type of Service field SHOULD be copied from
      the stripped OH header Type of Service field (with one caveat, see
      below)..
      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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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 Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record count. Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  A 4-byte  An 8-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  The
      security of the "Source EID Address" field.

   ITR-AFI:  Address family LISP mapping protocol depends critically on the
      strength of the "Originating ITR nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   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.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request, it may
   originate a "verifying Map-Request", addressed to the original ITR.
   If the ETR has a map-cache entry that matches the "piggybacked" EID
   and the RLOC is in the locator-set for the entry, then it may send
   the "verifying Map-Request" to the original Map-Request source.  If
   not, then it MUST send it to the "piggybacked" EID.  Doing this
   forces the "verifying Map-Request" to go through the mapping database
   system to reach the authoritative source of information about that
   EID, guarding against RLOC-spoofing in in the "piggybacked" 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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
      advertising that the site 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 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request
      that is echoed here in this Nonce field of the Map-Reply. 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.

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

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

   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: this bit is reserved for use by the LISP mobile-node design
      documented in [LISP-MN].

   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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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  This 8-byte 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, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply and or that stored in the database
   mapping service does not database system provide any reachability status information for Locators.  This is done outside RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the mapping service.  See Routing Locator Reachability Algorithms described in the
   next section for details. section.

6.3.  Routing Locator Reachability

   There are 4 methods

   Several mechanisms for determining when a Locator is either
   reachable or has become unreachable:

   1.  Locator RLOC reachability is determined by an ETR by examining are currently
   defined:

   1.  An ETR may examine the Loc-Status-Bits in the
       Loc-Reach-Bits from a LISP header of a an
       encapsulated data packet
       which received from an ITR.  If the ETR is provided by
       also acting as an ITR when an and has traffic to return to the original
       ITR encapsulates data.

   2.  Locator unreachability is determined by site, it can use this status information to help select an
       RLOC.

   2.  An ITR by receiving may receive an ICMP Network or ICMP Host Unreachable messages.
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  Locator unreachability  An ITR which participates in the global routing system can also be determined by
       determine that an BGP-enabled
       ITR when there RLOC is down if no prefix matching a Locator address from the BGP RIB. RIB route exists that
       matches the RLOC IP address.

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

   5.  Locator reachability is determined by receiving  An ITR may receive a Map-Reply
       message from a ETR's Locator address ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  Locator reachability can also be determined by receiving packets  When an ETR receives an encapsulated by packet from an ITR, the ITR assigned to
       source RLOC from the locator address. outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   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 an encapsulating ITR closest to the Locators at the source about
   reachability for all ETRs at the site.  The  CE-based ITRs at the source
   site can determine reachability when running their
   IGP at the site.  When relative to each other using the ITRs are deployed on CE routers, typically site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route is injected into the site's IGP from each of the
   ITRs. site IGP.

   o  If an ITR goes down, the CE-PE link goes down, fails or if the upstream link to its PE
   router goes down, the CE router withdraws the fails, its
      default route.  This
   allows route will either time-out or be withdrawn.

   Each ITR can thus observe the other ITRs at presence or lack of a default route
   originated by the site others to determine one of the Locators
   has gone unreachable.

   The Locators Locator Status Bits it sets
   for them.

   RLOCs 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 encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit numbered as 0.  So,
   for bit.  For example, if the ITR with locator an RLOC
   listed as in the 3rd Locator position in of the Map-Reply goes down, down (ordinal value
   2), then all other ITRs at the site will
   have clear the 3rd least significant
   bit from (xxxx x0xx) of the right cleared (the bit that corresponds to
   ordinal 2). Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will look check for a any change in
   the
   Loc-Reach-Bits value. Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to the Locator an RLOC that has just gone
   unreachable. is indicated as
   down.  It can start will only resume using the Locator again when the bit that
   corresponds to RLOC if the Locator goes from 0 corresponding Loc-
   Status-Bit returns to a value of 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 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 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 which transmits traffic from that site or to determine when the site path to site
   traffic is unidirectional so there a specific locator is no ITR returning traffic.

   Note that other
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator reachability mechanisms are being researched
   and 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.

   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 more secure to reach an authoritative ETR,
   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 24-bit Nonce field in the LISP encapsulation header. header and a
   64-bit Nonce field in the LISP control message.  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 have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   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,  Two are the Echo-Noncing and
        RLOC-Probing algorithms which is are documented in this
        specification.  The other two are third is 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.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

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

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

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.

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, Sam Hartman, Michael Hofling, and Pedro Marques.

   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-52--486260241 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-52--486260241 Content-Disposition: attachment; filename=draft-ietf-lisp-04.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-04.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: March 15, 2010 D. Lewis cisco Systems September 11, 2009 Locator/ID Separation Protocol (LISP) 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 March 15, 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. Farinacci, et al. Expires March 15, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . 36 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 37 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 39 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 41 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 42 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 43 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 44 7. Router Performance Considerations . . . . . . . . . . . . . . 46 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 47 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 48 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 48 Farinacci, et al. Expires March 15, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 49 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 50 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 51 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 51 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 51 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 53 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 53 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 55 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 55 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 57 12. Security Considerations . . . . . . . . . . . . . . . . . . . 58 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 59 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 14.1. Normative References . . . . . . . . . . . . . . . . . . . 62 14.2. Informative References . . . . . . . . . . . . . . . . . . 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 Farinacci, et al. Expires March 15, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 15, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 15, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 15, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 15, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 statically 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 prepends 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 statically configured. Farinacci, et al. Expires March 15, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 prepends 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 Farinacci, et al. Expires March 15, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 15, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | | Farinacci, et al. Expires March 15, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer 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 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 SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. 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. Farinacci, et al. Expires March 15, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See section Section 6.3.1 for details. L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. E: this is the echo-nonce-request bit. When this bit is set to 1, the N bit must be 1. 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. rflags: this 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 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. When the E-bit is clear but the N-bit is set, an ITR is either echoing a previously requested echo-nonce or providing a random nonce. See section Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least 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 outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Type of Service field (with one caveat, see below). Farinacci, et al. Expires March 15, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 When doing Re-encapsulated Tunneling: o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer 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. Farinacci, et al. Expires March 15, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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. Farinacci, et al. Expires March 15, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet with DF bit set to 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. Farinacci, et al. Expires March 15, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires March 15, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 | | + 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. Farinacci, et al. Expires March 15, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D1 |A|M|P|S| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . 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: Farinacci, et al. Expires March 15, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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 Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. 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. Farinacci, et al. Expires March 15, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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. An ITR that is configured with mapping database information (i.e. it Farinacci, et al. Expires March 15, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request, it may originate a "verifying Map-Request", addressed to the original ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map-Request" to the original Map-Request source. If not, then it MUST send it to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" 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=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | 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: Farinacci, et al. Expires March 15, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. See section Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is advertising that the site 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 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of 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. 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. Farinacci, et al. Expires March 15, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 (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: this bit is reserved for use by the LISP mobile-node design documented in [LISP-MN]. 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 Farinacci, et al. Expires March 15, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 15, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 [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 [RFC4302] is: Farinacci, et al. Expires March 15, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 SHA-1 or SHA-128 HMAC. The Map-Register message format is: Farinacci, et al. Expires March 15, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D3 |P| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | 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: This 8-byte 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. Farinacci, et al. Expires March 15, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o A "gleaned" map-cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. Farinacci, et al. Expires March 15, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the 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 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 Farinacci, et al. Expires March 15, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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 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 Farinacci, et al. Expires March 15, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 nonce echo, it sets the 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 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 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. 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. Farinacci, et al. Expires March 15, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 obtain those benefits, especially if the 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. Farinacci, et al. Expires March 15, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 15, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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-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-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-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. Farinacci, et al. Expires March 15, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the 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 ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- prefix uses is the one copied from the SMR 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 Farinacci, et al. Expires March 15, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 the loc-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending 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 more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. Farinacci, et al. Expires March 15, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 15, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, Farinacci, et al. Expires March 15, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 15, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 15, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 15, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 15, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. 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. Farinacci, et al. Expires March 15, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Interoperable implementations have been available since the beginning of 2009. We are trying to converge on a packet format so implementations can converge on the -04 and later drafts. 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. Farinacci, et al. Expires March 15, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts 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. Farinacci, et al. Expires March 15, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. [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. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [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. Farinacci, et al. Expires March 15, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 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), Farinacci, et al. Expires March 15, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-02.txt (work in progress), 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", Farinacci, et al. Expires March 15, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 15, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, and Pedro Marques. 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. Farinacci, et al. Expires March 15, 2010 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 15, 2010 [Page 67] =0C --Apple-Mail-52--486260241 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-52--486260241-- From mrw@sandstorm.net Fri Sep 11 13:07: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 3302A28C120 for ; Fri, 11 Sep 2009 13:07:35 -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 GU0viHdsxh94 for ; Fri, 11 Sep 2009 13:07:34 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 64F0628C19C for ; Fri, 11 Sep 2009 13:07:34 -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 n8BK8A28037189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 11 Sep 2009 16:08:10 -0400 (EDT) (envelope-from mrw@sandstorm.net) 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: Fri, 11 Sep 2009 16:08:10 -0400 References: X-Mailer: Apple Mail (2.935.3) Subject: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 20:07:35 -0000 I have a new issue that should probably go in the tracker (for resolution in -05 or later, not to hold anything up now). The UDP-TUNNELS document contains the following restriction: 2. The tunneling protocol and implementation must not use fragmentation of the inner packets being carried. This is inconsistent with one of our two options for MTU handling, the one described in section 5.4.1: A Stateless Solution to MTU Handling. To address this issue, we could remove the option in section 5.4.1 and just require that ITRs implement the stateful solution described in section 5.4.2. Margaret From dino@cisco.com Fri Sep 11 13:45: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 ED7783A69CF for ; Fri, 11 Sep 2009 13:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 W9zzmHShbVp4 for ; Fri, 11 Sep 2009 13:45:05 -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 4706C3A694E for ; Fri, 11 Sep 2009 13:45:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOdTqkqrR7PD/2dsb2JhbADEf4hIAZAJBYQY X-IronPort-AV: E=Sophos;i="4.44,372,1249257600"; d="scan'208";a="203944869" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 11 Sep 2009 20:45: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 n8BKjWB4019243 for ; Fri, 11 Sep 2009 13:45:32 -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 n8BKjWTm017897 for ; Fri, 11 Sep 2009 20:45:32 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, 11 Sep 2009 13:45:31 -0700 Received: from [192.168.1.2] ([10.21.75.162]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 13:45:31 -0700 Message-Id: From: Dino Farinacci 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 v936) Date: Fri, 11 Sep 2009 13:45:30 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 20:45:31.0750 (UTC) FILETIME=[CDC21860:01CA3320] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=176; t=1252701932; x=1253565932; 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:=20I=20am=20not=20posting=20the=20-04=20document=2 0today |Sender:=20; bh=9E+J6WCrj/cbOqnHUEOZiyoVemUMDEVwD1AT8L3k+TY=; b=UG1IXhw9qipf/5v9TRft7VhFmjHhdLfWaBKRNoeQWzoYLB9XtVe0kTys/7 Gn6JUIk03AGk418jLF4wB+c0hlXa3MWtKMBO9hb3/oJP5xPvKQ6SlwqZy1cU BtC74ar2io; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [lisp] I am not posting the -04 document today X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 20:45:06 -0000 One of the chairs (Sam) feels we have not reached consensus. I thought we had. I believe there are 2 issues remaining. I'll let Sam specify those. Regrettably, Dino From tme@americafree.tv Fri Sep 11 13:46: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 B252D28C19B for ; Fri, 11 Sep 2009 13:46:03 -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 9lXsZSRFBtXb for ; Fri, 11 Sep 2009 13:46:03 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id D393C28C172 for ; Fri, 11 Sep 2009 13:46:02 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 941124B41F2D; Fri, 11 Sep 2009 16:46:40 -0400 (EDT) Message-Id: From: Marshall Eubanks 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 v936) Date: Fri, 11 Sep 2009 16:46:38 -0400 References: <20090911192025.248A46BE574@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , 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: Fri, 11 Sep 2009 20:46:03 -0000 Your proposal for -04 WFM On Sep 11, 2009, at 3:26 PM, Dino Farinacci wrote: >> Dino, as requested: >> >>> From: "Joel M. Halpern" >> >>> UDP Checksum: this field MAY be transmitted as zero by an ITR. >> >> I'm OK with all the rest of this text, but would like to change >> this first >> "MAY" to "SHOULD". I have discussed this extensively offline with a >> couple of >> the 'usual suspects' in the WG, and they are OK with it. > > I can make this change but it doesn't really leave enough time for > people to discuss it and we are at the deadline. Even though we have > discussed this to death. > > So I propose this; > > (1) Make this change. > (2) Post -04 now. There are a lot of changes and we need to post it. > (3) Any other open issues can be addressed in the -05 spec which we > can open up in the coming weeks. > > I hope that is reasonable for everyone. > >> I can forward extracts of that exchange (which amounts to a long >> examination >> of the whole philosophy of checksums at various levels in the >> stack) to >> anyone who is interested, but the bottom line is that the UDP >> checksum in the >> encapsulation does not perform any useful function _for the >> encapsulated >> packet_, and I would like to make it plain to less-knowledgable >> readers that >> that is so, and changing from a MAY to a SHOULD does that, while >> changing >> reality on the ground little (the two terms are almost >> interchangeable, in >> terms of their effect). > > I trust and believe you Noel. The question is solely on consensus. > > Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dmm@1-4-5.net Fri Sep 11 13:48: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 6435F3A69CF for ; Fri, 11 Sep 2009 13:48: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=[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 2x-FYjjpAY1q for ; Fri, 11 Sep 2009 13:47:59 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 8DF6E3A694E for ; Fri, 11 Sep 2009 13:47:59 -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 n8BKm4t9015793; Fri, 11 Sep 2009 13:48:04 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n8BKm4w4015792; Fri, 11 Sep 2009 13:48:04 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 11 Sep 2009 13:48:04 -0700 From: David Meyer To: Marshall Eubanks Message-ID: <20090911204804.GA15768@1-4-5.net> References: <20090911192025.248A46BE574@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" 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] 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: Fri, 11 Sep 2009 20:48:00 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 11, 2009 at 04:46:38PM -0400, Marshall Eubanks wrote: > Your proposal for -04 WFM +1 Dave --G4iJoqBmSsgzjUCe 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) iEYEARECAAYFAkqqt4QACgkQORgD1qCZ2Kfi0QCeMnDoAwA8htwwNWzuvW9VPb9C dUMAn1fWafeiy6LY7fE8pMC8qSQPrSVb =9Ff1 -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- From Fred.L.Templin@boeing.com Fri Sep 11 14:46: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 290CA3A6804 for ; Fri, 11 Sep 2009 14:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.954 X-Spam-Level: X-Spam-Status: No, score=-5.954 tagged_above=-999 required=5 tests=[AWL=0.645, 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 QF-EjaXw2G8C for ; Fri, 11 Sep 2009 14:46:30 -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 517E53A68FC for ; Fri, 11 Sep 2009 14:46:30 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n8BLl5eC027940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Sep 2009 14:47:06 -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 n8BLl4c5017901; Fri, 11 Sep 2009 16:47:05 -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 n8BLl4M2017885; Fri, 11 Sep 2009 16:47:04 -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); Fri, 11 Sep 2009 14:47:04 -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, 11 Sep 2009 14:47:03 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106624B5A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling Thread-Index: AcozG5lb5fSvuJ2JR+G5xmraXR7QYwADPT+Q References: From: "Templin, Fred L" To: "Margaret Wasserman" , X-OriginalArrivalTime: 11 Sep 2009 21:47:04.0554 (UTC) FILETIME=[66D744A0:01CA3329] Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 21:46:31 -0000 Margaret, > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@sandstorm.net] > Sent: Friday, September 11, 2009 1:08 PM > To: lisp@ietf.org > Subject: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling >=20 >=20 > I have a new issue that should probably go in the tracker (for > resolution in -05 or later, not to hold anything up now). >=20 > The UDP-TUNNELS document contains the following restriction: >=20 > 2. The tunneling protocol and implementation must not use > fragmentation of the inner packets being carried. >=20 > This is inconsistent with one of our two options for MTU handling, the > one described in section 5.4.1: A Stateless Solution to MTU Handling. > To address this issue, we could remove the option in section 5.4.1 and > just require that ITRs implement the stateful solution described in > section 5.4.2. The UDP-TUNNELS text also says that the restriction only applies for a UDP checksum of 0. IMHO, the UDP-TUNNELS text should be carefully examined before suggesting any changes in LISP. Fred fred.l.templin@boeing.com > Margaret >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Fri Sep 11 15:17: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 1CD803A69AB for ; Fri, 11 Sep 2009 15:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 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 rWwffeADTzQF for ; Fri, 11 Sep 2009 15:17:24 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 656CF3A6986 for ; Fri, 11 Sep 2009 15:17:24 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 122DD452E; Fri, 11 Sep 2009 18:17:42 -0400 (EDT) To: Dino Farinacci References: From: Sam Hartman Date: Fri, 11 Sep 2009 18:17:41 -0400 In-Reply-To: (Dino Farinacci's message of "Fri\, 11 Sep 2009 13\:45\:30 -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] I am not posting the -04 document today X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 22:17:25 -0000 >>>>> "Dino" == Dino Farinacci writes: 8 Dino> One of the chairs (Sam) feels we have not reached Dino> consensus. I thought we had. First, I'm still waiting for feedback on the SMR bit being removed from the data plane. I don't think there has been any stated support for this on the list. I made a call in the form of an issue and have seen no responses. Dino thinks I just missed the discussion. So, if you spoke up in the past in support of this, please do so again; this is really important to resolve. The second issue is #19, the mobility bit. I explained why I don't believe we can include that. --Sam From hartmans@mit.edu Fri Sep 11 15:24: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 853033A680B for ; Fri, 11 Sep 2009 15:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 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 kmG1uVnuM3fA for ; Fri, 11 Sep 2009 15:24:55 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id E60403A696C for ; Fri, 11 Sep 2009 15:24:54 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DE64A452E; Fri, 11 Sep 2009 18:25:11 -0400 (EDT) To: David Meyer References: <20090911192025.248A46BE574@mercury.lcs.mit.edu> <20090911204804.GA15768@1-4-5.net> From: Sam Hartman Date: Fri, 11 Sep 2009 18:25:11 -0400 In-Reply-To: <20090911204804.GA15768@1-4-5.net> (David Meyer's message of "Fri\, 11 Sep 2009 13\:48\:04 -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] 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: Fri, 11 Sep 2009 22:24:55 -0000 Dino, I have some concerns about the UDP text that I'd like to discuss with Darrel; please wait for us. From dino@cisco.com Fri Sep 11 16:02: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 1D0673A680B for ; Fri, 11 Sep 2009 16:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 uCXiaz7DQYZE for ; Fri, 11 Sep 2009 16:02:58 -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 3B2C03A6855 for ; Fri, 11 Sep 2009 16:02:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALd0qkqrR7MV/2dsb2JhbADEOohIAY9rBYQYimU X-IronPort-AV: E=Sophos;i="4.44,372,1249257600"; d="scan'208";a="240739001" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 11 Sep 2009 23:00:16 +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 n8BN0Gmp008558; Fri, 11 Sep 2009 16:00:16 -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 n8BN0GtN023264; Fri, 11 Sep 2009 23:00:16 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); Fri, 11 Sep 2009 16:00:15 -0700 Received: from [192.168.1.2] ([10.21.75.162]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 16:00:15 -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 v936) Date: Fri, 11 Sep 2009 16:00:15 -0700 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Sep 2009 23:00:15.0650 (UTC) FILETIME=[A0235820:01CA3333] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1281; t=1252710016; x=1253574016; 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]=20I=20am=20not=20posting=20the=2 0-04=20document=20today |Sender:=20; bh=sQaaxTw6Dp1MF3sn/zMgPgOUfcwiKsoV6N4Ns/sZycA=; b=rPWEBzLQl9LtSzsPQ10Mni/yWruLaRAT7A5dNHIRv5AuP5Ym2ihV3Rzwr7 iqm/BXACQ0h9u7OPVWZXUNg3Pga6Z3ufECzhEjCMcrLr+2lTcbv+F2/DCtRm zahzIMNoTvo/dL4EVaf0umfd3XMOLUj/wswGHOhH3FyNkgYA3qqAc=; 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] I am not posting the -04 document today X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 23:02:59 -0000 >>>>>> "Dino" == Dino Farinacci writes: > 8 > Dino> One of the chairs (Sam) feels we have not reached > Dino> consensus. I thought we had. > > First, I'm still waiting for feedback on the SMR bit being removed > from the data plane. I don't think there has been any stated support > for this on the list. I made a call in the form of an issue and have > seen no responses. I support this. And I know the core LISP team at cisco has had conversations both on and off the list with the UCL-B guys and we all agreed that mapping- updates should be out of the data plane. That means the spec should not have version numbers in it or a SMR-bit in it. So just making it clear what I thought we had consensus on. And when we brought it to the list, no one objected. > Dino thinks I just missed the discussion. > So, if you spoke up in the past in support of this, please do so > again; this is really important to resolve. > > The second issue is #19, the mobility bit. I explained why I don't > believe we can include that. My understanding was to include the M bit so it can be allocated and indicate that it will be described in a future spec. Joel asked me to put that text in, and that is what I did. Dino From jnc@mercury.lcs.mit.edu Fri Sep 11 16:27: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 6432D3A6A94 for ; Fri, 11 Sep 2009 16:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 NlVh8Ufosui2 for ; Fri, 11 Sep 2009 16:27: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 7A3903A67E9 for ; Fri, 11 Sep 2009 16:27:36 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id E0EDA6BE553; Fri, 11 Sep 2009 19:28:13 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090911232813.E0EDA6BE553@mercury.lcs.mit.edu> Date: Fri, 11 Sep 2009 19:28:13 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] I am not posting the -04 document today X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 23:27:37 -0000 > From: Sam Hartman > I'm still waiting for feedback on the SMR bit being removed from the > data plane. I don't think there has been any stated support for this on > the list. I made a call in the form of an issue and have seen no > responses. I conducted an extensive search through the last couple of months of email to see what I could find out about this issue. It seems to be a recent thing, since I see on August 10th private email from Dino which talks about (paraphrased) 'not sure whether we are keeping the SMR bit in the data header'. Basically, only two messages to the list since around then mention the issue itself (and a number more as a meta-issue, i.e. about whether it has been finalized, i.e. not about the issue itself). Both of the ones which mention it direct mention it prominently. The first, from Dino: http://www.ietf.org/mail-archive/web/lisp/current/msg01119.html listed it up top, in the very first paragraph. The second, from you: http://www.ietf.org/mail-archive/web/lisp/current/msg01246.html had it as the only issue, and received no responses at all. In addition, the flags field in the user-data header (which is where the SMR bit in question was) has been discussed _extensively_, including this consensus call from you: http://www.ietf.org/mail-archive/web/lisp/current/msg01294.html and the extremely long thread starting here: http://www.ietf.org/mail-archive/web/lisp/current/msg01197.html and nobody mentioned the missing SMR bit. To me, this would seem adequate to show that everyone is happy with getting rid of the data-plane bit (on several occasions the question has been asked directly; and with all the discussion of the flags field, if anyone who is thinking about LISP to any considerable degree was unaware that bit was gone, I would be stunned). If anyone had a problem surely at least _one message_ would have been sent about it. Yes, we didn't get a flood of 'yes that's OK' messages, but in general in the IETF 'silence betokens consent' - how many Last Calls on the main IETF list generate no responses at all, without anyone concluding that that's not acceptable? Anyway, for what it's worth, I'm fine with this change. Noel From jzwiebel@cisco.com Fri Sep 11 16:41: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 3E51E3A69E9 for ; Fri, 11 Sep 2009 16:41:43 -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 mqxbrY5lgRfO for ; Fri, 11 Sep 2009 16:41:42 -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 348FD3A67E9 for ; Fri, 11 Sep 2009 16:41:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAGN9qkqrR7PE/2dsb2JhbACCKS3Ba4hIAY9nBYQYimY X-IronPort-AV: E=Sophos;i="4.44,373,1249257600"; d="scan'208,217";a="387121755" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 11 Sep 2009 23:42:15 +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 n8BNgFvf028249; Fri, 11 Sep 2009 16:42:15 -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 n8BNgFtu012324; Fri, 11 Sep 2009 23:42:15 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 16:42:15 -0700 Received: from [10.0.1.3] ([10.21.74.88]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 16:42:14 -0700 In-Reply-To: <20090911232813.E0EDA6BE553@mercury.lcs.mit.edu> References: <20090911232813.E0EDA6BE553@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-14--472574034 Message-Id: <5CDFE780-48EC-4070-90F5-CFD3B098FB6A@cisco.com> From: John Zwiebel Date: Fri, 11 Sep 2009 13:42:12 -1000 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 11 Sep 2009 23:42:14.0878 (UTC) FILETIME=[7DB707E0:01CA3339] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=957; t=1252712535; x=1253576535; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[lisp]=20I=20am=20not=20posting=20the=2 0-04=20document=20today |Sender:=20; bh=VrRDfvjZNfrV/jCX1AwWJv/WzI33lZJDm41h/S0wSvY=; b=iwleHQ78RQiApHfLDK7aHPtsnLYwmxdIR/ujqSgCPd2JD0iILMVnz9JX4G NppwhDyzTxiUC/opZ7AakSDhM+hKyESobZMC3qf/HcoLlnGq5/ZW0QxdP24U Y337cG2J6/; 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] I am not posting the -04 document today X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 23:41:43 -0000 --Apple-Mail-14--472574034 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 11, 2009, at 1:28 PM, Noel Chiappa wrote: > Yes, we didn't get a flood of 'yes that's OK' messages, but in > general in the Its OK with me. Delete the SMR bit. --Apple-Mail-14--472574034 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
On Sep 11, 2009, at 1:28 PM, Noel Chiappa wrote:

Yes, we didn't get a flood of 'yes that's OK' messages, but in general in the


Its OK with me.
Delete the SMR bit.

--Apple-Mail-14--472574034-- From mrw@sandstorm.net Fri Sep 11 18:24: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 A071B3A69D2 for ; Fri, 11 Sep 2009 18:24:47 -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 oj3X55xQfHFy for ; Fri, 11 Sep 2009 18:24:46 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id B25C128C10B for ; Fri, 11 Sep 2009 18:24:46 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8C1PLbd048825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Sep 2009 21:25:22 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: 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, 11 Sep 2009 21:25:21 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 12 Sep 2009 01:24:47 -0000 On Sep 11, 2009, at 6:24 PM, Sam Hartman wrote: >>>>>> "Margaret" == Margaret Wasserman writes: > > Margaret> I have a new issue that should probably go in the > Margaret> tracker (for resolution in -05 or later, not to hold > Margaret> anything up now). > > Margaret> The UDP-TUNNELS document contains the following > Margaret> restriction: > > Margaret, I think this would be a duplicate of an open issue. Your > existing issue requires us to normatively reference a spec that makes > appropriate standards track changes to permit what we're doing. > > If you believe that Marshall's draft doesn't do that, then we either > need to convince Marshall to do what we want or reference another > draft. > > I don't see how an extra issue will help. > > Does this work for you? No, I don't see why this is a duplicate. I am saying that if we use IPv6/UDP zero checksums, the UDP-TUNNELS spec contains a restriction that we can't send fragments. After reading Fred Templin's mail, I realize that there is another possible solution to this problem -- to state in the fragmentation section that you MUST NOT set the UDP/IPv6 chekcsum to zero for packets that contain fragments. The UDP-TUNNELS draft is written with a different notion of tunnels than LISP -- like somehow the tunnel will be used for one application or one type of traffic. So, it doesn't actually talk about using zero checksums for some packets and non-zero checksums for others. It just says that you must discard, or can't send, certain types of packets. Presumably we don't want LISP ITRs to simply discard packets that are not integrity checked, but I think it would be consistent with UDP- TUNNELS to just use non-zero IPv6/UDP checksums for those packets... Margaret From tme@americafree.tv Sat Sep 12 10:44: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 A51FD3A6953 for ; Sat, 12 Sep 2009 10:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=-1.457, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MANGLED_OFF=2.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 0DyECOcrSRTk for ; Sat, 12 Sep 2009 10:44:33 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 802993A6950 for ; Sat, 12 Sep 2009 10:44:33 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id C17594B5EA04; Sat, 12 Sep 2009 13:45:12 -0400 (EDT) Message-Id: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@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: Sat, 12 Sep 2009 13:45:09 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Sam Hartman , Magnus Westerlund , lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 12 Sep 2009 17:44:34 -0000 Dear Margaret; On Sep 11, 2009, at 9:25 PM, Margaret Wasserman wrote: > > On Sep 11, 2009, at 6:24 PM, Sam Hartman wrote: > >>>>>>> "Margaret" == Margaret Wasserman writes: >> >> Margaret> I have a new issue that should probably go in the >> Margaret> tracker (for resolution in -05 or later, not to hold >> Margaret> anything up now). >> >> Margaret> The UDP-TUNNELS document contains the following >> Margaret> restriction: >> >> Margaret, I think this would be a duplicate of an open issue. Your >> existing issue requires us to normatively reference a spec that makes >> appropriate standards track changes to permit what we're doing. >> >> If you believe that Marshall's draft doesn't do that, then we either >> need to convince Marshall to do what we want or reference another >> draft. I might point out that our draft has not yet been accepted by 6Man, and we are certainly open to changes. This entire discussion here has been very good for our draft. >> >> I don't see how an extra issue will help. >> >> Does this work for you? > > No, I don't see why this is a duplicate. I am saying that if we use > IPv6/UDP zero checksums, the UDP-TUNNELS spec contains a restriction > that we can't send fragments. It says " The tunneling protocol and implementation must not use fragmentation of the inner packets being carried." This comes from an email of Magnus Westerlund ----- [MBONED] WGLC for - UDP checksum? Date: December 5, 2007 3:12:05 PM EST I think it will be acceptable to update RFC 2460 to say that the UDP checksum may be turned of[f] under the following restrictions: 1. The UDP payload must have the capability to verify its integrity by itself, for example by being a complete IP packet in itself. 2. That IP packet fragmentation must not be used. ------ We interpreted "2" as coming from "1" - i.e., the total "outer" packet could be fragmented, but the "inner" packet should not be a fragment of the original "inner" packet, as then I could not verify its integrity by itself. We also interpreted this as both a AD proscription, and as feedback from IPv6 guru's, so we didn't question it much. However, the issue can certainly be raised here. I personally think that we could live with fragments. Here is my reasoning - If I want to send fragments over IPv6 LISP, my understanding is that only the first will have the inner UDP header, and thus the inner fragments after the first will not have any data checks _inside their fragment_. However, when the inner packet is reassembled, it _will_ have a checksum check. This to me fits within the "other integrity checks" mentioned below. - The current draft draft-ietf-lisp-04.txt says (Section 5) 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. 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. I am assuming that the discussion in Section 5.4.1 applies to IPv6 as well as IPv4. Section 5.4.1 : 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. So, again, this would lead to unprotected fragments but errors in the inner packet should be caught at the end. In the Tunneling draft there is an implicit assumption that catching errors only at the end is acceptable. In IPv6 itself, it is also not possible to perform a checksum test except at the end node, as there is no separate checksum for any fragments, so if tunneling was not used, any errors would still only be caught at the end. Magnus might care to provide more insight as to the push-back here, so I have cc:ed him. > > After reading Fred Templin's mail, I realize that there is another > possible solution to this problem -- to state in the fragmentation > section that you MUST NOT set the UDP/IPv6 chekcsum to zero for > packets that contain fragments. > > The UDP-TUNNELS draft is written with a different notion of tunnels > than LISP -- like somehow the tunnel will be used for one > application or one type of traffic. So, it doesn't actually talk > about using zero checksums for some packets and non-zero checksums > for others. It just says that you must discard, or can't send, > certain types of packets. Presumably we don't want LISP ITRs to > simply discard packets that are not integrity checked, but I think > it would be consistent with UDP-TUNNELS to just use non-zero IPv6/ > UDP checksums for those packets... > It certainly would. - draft-eubanks-chimento-6man is intended to allow for tunneling uses without an outer packet checksum in the case where the inner packet does have a checksum. That way, on an end to end basis, the packets will be checked. - Yes, that does imply it is intended for applications that only send inner packets with checksums or check to verify that the inner packet checksum is present. - My understanding is that LISP is such a situation, and that is how I read the draft. I regard how stringently this should be enforced as open to discussion and debate (i.e., what other integrity checks are acceptable), but I don't think we are going to get a "ignore all checksums" addition to IPv6. Regards Marshall > Margaret > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From hartmans@mit.edu Fri Sep 11 15:23: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 194AE28C147 for ; Fri, 11 Sep 2009 15:23: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 ii3vVjnMIsal for ; Fri, 11 Sep 2009 15:23: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 690D93A680B for ; Fri, 11 Sep 2009 15:23:43 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1FBCD452E; Fri, 11 Sep 2009 18:24:01 -0400 (EDT) To: Margaret Wasserman References: From: Sam Hartman Date: Fri, 11 Sep 2009 18:24:01 -0400 In-Reply-To: (Margaret Wasserman's message of "Fri\, 11 Sep 2009 16\:08\:10 -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 X-Mailman-Approved-At: Sat, 12 Sep 2009 13:45:22 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 11 Sep 2009 22:23:44 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> I have a new issue that should probably go in the Margaret> tracker (for resolution in -05 or later, not to hold Margaret> anything up now). Margaret> The UDP-TUNNELS document contains the following Margaret> restriction: Margaret, I think this would be a duplicate of an open issue. Your existing issue requires us to normatively reference a spec that makes appropriate standards track changes to permit what we're doing. If you believe that Marshall's draft doesn't do that, then we either need to convince Marshall to do what we want or reference another draft. I don't see how an extra issue will help. Does this work for you? From jnc@mercury.lcs.mit.edu Sat Sep 12 14:08: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 56AB43A67E2 for ; Sat, 12 Sep 2009 14:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 QDo6aab9iwXv for ; Sat, 12 Sep 2009 14:08:29 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 8A92D3A6906 for ; Sat, 12 Sep 2009 14:08:29 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 07FB66BE5D9; Sat, 12 Sep 2009 17:09:08 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090912210909.07FB66BE5D9@mercury.lcs.mit.edu> Date: Sat, 12 Sep 2009 17:09:08 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu 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: Sat, 12 Sep 2009 21:08:30 -0000 > From: Margaret Wasserman > I also personally prefer a "SHOULD" for IPv6 ETRs to accept incoming > packets with a zero checksum (to support implementation on existing > desktop systems) The problem which that would cause is that we would likely have pair-wise black holes. If such an ETR is interacting with an ITR which is sending packets with zero UDPv6 checksums (which under the current text it 'MAY' do), all the traffic will be tossed. (And my apologies if that was already perfectl clear to you, and I've misunderstood your point here.) We could get rid of the black holes by adding a status bit to the Map-Reply message ('this ETR accepts zero UDPv6 checksums'), and changing the spec (and code) to say that ITRs which wish to send packets to that ETR have to compute UDPv6 checkums unless that bit is set. Even then, though, we could still find that there are pairs of xTRs which cannot communicate, if there are some ITRs which cannot easily compute UDP checkums. I am given to understand by a message here (too lazy to look for it in the archives) that some router boxes only have access to headers, and can't checksum the packet. We could go the other way and add a status bit to the Map-Reply message ('this ETR does not accepts zero UDPv6 checksums'), and change the spec (and code) to say that ITRs either i) have to compute UDPv6 checkums iff that bit is set, or ii) not use such ETRs. Again, that would fix the black holes, but ETRs which cannot accept zero checksums would almost certainly be unable to communicate with some ITRs. But if we don't add that complexity, we either have to have 'MUST accept zero checksums', or we have to delete 'MAY send zero checksums' - or black holes will result. > but I understand that others' opinions differ. I want to make sure I understand what this means (in terms of implications). Is this to be read as 'you aren't happy with the existing text, but can live with it', or did you want to do something else? Noel From luigi@net.t-labs.tu-berlin.de Sun Sep 13 03:48: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 675083A67AE for ; Sun, 13 Sep 2009 03:48:18 -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 OAHUqQoUjKza for ; Sun, 13 Sep 2009 03:48:17 -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 96A003A67FB for ; Sun, 13 Sep 2009 03:48:17 -0700 (PDT) Received: from [192.168.2.101] (p4FC25F97.dip.t-dialin.net [79.194.95.151]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 3DBB97067A63; Sun, 13 Sep 2009 12:48:57 +0200 (CEST) Message-Id: From: Luigi Iannone 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 v936) Date: Sun, 13 Sep 2009 12:48:56 +0200 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] I am not posting the -04 document today X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 13 Sep 2009 10:48:18 -0000 On Sep 12, 2009, at 1:00 , Dino Farinacci wrote: >>>>>>> "Dino" == Dino Farinacci writes: >> 8 >> Dino> One of the chairs (Sam) feels we have not reached >> Dino> consensus. I thought we had. >> >> First, I'm still waiting for feedback on the SMR bit being removed >> from the data plane. I don't think there has been any stated support >> for this on the list. I made a call in the form of an issue and have >> seen no responses. > > I support this. +1 > > And I know the core LISP team at cisco has had conversations both on > and off the list with the UCL-B guys and we all agreed that mapping- > updates should be out of the data plane. Almost.... Our position was that SMR bit in the data-plane could be somehow tricky to manage. But has his value in the control-plane. We still think that versioning can be useful in the data-plane and we would like to make experiment with it (but this has been discussed in another thread). Luigi > That means the spec should not have version numbers in it or a SMR- > bit in it. > > So just making it clear what I thought we had consensus on. And when > we brought it to the list, no one objected. > >> Dino thinks I just missed the discussion. >> So, if you spoke up in the past in support of this, please do so >> again; this is really important to resolve. >> >> The second issue is #19, the mobility bit. I explained why I don't >> believe we can include that. > > My understanding was to include the M bit so it can be allocated and > indicate that it will be described in a future spec. Joel asked me > to put that text in, and that is what I did. > > Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From mrw@sandstorm.net Sun Sep 13 05:45: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 764AC3A6823 for ; Sun, 13 Sep 2009 05:45:54 -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 9PEjTpEfIMNN for ; Sun, 13 Sep 2009 05:45:53 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 8236F3A63C9 for ; Sun, 13 Sep 2009 05:45:53 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8DCkGCU016682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Sep 2009 08:46:16 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090912210909.07FB66BE5D9@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: Sun, 13 Sep 2009 08:46:15 -0400 References: <20090912210909.07FB66BE5D9@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) 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: Sun, 13 Sep 2009 12:45:54 -0000 Hi Noel, Most of your message boils down to something I think we both know... If we want to write an interoperable specification that includes multiple options that are not interoperable, we have two choices: (1) State that it is mandatory to support one of the choices on both ends, and signal/negotiate the use of any of the other options. (2) Require all implementations of one end of the connection (in our case either the ITR or the ETR) to support all of the options. At this point, the LISP specification achieves interoperability for IPv6/UDP checksums by requiring ETRs to accept IPv6/UDP/LISP packets with both zero or non-zero checksums. So, the text in the LISP -04 specification is theoretically sound. With the text we have in -04, though, we will still have a _practical_ problem with black holes. There are many currently deployed systems that are _not capable_ of accepting a packet with an IPv6/UDP checksum of zero, and they will not gain the ability to do so simply because the LISP specification says that ETRs MUST accept them. This is _not_ a performance issue. LISP simply _will not work_ over IPv6 on those systems. The list includes all deployed copies of every major operating system, all currently deployed IPv6-capable CPE equipment, and the checksum offload hardware in all recently-shipped Macs and many (perhaps most) recently-shipped PCs. Getting these things upgraded to accept IPv6/UDP zero checksums would take at least 7-to-10 years, and the clock _won't even start_ until LISP becomes popular enough to affect the implementation of host operating systems and network interface cards So, with luck, we will be able to implement a compliant IPv6-capable LISP ETR on most end nodes (to support things like mobile LISP) in the early 2020's. We are making this choice to allow an _optimization_ on some existing high-end routers that _can and do_ (or at least claim to) support the calculation of UDP checksums on both ends when UDP checksums are enabled for other UDP-based tunneling protocols, such as L2TP. The only interoperable choice (if we must use UDP) that is _actually available_ on all of these systems is to require both ITRs and ETRs to handle packets with non-zero IPv6/UDP checksums, and for ITRs to only send IPv6/UDP zero checksums when there is an indication from the other side that they are supported. For some reason, though, the WG seems to be choosing an optimization for high-end routers over the ability to implement LISP on widely deployed host systems. I think that is a _huge_ mistake, and an incorrect technical choice for an IETF specification. On Sep 12, 2009, at 5:09 PM, Noel Chiappa wrote: > >> but I understand that others' opinions differ. > > I want to make sure I understand what this means (in terms of > implications). Is this to be read as 'you aren't happy with the > existing text, but can live with it', or did you want to do something > else? I am not satisfied with the current text, for the reasons I have stated above. I do not think that I am ever going to convince a lot of folks from a large router vendor to change their minds about this, though... So, I will accept that I am in the rough, and we can move on. Margaret From mrw@sandstorm.net Sun Sep 13 05:49: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 C07B03A6800 for ; Sun, 13 Sep 2009 05:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_TOOL=2.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 oyugnEsFL9jQ for ; Sun, 13 Sep 2009 05:49:55 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id F22243A67AC for ; Sun, 13 Sep 2009 05:49:54 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8DCoWDZ016875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Sep 2009 08:50:33 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <8472C95A-6A64-4405-921F-2DD8AB6D0211@sandstorm.net> From: Margaret Wasserman To: Luigi Iannone 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: Sun, 13 Sep 2009 08:50:32 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] I am not posting the -04 document today X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 13 Sep 2009 12:49:55 -0000 On Sep 13, 2009, at 6:48 AM, Luigi Iannone wrote: > > On Sep 12, 2009, at 1:00 , Dino Farinacci wrote: > >>>>>>>> "Dino" == Dino Farinacci writes: >>> 8 >>> Dino> One of the chairs (Sam) feels we have not reached >>> Dino> consensus. I thought we had. >>> >>> First, I'm still waiting for feedback on the SMR bit being removed >>> from the data plane. I don't think there has been any stated >>> support >>> for this on the list. I made a call in the form of an issue and >>> have >>> seen no responses. >> >> I support this. > > +1 Me, too -- +1. > >>> The second issue is #19, the mobility bit. I explained why I don't >>> believe we can include that. >> >> My understanding was to include the M bit so it can be allocated >> and indicate that it will be described in a future spec. Joel asked >> me to put that text in, and that is what I did. I do not agree with including the M bit, and I didn't perceive that we had consensus to do so. Several of us indicated that we should not include any bits in the main spec, unless their mechanism is described in (or normatively referenced from) the main spec. I have no problem with the mobility spec allocating an M-bit for its own use, and I think we should support that through an appropriate IANA considerations section in the LISP specification. Margaret From mrw@sandstorm.net Sun Sep 13 06:24: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 534F93A6842 for ; Sun, 13 Sep 2009 06:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.115, 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 7Rocq3AQ034k for ; Sun, 13 Sep 2009 06:24:19 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 4C0213A677C for ; Sun, 13 Sep 2009 06:24:19 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8DDOnHa018413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Sep 2009 09:24:49 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Marshall Eubanks In-Reply-To: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@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: Sun, 13 Sep 2009 09:24:48 -0400 References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> X-Mailer: Apple Mail (2.935.3) Cc: Sam Hartman , Magnus Westerlund , lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 13 Sep 2009 13:24:20 -0000 Hi Marshall, Just FYI -- the UDP-TUNNEL draft is now expired. You might want to update (or resubmit) it. On Sep 12, 2009, at 1:45 PM, Marshall Eubanks wrote: > We also interpreted this as both a AD proscription, and as feedback > from IPv6 guru's, so we didn't question it much. However, the issue > can certainly be raised here. These issues can definitely be discussed further, alhtough perhaps it would be better to discuss them in 6man. I'll wait for an explanation from Magnus about why he proposed this restriction before stating an opinion on whether or not to remove it. In general, though, it would be good to explain the reasons for all of the restrictions in your draft, so that people won't be inclined to ignore them without realizing why they are important. If we can't give a good explanation of the reasons for a particular restriction, perhaps we should take it out. >> The UDP-TUNNELS draft is written with a different notion of tunnels >> than LISP -- like somehow the tunnel will be used for one >> application or one type of traffic. So, it doesn't actually talk >> about using zero checksums for some packets and non-zero checksums >> for others. It just says that you must discard, or can't send, >> certain types of packets. Presumably we don't want LISP ITRs to >> simply discard packets that are not integrity checked, but I think >> it would be consistent with UDP-TUNNELS to just use non-zero IPv6/ >> UDP checksums for those packets... >> > > It certainly would. > > - draft-eubanks-chimento-6man is intended to allow for tunneling > uses without an outer packet checksum in the case where the inner > packet does have a checksum. That way, on an end to end basis, the > packets will be checked. > > - Yes, that does imply it is intended for applications that only > send inner packets with checksums or check to verify that the inner > packet checksum is present. > > - My understanding is that LISP is such a situation, and that is how > I read the draft. LISP currently does nothing to ensure that "inner" packets have any sort of integrity checking. LISP does not (currently) discard UDP packets that have zero checksums before tunneling them as required in UDP-TUNNELS, and it doesn't do anything else to check that the inner packets have integrity checks. The LISP documents also describe a case where LISP packets would be tunneled in another LISP outer header for Traffic Engineering purposes. In that case, encapsulating an existing LISP packet (with a zero UDP checksum) in an IPv6/UDP/LISP header with a zero UDP checksum would clearly violate the restrictions in UDP-TUNNELs. > > I regard how stringently this should be enforced as open to > discussion and debate (i.e., what other integrity checks are > acceptable), but I don't think we are going to get a "ignore all > checksums" addition to IPv6.= I do understand that some of this could change, and hopefully LISP Folks will work with 6man to try to get our needs met. But in the meantime, we have two drafts, one of which normatively references the other, that are incompatible in certain ways. IMO, we should log a LISP issue indicating that LISP (-04) is not fully compatible with UDP-TUNNEL (-00) in four ways: (2) LISP does not discard packets with zero UDP checksums before enapsulating them in IPv6/UDP with a zero UDP checksum. (2) LISP does not ensure that all encapsulated packets contain an inner integrity checking mechanism before encapsulating in IPv6/UDP with a zero UDP checksum. (3) LISP contains an option that would result in fragmentation of inner packets, and it does not indicate that non-zero UDP checksums must be used when these packets are encapsulated in an IPv6 LISP header. (4) The LISP specifications provide for encapsulating LISP packets within a second LISP header and it does not indicate that non-zero UDP checksums must be used when the new outer header is an IPv6 LISP header. This issue will insure that we don't forget to check for compatibility between LISP and UDP-TUNNELS before we publish the LISP RFCs. After we enter the issue in the tracker, I think we should park the issue (for the LISP group, at least) and re-visit it after the 6man group (with help from those of us who participate) reaches consensus on the final form (if any) of the UDP-TUNNEL document. When UDP- TUNNEL is no longer a moving target, we can assess what changes (if any) will be required for LISP to use it properly. Margaret From tme@americafree.tv Sun Sep 13 11: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 08B8F3A6927 for ; Sun, 13 Sep 2009 11:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 GvfYS86hidBV for ; Sun, 13 Sep 2009 11:47:36 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id C333E3A6919 for ; Sun, 13 Sep 2009 11:47:35 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 546004B75EDD; Sun, 13 Sep 2009 14:48:17 -0400 (EDT) Message-Id: 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: Sun, 13 Sep 2009 14:48:16 -0400 References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> X-Mailer: Apple Mail (2.936) Cc: Sam Hartman , Magnus Westerlund , lisp@ietf.org, "Philip F. Chimento" Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 13 Sep 2009 18:47:37 -0000 On Sep 13, 2009, at 9:24 AM, Margaret Wasserman wrote: > > Hi Marshall, > > Just FYI -- the UDP-TUNNEL draft is now expired. You might want to > update (or resubmit) it. > > On Sep 12, 2009, at 1:45 PM, Marshall Eubanks wrote: >> We also interpreted this as both a AD proscription, and as feedback >> from IPv6 guru's, so we didn't question it much. However, the issue >> can certainly be raised here. > > These issues can definitely be discussed further, alhtough perhaps > it would be better to discuss them in 6man. I'll wait for an > explanation from Magnus about why he proposed this restriction > before stating an opinion on whether or not to remove it. In > general, though, it would be good to explain the reasons for all of > the restrictions in your draft, so that people won't be inclined to > ignore them without realizing why they are important. If we can't > give a good explanation of the reasons for a particular restriction, > perhaps we should take it out. I think that is a good principle, and one that would certainly apply here. > >>> The UDP-TUNNELS draft is written with a different notion of >>> tunnels than LISP -- like somehow the tunnel will be used for one >>> application or one type of traffic. So, it doesn't actually talk >>> about using zero checksums for some packets and non-zero checksums >>> for others. It just says that you must discard, or can't send, >>> certain types of packets. Presumably we don't want LISP ITRs to >>> simply discard packets that are not integrity checked, but I think >>> it would be consistent with UDP-TUNNELS to just use non-zero IPv6/ >>> UDP checksums for those packets... >>> >> >> It certainly would. >> >> - draft-eubanks-chimento-6man is intended to allow for tunneling >> uses without an outer packet checksum in the case where the inner >> packet does have a checksum. That way, on an end to end basis, the >> packets will be checked. >> >> - Yes, that does imply it is intended for applications that only >> send inner packets with checksums or check to verify that the inner >> packet checksum is present. >> >> - My understanding is that LISP is such a situation, and that is >> how I read the draft. > > LISP currently does nothing to ensure that "inner" packets have any > sort of integrity checking. LISP does not (currently) discard UDP > packets that have zero checksums before tunneling them as required > in UDP-TUNNELS, and it doesn't do anything else to check that the > inner packets have integrity checks. > It also, AFAIKT, verify those integrity checks in any way. IPv6 in IPv6 tunnels and IPv6 in IPv4 tunnels in LISP should not have this problem, correct ? (As incoming UDP packets, they would be subject to RFC 2460.) Now, IPv4 in IPv4 is not an issue, and that leaves IPv4 in IPv6 tunnels - do you agree with this reasoning ? It might be possible to treat 4n6 traffic as a corner case. Suppose, for example, that LISP requires 4n6 traffic to have checksums. Now, if the same traffic arrives for a 4n4 tunnel, and the ITR _doesn't check the incoming checksum_ and puts the traffic in the tunnel, it seems to me that that the 4n4 traffic is also unprotected end-to-end. A question that occurs to me is to what extent control traffic (i.e., non-UDP and non-TCP traffic) would be carried over LISP, and to whether any of that traffic is not protected by other means. > The LISP documents also describe a case where LISP packets would be > tunneled in another LISP outer header for Traffic Engineering > purposes. In that case, encapsulating an existing LISP packet > (with a zero UDP checksum) in an IPv6/UDP/LISP header with a zero > UDP checksum would clearly violate the restrictions in UDP-TUNNELs. I look forward to the thrashing out of the needs for this in LISP, and also the reasons not to allow unprotected tunnels-in-tunnels. >> >> I regard how stringently this should be enforced as open to >> discussion and debate (i.e., what other integrity checks are >> acceptable), but I don't think we are going to get a "ignore all >> checksums" addition to IPv6.= > > I do understand that some of this could change, and hopefully LISP > Folks will work with 6man to try to get our needs met. But in the > meantime, we have two drafts, one of which normatively references > the other, that are incompatible in certain ways. > > IMO, we should log a LISP issue indicating that LISP (-04) is not > fully compatible with UDP-TUNNEL (-00) in four ways: > > (2) LISP does not discard packets with zero UDP checksums before > enapsulating them in IPv6/UDP with a zero UDP checksum. > (2) LISP does not ensure that all encapsulated packets contain an > inner integrity checking mechanism before encapsulating in IPv6/UDP > with a zero UDP checksum. > (3) LISP contains an option that would result in fragmentation of > inner packets, and it does not indicate that non-zero UDP checksums > must be used when these packets are encapsulated in an IPv6 LISP > header. > (4) The LISP specifications provide for encapsulating LISP packets > within a second LISP header and it does not indicate that non-zero > UDP checksums must be used when the new outer header is an IPv6 LISP > header. > > This issue will insure that we don't forget to check for > compatibility between LISP and UDP-TUNNELS before we publish the > LISP RFCs. > > After we enter the issue in the tracker, I think we should park the > issue (for the LISP group, at least) and re-visit it after the 6man > group (with help from those of us who participate) reaches consensus > on the final form (if any) of the UDP-TUNNEL document. When UDP- > TUNNEL is no longer a moving target, we can assess what changes (if > any) will be required for LISP to use it properly. > I think that all of this is reasonable. We will our this draft soon, and I hope to summarize all of this discussion at 6Man in Hiroshima. Regards Marshall > Margaret > > > > > > > > From mrw@sandstorm.net Sun Sep 13 12:32: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 BEF2C3A6868 for ; Sun, 13 Sep 2009 12:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.105, 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 UQaW163hcDeB for ; Sun, 13 Sep 2009 12:32:58 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id CD2F73A67BD for ; Sun, 13 Sep 2009 12:32:57 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8DJXPI3031263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Sep 2009 15:33:26 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <8CC8E720-1325-46DB-8458-6EBDB8722209@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: Sun, 13 Sep 2009 15:33:25 -0400 References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> X-Mailer: Apple Mail (2.935.3) Cc: Sam Hartman , Magnus Westerlund , lisp@ietf.org, "Philip F. Chimento" Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 13 Sep 2009 19:32:58 -0000 On Sep 13, 2009, at 2:48 PM, Marshall Eubanks wrote: > > It might be possible to treat 4n6 traffic as a corner case. Suppose, > for example, that LISP requires 4n6 traffic to have checksums. Now, > if the same traffic arrives for a 4n4 tunnel, and the ITR _doesn't > check the incoming checksum_ and puts the traffic in the tunnel, it > seems to me that that the 4n4 traffic is also unprotected end-to-end. The difference is that the UDP checksum does two things in IPv6, while it only does one thing in IPv4... - In IPv4, the UDP checksum is used to provide end-to-end integrity checking for the UDP header and data. Its coverage of the IP header fields is redundant, and sometimes annoying. The IPv4 header checksum is responsible for ensuring that the packets are delivered to the correct destination. - In IPv6, the UDP checksum performs both functions: it offers end-to- end integrity checking _and_ assurance that the packet reaches the right destination. To get something in IPv6 that behaves like IPv4/UDP with zero UDP checksums, you can't just set the IPv6/UDP checksum to zero. That would be like an IPv4 packet with no IPv4 header checksum AND no UDP checksum. To get something like an IPv4/UDP packet with no UDP checksum in IPv6, you need to use IPv6/UDP-Lite. That way, the important IP header fields are checksummed, and the data is not. We should realize, that when we start proposing that IPv6 header checksums are not needed for lightweight tunnels, this is the same as proposing that we turn off IPv4 header checksums AND UDP checksum for the tunnel. I understand that there are objections to using UDP-Lite as the encapsulation protocol for IPv6, as some currently deployed load balancing equipment won't use the UDP-Lite source port or the IPv6 flow label as part of its flow hash. I'm beginning to strongly believe, though, that using IPv6/UDP-Lite/LISP as the IPv6 encapsulation might be the best choice that we have available, since our other choices seem to be that we could eliminate the possibility of implementing LISP on commodity systems any time soon, or we could significantly reduce its performance on existing router hardware. Neither of those choices seems good to me, and they both seem worse (at least in the mid-term) than not having our LISP flows properly identified by load balancing equipment. > A question that occurs to me is to what extent control traffic > (i.e., non-UDP and non-TCP traffic) would be carried over LISP, and > to whether any of that > traffic is not protected by other means. We'd actually _like_ to create a world in IPv6 where there can be new transport layer protocols that _aren't_ just used for special-purpose or control traffic. Margaret From jmh@joelhalpern.com Sun Sep 13 13:28: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 B3C053A67B0 for ; Sun, 13 Sep 2009 13:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 51wpfpFGSFJF for ; Sun, 13 Sep 2009 13:28:29 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DC6473A6784 for ; Sun, 13 Sep 2009 13:28:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 09C3C430252; Sun, 13 Sep 2009 13:29:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.10] (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 1CCB843024E; Sun, 13 Sep 2009 13:29:12 -0700 (PDT) Message-ID: <4AAD5616.3040602@joelhalpern.com> Date: Sun, 13 Sep 2009 16:29:10 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Margaret Wasserman References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> In-Reply-To: <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Hartman , Magnus Westerlund , lisp@ietf.org, "Philip F. Chimento" Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 13 Sep 2009 20:28:30 -0000 If we are willing to expect load balancers to handle UDP-Lite, we can as easily expect them to just use the flow-id filed. Then we don't bother with a UDP header at all. I can see reasons for sticking with UDP. But once we step past that, I do not follow the reason for some other intermediate between the IP and LISP headers. Yours, Joel Margaret Wasserman wrote: > > On Sep 13, 2009, at 2:48 PM, Marshall Eubanks wrote: >> >> It might be possible to treat 4n6 traffic as a corner case. Suppose, >> for example, that LISP requires 4n6 traffic to have checksums. Now, if >> the same traffic arrives for a 4n4 tunnel, and the ITR _doesn't check >> the incoming checksum_ and puts the traffic in the tunnel, it seems to >> me that that the 4n4 traffic is also unprotected end-to-end. > > The difference is that the UDP checksum does two things in IPv6, while > it only does one thing in IPv4... > > - In IPv4, the UDP checksum is used to provide end-to-end integrity > checking for the UDP header and data. Its coverage of the IP header > fields is redundant, and sometimes annoying. The IPv4 header checksum > is responsible for ensuring that the packets are delivered to the > correct destination. > > - In IPv6, the UDP checksum performs both functions: it offers > end-to-end integrity checking _and_ assurance that the packet reaches > the right destination. > > To get something in IPv6 that behaves like IPv4/UDP with zero UDP > checksums, you can't just set the IPv6/UDP checksum to zero. That would > be like an IPv4 packet with no IPv4 header checksum AND no UDP > checksum. To get something like an IPv4/UDP packet with no UDP checksum > in IPv6, you need to use IPv6/UDP-Lite. That way, the important IP > header fields are checksummed, and the data is not. We should realize, > that when we start proposing that IPv6 header checksums are not needed > for lightweight tunnels, this is the same as proposing that we turn off > IPv4 header checksums AND UDP checksum for the tunnel. > > I understand that there are objections to using UDP-Lite as the > encapsulation protocol for IPv6, as some currently deployed load > balancing equipment won't use the UDP-Lite source port or the IPv6 flow > label as part of its flow hash. I'm beginning to strongly believe, > though, that using IPv6/UDP-Lite/LISP as the IPv6 encapsulation might be > the best choice that we have available, since our other choices seem to > be that we could eliminate the possibility of implementing LISP on > commodity systems any time soon, or we could significantly reduce its > performance on existing router hardware. Neither of those choices seems > good to me, and they both seem worse (at least in the mid-term) than not > having our LISP flows properly identified by load balancing equipment. > >> A question that occurs to me is to what extent control traffic (i.e., >> non-UDP and non-TCP traffic) would be carried over LISP, and to >> whether any of that >> traffic is not protected by other means. > > We'd actually _like_ to create a world in IPv6 where there can be new > transport layer protocols that _aren't_ just used for special-purpose or > control traffic. > > Margaret > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From mrw@sandstorm.net Sun Sep 13 14:06: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 0C4C33A683D for ; Sun, 13 Sep 2009 14:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.096, 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 EpswLF3PoeXg for ; Sun, 13 Sep 2009 14:06:36 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 42E7D3A681C for ; Sun, 13 Sep 2009 14:06:36 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8DL75vv034028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Sep 2009 17:07:05 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> From: Margaret Wasserman To: "Joel M. Halpern" In-Reply-To: <4AAD5616.3040602@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: Sun, 13 Sep 2009 17:07:04 -0400 References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) Cc: Sam Hartman , Magnus Westerlund , lisp@ietf.org, "Philip F. Chimento" Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 13 Sep 2009 21:06:37 -0000 On Sep 13, 2009, at 4:29 PM, Joel M. Halpern wrote: > If we are willing to expect load balancers to handle UDP-Lite, we > can as easily expect them to just use the flow-id filed. Then we > don't bother with a UDP header at all. > I can see reasons for sticking with UDP. But once we step past > that, I do not follow the reason for some other intermediate between > the IP and LISP headers. Well, the problem is that if we run LISP directly over IPv6, the LISP header would (I believe) be required to include an IPv6 pseudo-header checksum... Of course that can fit in 2 bytes, while a UDP-Lite header takes 8 bytes, so that still might be the better way to go. It makes the differences between IPv4 and IPv6 extend into the LISP header, though, instead of being constrained to the IP(v4/v6)/UDP(- Lite) encapsulation. Margaret From jmh@joelhalpern.com Sun Sep 13 15:08: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 53DF33A685C for ; Sun, 13 Sep 2009 15:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.254 X-Spam-Level: X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, 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 tAPoHV1E+1u9 for ; Sun, 13 Sep 2009 15:08:50 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 92E3D3A67A6 for ; Sun, 13 Sep 2009 15:08:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E47A04303BA; Sun, 13 Sep 2009 15:09:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.10] (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 426EB430265; Sun, 13 Sep 2009 15:09:33 -0700 (PDT) Message-ID: <4AAD6D9B.1020400@joelhalpern.com> Date: Sun, 13 Sep 2009 18:09:31 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Margaret Wasserman References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> In-Reply-To: <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Hartman , Magnus Westerlund , lisp@ietf.org, "Philip F. Chimento" Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 13 Sep 2009 22:08:51 -0000 I do not follow your reasoning. Yes, IPv6 decided that it could dispense with the header checksum, because the carried thing has checksums. But the thing that needs to be protected (if something needs protection) is that actual data packet. I read the IPv6 decision as sensibly leaving the degree of pr4otection desired to the carried protocol. It dispenses with a delivery header checksum. That does not mean that everything else is required to protect every byte. The LISP header is serving a function very similar to an IP header. IPv6 in IPv6 is a well defined tunnel, and is not required to carry a header checksum. We have a LOT of tunnels. Many of them are permitted over IPv6 without a header checksum. Yours, Joel Margaret Wasserman wrote: > > On Sep 13, 2009, at 4:29 PM, Joel M. Halpern wrote: > >> If we are willing to expect load balancers to handle UDP-Lite, we can >> as easily expect them to just use the flow-id filed. Then we don't >> bother with a UDP header at all. >> I can see reasons for sticking with UDP. But once we step past that, >> I do not follow the reason for some other intermediate between the IP >> and LISP headers. > > > Well, the problem is that if we run LISP directly over IPv6, the LISP > header would (I believe) be required to include an IPv6 pseudo-header > checksum... Of course that can fit in 2 bytes, while a UDP-Lite header > takes 8 bytes, so that still might be the better way to go. It makes > the differences between IPv4 and IPv6 extend into the LISP header, > though, instead of being constrained to the IP(v4/v6)/UDP(-Lite) > encapsulation. > > Margaret > > From jzwiebel@cisco.com Sun Sep 13 19:17: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 B840E3A683F for ; Sun, 13 Sep 2009 19:17:46 -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=[AWL=-0.000, 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 GPPkhl-Tec2m for ; Sun, 13 Sep 2009 19:17:45 -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 CFAF03A680F for ; Sun, 13 Sep 2009 19:17:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugEAEBErUqrR7O6/2dsb2JhbACCKS3AR4hMAY4EBYQY X-IronPort-AV: E=Sophos;i="4.44,381,1249257600"; d="scan'208,217";a="204186486" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 14 Sep 2009 02:18: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 n8E2ISR6029585; Sun, 13 Sep 2009 19:18:28 -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 n8E2IS8j007538; Mon, 14 Sep 2009 02:18:28 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Sep 2009 19:18:28 -0700 Received: from [10.0.1.3] ([10.21.118.160]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Sep 2009 19:18:28 -0700 In-Reply-To: <8472C95A-6A64-4405-921F-2DD8AB6D0211@sandstorm.net> References: <8472C95A-6A64-4405-921F-2DD8AB6D0211@sandstorm.net> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-36--290401371 Message-Id: <9B93E45D-92DE-4D5C-92F8-773C6DDB29D4@cisco.com> From: John Zwiebel Date: Sun, 13 Sep 2009 16:18:25 -1000 To: Margaret Wasserman X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 14 Sep 2009 02:18:28.0331 (UTC) FILETIME=[A58DF3B0:01CA34E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1999; t=1252894708; x=1253758708; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[lisp]=20I=20am=20not=20posting=20the=2 0-04=20document=20today |Sender:=20; bh=V2DakXhuqannBwfNLN3A+ARt17yffRQswz7UV3opLqo=; b=EURYJ08cxtWZnPvAepSDpApegK3+oovjux55hXW+Ffw5B3KHGb0ghC13zg sSCuAhTj5aFt4JyHYJBMGU5EniUZYsVkqnKrh2psT63ff1Lr8lyp3blrZnEB 6r8q4RBu40; Authentication-Results: sj-dkim-2; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] I am not posting the -04 document today X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 14 Sep 2009 02:17:46 -0000 --Apple-Mail-36--290401371 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 13, 2009, at 2:50 AM, Margaret Wasserman wrote: >>> >>> My understanding was to include the M bit so it can be allocated >>> and indicate that it will be described in a future spec. Joel >>> asked me to put that text in, and that is what I did. > > I do not agree with including the M bit, and I didn't perceive that > we had consensus to do so. How many does it take to make a consensus? I'm for including the M-bit. --Apple-Mail-36--290401371 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII
On Sep 13, 2009, at 2:50 AM, Margaret Wasserman = wrote:


My understanding was to include the M bit so it can be allocated = and indicate that it will be described in a future spec. Joel asked me = to put that text in, and that is what I did.

=


I do not agree with including the M bit, and I didn't = perceive that we had consensus to do so. 

=

How many does it take to make a = consensus?

I'm for including the = M-bit.
= --Apple-Mail-36--290401371-- From mrw@sandstorm.net Sun Sep 13 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 8652E3A6855 for ; Sun, 13 Sep 2009 20:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_28=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 fuE-+lSemREV for ; Sun, 13 Sep 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 BB1AC3A67D1 for ; Sun, 13 Sep 2009 20:09:31 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8E3A82B043936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Sep 2009 23:10:09 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <6CF76144-0312-4F4A-8E26-97765C964195@sandstorm.net> From: Margaret Wasserman To: "Joel M. Halpern" In-Reply-To: <4AAD6D9B.1020400@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: Sun, 13 Sep 2009 23:10:08 -0400 References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> <4AAD6D9B.1020400@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) Cc: Sam Hartman , Magnus Westerlund , lisp@ietf.org, "Philip F. Chimento" Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 14 Sep 2009 03:09:32 -0000 On Sep 13, 2009, at 6:09 PM, Joel M. Halpern wrote: > I do not follow your reasoning. > Yes, IPv6 decided that it could dispense with the header checksum, > because the carried thing has checksums. > But the thing that needs to be protected (if something needs > protection) is that actual data packet. > I read the IPv6 decision as sensibly leaving the degree of > pr4otection desired to the carried protocol. It dispenses with a > delivery header checksum. That does not mean that everything else > is required to protect every byte. > > The LISP header is serving a function very similar to an IP header. > IPv6 in IPv6 is a well defined tunnel, and is not required to carry > a header checksum. We have a LOT of tunnels. Many of them are > permitted over IPv6 without a header checksum. If we can do IPV6/LISP without the need to add an IPv6 pseudo header checksum to the LISP header, I think that is probably better than IPV6/ UDP-Lite/LISP, if only because it saves 8 bytes. It does, of course, make the IPv6 encapsulation more different from the IPv4 encapsulation, but I don't see why that is a major problem. Margaret From hartmans@mit.edu Mon Sep 14 05:33: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 6A1CC3A67F2 for ; Mon, 14 Sep 2009 05:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=-0.756, 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 mG5QSWVfNV2Q for ; Mon, 14 Sep 2009 05:33:41 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id BD35E3A67E6 for ; Mon, 14 Sep 2009 05:33:41 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EDBA34558; Mon, 14 Sep 2009 08:34:22 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Mon, 14 Sep 2009 08:34:22 -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] #20: supporting SMR bit only in control plane X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 14 Sep 2009 12:33:42 -0000 This change seems to make things simpler and doesn't remove any functionality. To actually get a map request and reply you're going to need to use the control plane. One additional packet to update a mapping (instead of using a bit in a data plane packet) seems like not too big of a change. From hartmans@mit.edu Mon Sep 14 05:38: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 1CE643A6828 for ; Mon, 14 Sep 2009 05:38:11 -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 ijdv3i420FXx for ; Mon, 14 Sep 2009 05:38: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 61D063A67E6 for ; Mon, 14 Sep 2009 05:38:10 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 018C44558; Mon, 14 Sep 2009 08:38:51 -0400 (EDT) To: Sam Hartman References: From: Sam Hartman Date: Mon, 14 Sep 2009 08:38:51 -0400 In-Reply-To: (Sam Hartman's message of "Mon\, 14 Sep 2009 08\:34\:22 -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] #20 consensus call: SMR bit in control plane only X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 14 Sep 2009 12:38:11 -0000 We've seen seen support from Dino, Luigi and I. Unless there are significant objections raised by Monday, 21, then we have consensus for this change. I'll note that I'm about 60 messages behind on the list now (most of that over the weekend but some Friday) and so I may have missed traffic on this. I'm not going to have a lot of time to work on WG stuff today so it will be a day or so before I catch up. Sam Hartman LISP co-chair From jmh@joelhalpern.com Mon Sep 14 05:41: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 38ADF3A6828 for ; Mon, 14 Sep 2009 05:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.034 X-Spam-Level: X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, 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 1f+-z9xTTjym for ; Mon, 14 Sep 2009 05:41:19 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8BB5E3A67F2 for ; Mon, 14 Sep 2009 05:41:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 58A5E4300BC; Mon, 14 Sep 2009 05:42:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 214974300B4; Mon, 14 Sep 2009 05:42:03 -0700 (PDT) Message-ID: <4AAE3A19.8060200@joelhalpern.com> Date: Mon, 14 Sep 2009 08:42:01 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Magnus Westerlund References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> <4AAD6D9B.1020400@joelhalpern.com> <4AAE0395.7080009@ericsson.com> In-Reply-To: <4AAE0395.7080009@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Sam Hartman , "Philip F. Chimento" , lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 14 Sep 2009 12:41:21 -0000 I don't see it. There is not that big a difference between an outer packet corruption (if an IP-IP tunnel packet) that happens to change both the dest IP and the protocol ID, or an outer packet corruption (of a UDP encapsulated tunnel packet) that happens to change only the dest address, but arrives at a place where some other entity is processing that particular UDP port. I am not saying that we should not expect UDP encapsualted data packets to carry UDP checksums. That is a debate which I will leave to others, as it is an applicaiton behavior debate. But we have a large number of tunnel protocols. We have generally expected tunnel encapsulations, even if they happen to use UDP, to basically deliver the same semantics as the IP that they encapsualte. Tunnels are an IP extension. There are services that need higher reliability tunnels (Secure SSH tunnels). There are tunnels that provide much stronger checks (IPSec ESP with non-null authentication). But that is the choice of the tunnel mechanism, not a mandate from the IP service model. Yours, Joel Magnus Westerlund wrote: > Joel M. Halpern skrev: >> I do not follow your reasoning. >> Yes, IPv6 decided that it could dispense with the header checksum, >> because the carried thing has checksums. >> But the thing that needs to be protected (if something needs protection) >> is that actual data packet. >> I read the IPv6 decision as sensibly leaving the degree of pr4otection >> desired to the carried protocol. It dispenses with a delivery header >> checksum. That does not mean that everything else is required to >> protect every byte. >> >> The LISP header is serving a function very similar to an IP header. IPv6 >> in IPv6 is a well defined tunnel, and is not required to carry a header >> checksum. We have a LOT of tunnels. Many of them are permitted over >> IPv6 without a header checksum. >> > > Joel and LISP WG > (as an individual) > > My view is that there is a big difference between IP in IP tunnels and > IP/transport/IP tunnels. The reason is that when the outer header gets > corrupted and ends up on the wrong host there is a big difference who > handles that wrongly addressed packet. In a IP in IP tunnel, the next > header is IP, thus only if you have a tunnel decapsulator will you > really handle it and determine what to do with it. If it is not there > it gets dropped on the floor. Even if there is a decapsulator the packet > will be delivered according to the inner IP header. Which may or may not > make sense. It might even be correctly delivered, only having taken a > detour. A packet is only wrongly delivered to an application if the > following is true for IP in IP with corrupted headers: > 1. Destination host has an IP tunnel decapsulator > 2. Inner header is routable in the reached domain > 3. The destination address of the inner IP header is a private address > and there exist another host then the intended in the reached domain. > 4. That host has an application listening on the inner transport port. > > When you have IP/transport/IP then you hand of the packet to your > transport protocol stack for demultiplexing on port. So if the packet > arrives at the wrong host and there happens to be an application > listening on that port, it gets the packet. There is no defense against > detecting this corruption than what can be implemented on application > level. So the corresponding list for what ifs are need to be satisfied > for this option are: > 1. Destination host has an application listening on port given by the > tunnel transport protocol. > > It appears to me that the the weeding out factor for IP in IP tunnels > are significantly larger than it is for IP in transport in IP tunnels. > Thus I still think turning off the UDP checksum for IPv6 is a bad idea. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From magnus.westerlund@ericsson.com Mon Sep 14 01:27: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 74F5C3A6944 for ; Mon, 14 Sep 2009 01:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=-2.461, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_OFF=2.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 fcTSQ1vK4mcM for ; Mon, 14 Sep 2009 01:27:46 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 3828C3A67B8 for ; Mon, 14 Sep 2009 01:27:45 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-08-4aadfeac6f2d Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id CD.49.18827.CAEFDAA4; Mon, 14 Sep 2009 10:28:28 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 10:28:28 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 10:28:27 +0200 Message-ID: <4AADFEAB.8090804@ericsson.com> Date: Mon, 14 Sep 2009 10:28:27 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Marshall Eubanks References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> In-Reply-To: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Sep 2009 08:28:27.0445 (UTC) FILETIME=[5541EE50:01CA3515] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Mon, 14 Sep 2009 08:02:23 -0700 Cc: Sam Hartman , lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 14 Sep 2009 08:27:47 -0000 Marshall Eubanks skrev: > This comes from an email of Magnus Westerlund > ----- > [MBONED] WGLC for - UDP checksum? > Date: December 5, 2007 3:12:05 PM EST > I think it will be acceptable to update RFC 2460 to say that the UDP > checksum may be turned of[f] under the following restrictions: > > 1. The UDP payload must have the capability to verify its integrity by > itself, for example by being a complete IP packet in itself. > > 2. That IP packet fragmentation must not be used. > ------ > We interpreted "2" as coming from "1" - i.e., the total "outer" packet > could be fragmented, but the "inner" packet should not be a fragment of > the original "inner" packet, as then I could not verify its integrity > by itself. > > We also interpreted this as both a AD proscription, and as feedback from > IPv6 guru's, so we didn't question it much. However, the issue can > certainly be raised here. > As you note, the email is from 2007, not particular recent. Secondly, it says "I think". That is not the same as saying that I am right. And if you actually read the whole email from which the above citation was made it is clearer that I was not at all certain that what I was proposing was right. I don't classify myself as an IPv6 expert. Thus, don't take that email as an decreed limitation on the solution space from an AD. What I am today agreeing with from that email is the need for discussing this in general and get IETF consensus on the solution. I still think the 6man WG mailing list is the right place to discuss these issues. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Sep 14 01:49: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 C0EB33A69D8 for ; Mon, 14 Sep 2009 01:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.218 X-Spam-Level: X-Spam-Status: No, score=-5.218 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_28=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 cg3nx5HYvEQb for ; Mon, 14 Sep 2009 01:49:04 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 66F7E3A68AE for ; Mon, 14 Sep 2009 01:49:04 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000001984-eb-4aae03aac35e Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 47.1E.06532.AA30EAA4; Mon, 14 Sep 2009 10:49:47 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 10:49:25 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 10:49:24 +0200 Message-ID: <4AAE0395.7080009@ericsson.com> Date: Mon, 14 Sep 2009 10:49:25 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> <4AAD6D9B.1020400@joelhalpern.com> In-Reply-To: <4AAD6D9B.1020400@joelhalpern.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Sep 2009 08:49:24.0788 (UTC) FILETIME=[42B13F40:01CA3518] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Mon, 14 Sep 2009 08:02:23 -0700 Cc: Sam Hartman , "Philip F. Chimento" , lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 14 Sep 2009 08:49:05 -0000 Joel M. Halpern skrev: > I do not follow your reasoning. > Yes, IPv6 decided that it could dispense with the header checksum, > because the carried thing has checksums. > But the thing that needs to be protected (if something needs protection) > is that actual data packet. > I read the IPv6 decision as sensibly leaving the degree of pr4otection > desired to the carried protocol. It dispenses with a delivery header > checksum. That does not mean that everything else is required to > protect every byte. > > The LISP header is serving a function very similar to an IP header. IPv6 > in IPv6 is a well defined tunnel, and is not required to carry a header > checksum. We have a LOT of tunnels. Many of them are permitted over > IPv6 without a header checksum. > Joel and LISP WG (as an individual) My view is that there is a big difference between IP in IP tunnels and IP/transport/IP tunnels. The reason is that when the outer header gets corrupted and ends up on the wrong host there is a big difference who handles that wrongly addressed packet. In a IP in IP tunnel, the next header is IP, thus only if you have a tunnel decapsulator will you really handle it and determine what to do with it. If it is not there it gets dropped on the floor. Even if there is a decapsulator the packet will be delivered according to the inner IP header. Which may or may not make sense. It might even be correctly delivered, only having taken a detour. A packet is only wrongly delivered to an application if the following is true for IP in IP with corrupted headers: 1. Destination host has an IP tunnel decapsulator 2. Inner header is routable in the reached domain 3. The destination address of the inner IP header is a private address and there exist another host then the intended in the reached domain. 4. That host has an application listening on the inner transport port. When you have IP/transport/IP then you hand of the packet to your transport protocol stack for demultiplexing on port. So if the packet arrives at the wrong host and there happens to be an application listening on that port, it gets the packet. There is no defense against detecting this corruption than what can be implemented on application level. So the corresponding list for what ifs are need to be satisfied for this option are: 1. Destination host has an application listening on port given by the tunnel transport protocol. It appears to me that the the weeding out factor for IP in IP tunnels are significantly larger than it is for IP in transport in IP tunnels. Thus I still think turning off the UDP checksum for IPv6 is a bad idea. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Fred.L.Templin@boeing.com Mon Sep 14 08:38: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 2ACFD3A6A6B for ; Mon, 14 Sep 2009 08:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.957 X-Spam-Level: X-Spam-Status: No, score=-5.957 tagged_above=-999 required=5 tests=[AWL=0.642, 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 wRgDksIw8sFY for ; Mon, 14 Sep 2009 08:38:54 -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 61CF93A680B for ; Mon, 14 Sep 2009 08:38:54 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n8EFdViW021014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2009 10:39:32 -0500 (CDT) 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 n8EFdVrl028229; Mon, 14 Sep 2009 08:39:31 -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 n8EFdPXn027980; Mon, 14 Sep 2009 08:39:31 -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); Mon, 14 Sep 2009 08:39:28 -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: Mon, 14 Sep 2009 08:39:27 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10665C88B@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTUHandling Thread-Index: AcozR+oexzdLCtT4T2y3PaBcbaD1iACCRrsA References: From: "Templin, Fred L" To: "Margaret Wasserman" , "Sam Hartman" X-OriginalArrivalTime: 14 Sep 2009 15:39:28.0344 (UTC) FILETIME=[8B8DF580:01CA3551] Cc: lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTUHandling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 14 Sep 2009 15:38:55 -0000 > After reading Fred Templin's mail, I realize that there is another > possible solution to this problem -- to state in the fragmentation > section that you MUST NOT set the UDP/IPv6 chekcsum to zero for > packets that contain fragments. I just wanted to clarify that I am not arguing for this alternative - quite the opposite. I have kept quiet about MTU since Sam forbade me from discussing it further several weeks ago. Are we now open to discussions on MTU and, if so, is it permissible for me to participate? Thanks - Fred fred.l.templin@boeing.com From magnus.westerlund@ericsson.com Mon Sep 14 08:40: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 120103A6A6F for ; Mon, 14 Sep 2009 08:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[AWL=0.719, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 hHRGlSfsXMVS for ; Mon, 14 Sep 2009 08:40:48 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CB5BD3A6A6E for ; Mon, 14 Sep 2009 08:40:46 -0700 (PDT) X-AuditID: c1b4fb3e-b7b2cae000005a8f-98-4aae642a3010 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id A6.67.23183.A246EAA4; Mon, 14 Sep 2009 17:41:30 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 17:41:28 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 17:41:28 +0200 Message-ID: <4AAE6428.40704@ericsson.com> Date: Mon, 14 Sep 2009 17:41:28 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> <4AAD6D9B.1020400@joelhalpern.com> <4AAE0395.7080009@ericsson.com> <4AAE3A19.8060200@joelhalpern.com> In-Reply-To: <4AAE3A19.8060200@joelhalpern.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Sep 2009 15:41:28.0543 (UTC) FILETIME=[D332DEF0:01CA3551] X-Brightmail-Tracker: AAAAAA== Cc: Sam Hartman , "Philip F. Chimento" , lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 14 Sep 2009 15:40:50 -0000 Joel, Joel M. Halpern skrev: > I don't see it. There is not that big a difference between an outer > packet corruption (if an IP-IP tunnel packet) that happens to change > both the dest IP and the protocol ID, or an outer packet corruption (of > a UDP encapsulated tunnel packet) that happens to change only the dest > address, but arrives at a place where some other entity is processing > that particular UDP port. It comes down to probabilities. If you have an IPv6 outer header being corrupted in the next header field, then it still needs to pass checksum test of that transport protocol that it has become. In an IPv6 in IPv6 header, the position that corresponds to UDP and TCP checksum field is the inner packets Next Header and Hop Limit field. Thus the packet contains hop-by-hop options and should be discarded due to hop limit to achieve an all 0 checksum. Thus you need to have data that matches the present value. Thus it is quite likely to be discarded anyway. So by deliberate setting the UDP checksum to zero for an IPv6 packet you are actually significantly reducing any hosts capability to filter away corrupted packets. > > I am not saying that we should not expect UDP encapsualted data packets > to carry UDP checksums. That is a debate which I will leave to others, > as it is an applicaiton behavior debate. Yes, that is not the question here. The question is what impact of the proposed change of allowing 0 checksums for UDP when using IPv6. This change is attractive for the tunnel ingress, has little impact on the tunnel egress, but the cost is born by all hosts on the Internet by reduced capability of detecting and discarding corrupted packets. > > But we have a large number of tunnel protocols. We have generally > expected tunnel encapsulations, even if they happen to use UDP, to > basically deliver the same semantics as the IP that they encapsualte. > Tunnels are an IP extension. There are services that need higher > reliability tunnels (Secure SSH tunnels). There are tunnels that > provide much stronger checks (IPSec ESP with non-null authentication). > But that is the choice of the tunnel mechanism, not a mandate from the > IP service model. As I said above, the cost of this change does not primarily affect the tunnel end-points or the tunnel service. It is the other hosts on the network that has to pay the cost of this change. That is why I am against it. Regards Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jmh@joelhalpern.com Mon Sep 14 08:57: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 440B73A68B0 for ; Mon, 14 Sep 2009 08:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 tzdp3Dk3qvCh for ; Mon, 14 Sep 2009 08:57:25 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 513893A6A6E for ; Mon, 14 Sep 2009 08:57:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3C7044300C0; Mon, 14 Sep 2009 08:58:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id BE2464300B4; Mon, 14 Sep 2009 08:58:08 -0700 (PDT) Message-ID: <4AAE680F.6010203@joelhalpern.com> Date: Mon, 14 Sep 2009 11:58:07 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Magnus Westerlund References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> <4AAD6D9B.1020400@joelhalpern.com> <4AAE0395.7080009@ericsson.com> <4AAE3A19.8060200@joelhalpern.com> <4AAE6428.40704@ericsson.com> In-Reply-To: <4AAE6428.40704@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Sam Hartman , "Philip F. Chimento" , lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 14 Sep 2009 15:57:26 -0000 Looking at the same issue, I come to a very different conclusion. If we have a UDP checksum mandatory in the LISP boxes, we are mandating extra work in every LISP ITR and ETR on eveyr data packet handled by those boxes. Conversely, if we do not have the checksum, we will have a small number of packets directed to the wrong place, in which case it is almost certain that no one will be listening on those ports. A very small portion of the time, some UDP applications somewhere will get a complete garbage packet. In fact, since it is a UDP host stack that you are hypothesizing gets this packet, it probably will not be configured to accept zero checksums, so it will junk the packet. Only if we have a UDP app at the host the packet gets misdirected to, reading the particular port used by UDP data, and which is configured to accept packets with checksum 0, from an IPv6 source it has never heard from, will any real harm be done. This seems unlikely in the extremed. Paying even a small packet processing cost on every packet handled by LISP seems a very high price for protecting from this extreme corner case. Yours, Joel M. Halpern Magnus Westerlund wrote: > Joel, > > Joel M. Halpern skrev: >> I don't see it. There is not that big a difference between an outer >> packet corruption (if an IP-IP tunnel packet) that happens to change >> both the dest IP and the protocol ID, or an outer packet corruption (of >> a UDP encapsulated tunnel packet) that happens to change only the dest >> address, but arrives at a place where some other entity is processing >> that particular UDP port. > > It comes down to probabilities. If you have an IPv6 outer header being > corrupted in the next header field, then it still needs to pass checksum > test of that transport protocol that it has become. In an IPv6 in IPv6 > header, the position that corresponds to UDP and TCP checksum field is > the inner packets Next Header and Hop Limit field. Thus the packet > contains hop-by-hop options and should be discarded due to hop limit to > achieve an all 0 checksum. Thus you need to have data that matches the > present value. Thus it is quite likely to be discarded anyway. > > So by deliberate setting the UDP checksum to zero for an IPv6 packet you > are actually significantly reducing any hosts capability to filter away > corrupted packets. > >> I am not saying that we should not expect UDP encapsualted data packets >> to carry UDP checksums. That is a debate which I will leave to others, >> as it is an applicaiton behavior debate. > > Yes, that is not the question here. The question is what impact of the > proposed change of allowing 0 checksums for UDP when using IPv6. This > change is attractive for the tunnel ingress, has little impact on the > tunnel egress, but the cost is born by all hosts on the Internet by > reduced capability of detecting and discarding corrupted packets. > >> But we have a large number of tunnel protocols. We have generally >> expected tunnel encapsulations, even if they happen to use UDP, to >> basically deliver the same semantics as the IP that they encapsualte. >> Tunnels are an IP extension. There are services that need higher >> reliability tunnels (Secure SSH tunnels). There are tunnels that >> provide much stronger checks (IPSec ESP with non-null authentication). >> But that is the choice of the tunnel mechanism, not a mandate from the >> IP service model. > > As I said above, the cost of this change does not primarily affect the > tunnel end-points or the tunnel service. It is the other hosts on the > network that has to pay the cost of this change. That is why I am > against it. > > Regards > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From jnc@mercury.lcs.mit.edu Mon Sep 14 09:45: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 545BA3A686E for ; Mon, 14 Sep 2009 09:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 oIj05-YUqJ8t for ; Mon, 14 Sep 2009 09:45:06 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 946EA3A681D for ; Mon, 14 Sep 2009 09:45:06 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 21BAD6BE551; Mon, 14 Sep 2009 12:45:49 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090914164550.21BAD6BE551@mercury.lcs.mit.edu> Date: Mon, 14 Sep 2009 12:45:49 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 14 Sep 2009 16:45:07 -0000 > From: Magnus Westerlund > by deliberate setting the UDP checksum to zero for an IPv6 packet > you are actually significantly reducing any hosts capability to > filter away corrupted packets. I'm not understanding something here. How are we any worse off than if we were using an encapsulation (e.g. GRE) which did not have any checksum at all? (In fact, we'd probably be using GRE if it were not for other constraint) There are also potentially applications which _do not_ want the network to throw away corrupted packets for them - that's the whole reason UDPv4 _allows_ a zero checksum. that IPv6 LISP packet that just got corrupted might be carrying an IPv4 packet with a UDP zero-checkums packet inside. So why is the network taking it into its own hands to throw away corrupted packets? Noel From mrw@sandstorm.net Mon Sep 14 10:05: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 ED95C3A687E for ; Mon, 14 Sep 2009 10:05:42 -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 UJaWbQme-qx7 for ; Mon, 14 Sep 2009 10:05:37 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 66F713A682A for ; Mon, 14 Sep 2009 10:05:37 -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 n8EH5vHC087004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Sep 2009 13:06:03 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090914164550.21BAD6BE551@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, 14 Sep 2009 13:05:57 -0400 References: <20090914164550.21BAD6BE551@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 14 Sep 2009 17:05:43 -0000 On Sep 14, 2009, at 12:45 PM, Noel Chiappa wrote: >> From: Magnus Westerlund > >> by deliberate setting the UDP checksum to zero for an IPv6 packet >> you are actually significantly reducing any hosts capability to >> filter away corrupted packets. > > I'm not understanding something here. How are we any worse off than > if we were > using an encapsulation (e.g. GRE) which did not have any checksum at > all? (In > fact, we'd probably be using GRE if it were not for other constraint) There is no difference for LISP itself. The difference comes in when a LISP packet is sent to the wrong destination, which will happen more often in IPv6 than IPv4, because the IPv6 destination address will not be protected by any checksum. When an IP/IP or IP/GRE packet arrives at the wrong destination, the IP layer of the stack processes the packet and (typically) decides that there is nothing useful to do with the packet and throws it away. When an IP/UDP packet arrives at the wrong destination, the packet is passed up the stack to UDP. UDP does not have any way to tell that the packet was misdelivered (if we have checksums turned off), so it will look at the destination port to determine where to deliver the packet. In most cases, UDP will decide to throw the packet away, but it some cases, it might deliver the packet to an unsuspecting application. There are some things about LISP that make it much _less_ likely that the packet will be delivered to an unsuspecting application, the most important of which is that _all_ of the tunneled LISP packets are sent to a LISP destination port. We don't have return traffic that goes to a random port and may be mistaken for other return traffic. So, to get the problem that Magnus described, and have it effect anything but LISP, you'd have to have a different application running on the IANA- assigned LISP port. That isn't very likely, and if those applications accidentally receive LISP traffic, perhaps they have gotten what they deserve. > There are also potentially applications which _do not_ want the > network to > throw away corrupted packets for them - that's the whole reason UDPv4 > _allows_ a zero checksum. that IPv6 LISP packet that just got > corrupted > might be carrying an IPv4 packet with a UDP zero-checkums packet > inside. > So why is the network taking it into its own hands to throw away > corrupted > packets? In IPv6, corruption-tolerant applications are expected to use UDP- Lite. That is how one turns off the data checksum for UDP in IPv6. Margaret From jnc@mercury.lcs.mit.edu Mon Sep 14 12: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 933223A6AD0 for ; Mon, 14 Sep 2009 12:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 2E1LW7uaUuhR for ; Mon, 14 Sep 2009 12:00:35 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 913083A6A55 for ; Mon, 14 Sep 2009 12:00:28 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id E71CE6BE571; Mon, 14 Sep 2009 15:01:12 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090914190112.E71CE6BE571@mercury.lcs.mit.edu> Date: Mon, 14 Sep 2009 15:01:12 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu 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, 14 Sep 2009 19:00:36 -0000 > From: Margaret Wasserman > If we want to write an interoperable specification that includes > multiple options that are not interoperable, we have two choices: > (1) State that it is mandatory to support one of the choices on both > ends, and signal/negotiate the use of any of the other options. > (2) Require all implementations of one end of the connection .. to > support all of the options. Yup; good summary. Do note that this is the list _if we want any pair of boxes to be able to communicate_; we might not have that luxury, though. > There are many currently deployed systems that are _not capable_ of > accepting a packet with an IPv6/UDP checksum of zero ... LISP simply > _will not work_ over IPv6 on those systems. The list includes all > deployed copies of every major operating system, all currently deployed > IPv6-capable CPE equipment, and the checksum offload hardware in all > recently-shipped Macs and many (perhaps most) recently-shipped PCs. I guess to start with, the thing I need to understand is why this is a problem. In general these are not the boxes LISP is targeted toward. Do you forsee much need for some of these things to be running LISP? Do you have some particular deployment targets in mind which I don't understand? I ask this in part because, when thinking about all the host implementations, it's worth remembering that Multi6 was basically rejected by the users because it required management of addresses on individual hosts, so for that reason in general I wouldn't expect individual hosts to be wanting to run LISP anyway. So that's why I'm trying to understand the circumstances in which you forsee a need to run LISP on such boxes. With that in hand, I can think about the rest... Sigh, this is such a difficult situation. :-( Noel From hartmans@mit.edu Tue Sep 15 06:12: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 8EF9F3A684F for ; Tue, 15 Sep 2009 06:12:06 -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 CtCAEgCkRMSk for ; Tue, 15 Sep 2009 06:12: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 CA3B93A67F2 for ; Tue, 15 Sep 2009 06:12:05 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9080F454B; Tue, 15 Sep 2009 09:12:50 -0400 (EDT) To: John Zwiebel References: <8472C95A-6A64-4405-921F-2DD8AB6D0211@sandstorm.net> <9B93E45D-92DE-4D5C-92F8-773C6DDB29D4@cisco.com> From: Sam Hartman Date: Tue, 15 Sep 2009 09:12:50 -0400 In-Reply-To: <9B93E45D-92DE-4D5C-92F8-773C6DDB29D4@cisco.com> (John Zwiebel's message of "Sun\, 13 Sep 2009 16\:18\:25 -1000") 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: [lisp] #19: not including the 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, 15 Sep 2009 13:12:06 -0000 >>>>> "John" == John Zwiebel writes: John> On Sep 13, 2009, at 2:50 AM, Margaret Wasserman wrote: John> How many does it take to make a consensus? John> I'm for including the M-bit. John> _______________________________________________ lisp mailing John> list lisp@ietf.org John> https://www.ietf.org/mailman/listinfo/lisp This is not so much about lack of consensus (although I don't believe we have that) as a process problem. There are fairness issues if we start assigning bits to proposals that the WG has not accepted and cannot accept unless we first decide on guidelines we will apply for those assignments and then make the assignments. See my write-up of #19. The AD proposed the same way forward as I did in that issue in private mail to the editors and chairs. From jari.arkko@piuha.net Tue Sep 15 06:50: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 78EE03A6879 for ; Tue, 15 Sep 2009 06:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 XlHlcMGKWT09 for ; Tue, 15 Sep 2009 06:50:02 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9A0B13A6882 for ; Tue, 15 Sep 2009 06:50:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 142C6D4937 for ; Tue, 15 Sep 2009 16:50:49 +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 1cGgKk5L2Wbm for ; Tue, 15 Sep 2009 16:50:47 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B7101D492B for ; Tue, 15 Sep 2009 16:50:47 +0300 (EEST) Message-ID: <4AAF9BB6.1060905@piuha.net> Date: Tue, 15 Sep 2009 16:50:46 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: lisp@ietf.org References: <8472C95A-6A64-4405-921F-2DD8AB6D0211@sandstorm.net> <9B93E45D-92DE-4D5C-92F8-773C6DDB29D4@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] #19: not including the 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, 15 Sep 2009 13:50:03 -0000 We've talked about mobility now several times. I may be starting to sound like a broken record. But mobility is, for now, outside the scope of the working group. Lets not insert it half-way into the base specifications -- not even for that one bit. Many RFCs define RESERVED fields from where subsequent RFCs can allocate bits. That's technically the right thing to do in my opinion, because you do not know the full list of Lisp extensions and their bit needs anyway. (In addition, you can avoid lengthy threads and complex issues about what the bit actually means.) Jari From jari.arkko@piuha.net Tue Sep 15 06:57: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 18A143A6811 for ; Tue, 15 Sep 2009 06:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 Q4e7erNO8q8A for ; Tue, 15 Sep 2009 06:57:33 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 061CA3A63EB for ; Tue, 15 Sep 2009 06:57:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C317BD4938; Tue, 15 Sep 2009 16:58:19 +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 isJlR7VeJQw7; Tue, 15 Sep 2009 16:58:19 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 38455D492B; Tue, 15 Sep 2009 16:58:19 +0300 (EEST) Message-ID: <4AAF9D7A.602@piuha.net> Date: Tue, 15 Sep 2009 16:58:18 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Noel Chiappa References: <20090914190112.E71CE6BE571@mercury.lcs.mit.edu> In-Reply-To: <20090914190112.E71CE6BE571@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 15 Sep 2009 13:57:34 -0000 Noel, > > If we want to write an interoperable specification that includes > > multiple options that are not interoperable, we have two choices: > > (1) State that it is mandatory to support one of the choices on both > > ends, and signal/negotiate the use of any of the other options. > > (2) Require all implementations of one end of the connection .. to > > support all of the options. > > Yup; good summary. > Yes. > Do note that this is the list _if we want any pair of boxes to be able to > communicate_; we might not have that luxury, though. > > > > There are many currently deployed systems that are _not capable_ of > > accepting a packet with an IPv6/UDP checksum of zero ... LISP simply > > _will not work_ over IPv6 on those systems. The list includes all > > deployed copies of every major operating system, all currently deployed > > IPv6-capable CPE equipment, and the checksum offload hardware in all > > recently-shipped Macs and many (perhaps most) recently-shipped PCs. > > I guess to start with, the thing I need to understand is why this is a > problem. In general these are not the boxes LISP is targeted toward. Do > you forsee much need for some of these things to be running LISP? Do you > have some particular deployment targets in mind which I don't understand? > > I ask this in part because, when thinking about all the host > implementations, it's worth remembering that Multi6 was basically rejected > by the users because it required management of addresses on individual > hosts, so for that reason in general I wouldn't expect individual hosts to > be wanting to run LISP anyway. > > So that's why I'm trying to understand the circumstances in which you > forsee a need to run LISP on such boxes. With that in hand, I can think > about the rest... > There are many people who need to build networking equipment on top of general purpose operating systems. I suspect most of us on this list have done it. I've seen many bsd/linux based systems morph into major product lines over the years. I don't think we want to discourage this. Of course, it is always possible to hack the kernel and replace your own code, at least if we are talking about open source. The question is how hard that is, what you do with commercial OSes, and whether all this will in practice prevent some deployments. Jari From mrw@sandstorm.net Tue Sep 15 07:29: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 72FF53A6811 for ; Tue, 15 Sep 2009 07:29:57 -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 0XwfvgdD1GSk for ; Tue, 15 Sep 2009 07:29:56 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 652EE3A677C for ; Tue, 15 Sep 2009 07:29:56 -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 n8FEUTXY042835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Sep 2009 10:30:29 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <23EAB0F0-DD8B-4B18-8403-350459F80B6D@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090914190112.E71CE6BE571@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, 15 Sep 2009 10:30:29 -0400 References: <20090914190112.E71CE6BE571@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) 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: Tue, 15 Sep 2009 14:29:57 -0000 Hi Noel, On Sep 14, 2009, at 3:01 PM, Noel Chiappa wrote: > > I guess to start with, the thing I need to understand is why this is a > problem. In general these are not the boxes LISP is targeted toward. > Do > you forsee much need for some of these things to be running LISP? Do > you > have some particular deployment targets in mind which I don't > understand? > > I ask this in part because, when thinking about all the host > implementations, it's worth remembering that Multi6 was basically > rejected > by the users because it required management of addresses on individual > hosts, so for that reason in general I wouldn't expect individual > hosts to > be wanting to run LISP anyway. > > So that's why I'm trying to understand the circumstances in which you > forsee a need to run LISP on such boxes. With that in hand, I can > think > about the rest... I do not claim to know everywhere that LISP will be deployed... But, I do think (or at least hope) that it will be deployed on CPE equipment, so that end-users can enjoy the benefits of LISP, such as stable addresses. There is a significant amount of CPE equipment based on Linux, FreeBSD or various proprietary embedded operating systems. The stacks in those operating systems do not support sending or receiving zero UDP checksums in IPv6. There seems to be some belief that, since Linux and FreeBSD are open source, the folks who make CPE equipment can just hack their kernels to support zero UDP checksums in IPv6. However, that doesn't reflect reality in a number of ways... The hack to the kernel to support zero IPv6/UDP checksums for some connections and not others is fairly complex, and most of the CPE vendors I've known don't want to hack their kernel at all. In general they get a stable, supported Linux distribution from an embedded Linux distributor and use that. They value the open source for debugging purposes, but they don't want to branch their own kernel off from their supported package. Customers who use proprietary OSes would have to wait for their vendor to support zero UDP/IPv6 checksums, which isn't going to happen immediately. They would then need to upgrade the OS in their product to get the new checksum handling code. OS upgrades are typically considered to be a major project and are not taken lightly for stable, shipping products. Also, there is a significant amount of CPE equipment that does checksum offload in hardware, and not all systems offer a way to turn this off. Chips to do IPv6 checksum offload (for UDP/TCP) have been widely available for a while now and are widely deployed. They are all based on the current IPv6/UDP checksum standard (RFC 2460), which doesn't allow zero UDP/IPv6 checksums. So, we're talking about a situation where CPE equipment vendors would have to modify/upgrade their operating system, turn off IPv6 hardware acceleration for their current equipment (causing a significant performance drop) and (probably) upgrade their hardware for ongoing shipments, just to support LISP. I don't think we want to put these sorts of hurdle in the way of LISP being implemented and deployment on CPE equipment. So, I think we want to design LISP so that it will work with TCP/IP stacks and network interface hardware that is widely deployed today. In the future, I also hope that LISP will be capable of running on the end systems themselves. We'll need that capability to support mechanisms like the mobility draft or other mechanisms that push LISP all the way out to the edges. I realize that these applications are outside the scope of the current IETF WG, though. > Sigh, this is such a difficult situation. :-( Yes, it is... I understand that the requirements in this area for CPE equipment based on commodity hardware/software is directly at odds with the requirements for (at least some) high end routers. So, we seem to be at an impasse... When you find yourself at an impasse, sometimes it is best to go back, question your assumptions and explore the roads not taken... I understand that we want to use UDP to support LAG/ECMP. Is there any other way that we could support that? For example, Francis Dupont proposed that we could create unique per-flow three-tuples (two IP addresses and a protocol) by assigning a set of IP addresses (same prefix, different IIDs) to a LISP ITR, so that the ITR could send from different IP addresses to differentiate between different flows. Or, possibly, we could move to direct LISP-in-IP encapsulation (for IPv6 only) and try to move the world in the direction of using the IPv6 Flow Label as part of the LAG/ECMP hash in IPv6? I'd personally prefer the latter, because I agree with Joel that debugging tunnels that use multiple addresses on one end would be challenging. However, I may be underestimating how long it would be before LAG/ECMP hardware could be deployed that considers the IPv6 flow label... I'd strongly prefer either of these choices to where we find ourselves now, though. Margaret From magnus.westerlund@ericsson.com Tue Sep 15 07:46: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 2BA6328C10C for ; Tue, 15 Sep 2009 07:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.522 X-Spam-Level: X-Spam-Status: No, score=-5.522 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 rjK8-mVYMulY for ; Tue, 15 Sep 2009 07:45:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id AF7793A6B17 for ; Tue, 15 Sep 2009 07:45:55 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000001984-7a-4aafa8d11d6f Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 15.65.06532.1D8AFAA4; Tue, 15 Sep 2009 16:46:41 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 16:45:15 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 16:45:15 +0200 Message-ID: <4AAFA87B.2020708@ericsson.com> Date: Tue, 15 Sep 2009 16:45:15 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> <4AAD6D9B.1020400@joelhalpern.com> <4AAE0395.7080009@ericsson.com> <4AAE3A19.8060200@joelhalpern.com> <4AAE6428.40704@ericsson.com> <4AAE680F.6010203@joelhalpern.com> In-Reply-To: <4AAE680F.6010203@joelhalpern.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Sep 2009 14:45:15.0353 (UTC) FILETIME=[2308AC90:01CA3613] X-Brightmail-Tracker: AAAAAA== Cc: Sam Hartman , "Philip F. Chimento" , lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 14:46:03 -0000 Joel M. Halpern skrev: > Looking at the same issue, I come to a very different conclusion. > > If we have a UDP checksum mandatory in the LISP boxes, we are mandating > extra work in every LISP ITR and ETR on eveyr data packet handled by > those boxes. > > Conversely, if we do not have the checksum, we will have a small number > of packets directed to the wrong place, in which case it is almost > certain that no one will be listening on those ports. A very small > portion of the time, some UDP applications somewhere will get a complete > garbage packet. In fact, since it is a UDP host stack that you are > hypothesizing gets this packet, it probably will not be configured to > accept zero checksums, so it will junk the packet. Only if we have a > UDP app at the host the packet gets misdirected to, reading the > particular port used by UDP data, and which is configured to accept > packets with checksum 0, from an IPv6 source it has never heard from, > will any real harm be done. This seems unlikely in the extremed. Paying > even a small packet processing cost on every packet handled by LISP > seems a very high price for protecting from this extreme corner case. Well turning off the checksum makes it 32000 times more likely to occur than it currently does. I am at least lacking current data on how often corruption occurs. The data that I know of indicates that it was fairly common 10 years ago, when the investigate sites sent or received packets with corruptions in them in varying degrees between 1:1100 to 1:32000. This is from Stone and Partridge paper: http://doi.acm.org/10.1145/347059.347561 And of these 8% was single bit-errors, than can be caused anywhere on the path, such as links, buffer memories, etc. I know this is old data and I do hope the real error rates are significantly lower today. If anyone knows of publication of more current data then please reference that. But, considering that data rates has gone up, that we have more hosts on the Internet, and that LISP is intended for tunneling across the backbone and move large amounts of data I think we should be careful consider what it means to increase the probability of receiving spurious data with a factor of 32000. At the same time I do understand the gain of not having to do the checksum. No, I am not making a decision based on a 10 year old paper. But, I do speak for caution considering the potential effects here. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jnc@mercury.lcs.mit.edu Tue Sep 15 08:09: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 8BF0F3A68AD for ; Tue, 15 Sep 2009 08:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 SVpxxsiemnfI for ; Tue, 15 Sep 2009 08:09:11 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id DC8B73A6A3B for ; Tue, 15 Sep 2009 08:09:11 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DA9BA6BE5C3; Tue, 15 Sep 2009 11:09:57 -0400 (EDT) To: lisp@ietf.org, magnus.westerlund@ericsson.com, Philip.Chimento@jhuapl.edu Message-Id: <20090915150957.DA9BA6BE5C3@mercury.lcs.mit.edu> Date: Tue, 15 Sep 2009 11:09:57 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 15:09:12 -0000 > From: Magnus Westerlund > At the same time I do understand the gain of not having to do the > checksum. Doing UDP checksums on all packets is just a total non-starter. On some boxes, it's incredibly expensive: http://www.ietf.org/mail-archive/web/lisp/current/msg00773.html and on others it's impossible: http://www.ietf.org/mail-archive/web/lisp/current/msg00770.html It may be that there's just no choice for IPv6 that works for all parties (ISPs, routers, hosts). Noel From mrw@sandstorm.net Tue Sep 15 08: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 A4A303A6A24 for ; Tue, 15 Sep 2009 08:22:47 -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 kJ2ZFsUDDkdA for ; Tue, 15 Sep 2009 08:22:47 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id CB3063A67D9 for ; Tue, 15 Sep 2009 08:22:46 -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 n8FFNTnk045331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Sep 2009 11:23:29 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090915150957.DA9BA6BE5C3@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, 15 Sep 2009 11:23:29 -0400 References: <20090915150957.DA9BA6BE5C3@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org, Philip.Chimento@jhuapl.edu Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 15:22:47 -0000 On Sep 15, 2009, at 11:09 AM, Noel Chiappa wrote: > > It may be that there's just no choice for IPv6 that works for all > parties > (ISPs, routers, hosts). I actually think of the parties as ISPs, higher-end routers and lower- end routers. Many lower-end routers (such as CPE equipment, home gateways, small business gateways) are implemented using commodity or semi-customer hardware and general-purpose operating systems. I don't picture hosts implementing LISP in the short-to-mid term, although there may be advantages to keeping that option open for the future. My understanding of the ISP requirements is that LISP has to work with LAG/ECMP equipment, not (specifically) that we have to use UDP. Is that correct? If so, we could explore other options for IPv6 to meet the LAG/ECMP requirements, such as using different IPv6 IIDs for different flows. I'd also like to get a better understanding of the state of the current IPv6 LAG/ECMP deployment, including how/if those systems could be upgraded to use the IPv6 flow label as part of the flow- identification. Margaret From mrw@sandstorm.net Tue Sep 15 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 380F93A6A42 for ; Tue, 15 Sep 2009 08:24:40 -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 1XRd1qk+2dAV for ; Tue, 15 Sep 2009 08:24:39 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 6B62B3A6836 for ; Tue, 15 Sep 2009 08:24:39 -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 n8FFPOiq045386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Sep 2009 11:25:24 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <074D213F-C477-4341-895F-C66BF60765F0@sandstorm.net> 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, 15 Sep 2009 11:25:24 -0400 References: <20090915150957.DA9BA6BE5C3@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: Philip.Chimento@jhuapl.edu, Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 15:24:40 -0000 On Sep 15, 2009, at 11:23 AM, Margaret Wasserman wrote: > > I actually think of the parties as ISPs, higher-end routers and > lower-end routers. Many lower-end routers (such as CPE equipment, > home gateways, small business gateways) are implemented using > commodity or semi-customer hardware and general-purpose operating > systems. s/semi-customer/semi-custom Margaret From mrw@sandstorm.net Tue Sep 15 08:45: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 2A86C3A67F8 for ; Tue, 15 Sep 2009 08:45:08 -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 jRTSg5uGRQEu for ; Tue, 15 Sep 2009 08:45:07 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 45A413A67A3 for ; Tue, 15 Sep 2009 08:45:07 -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 n8FFjiHR046597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Sep 2009 11:45:44 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090915150957.DA9BA6BE5C3@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, 15 Sep 2009 11:45:44 -0400 References: <20090915150957.DA9BA6BE5C3@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org, Philip.Chimento@jhuapl.edu Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 15:45:08 -0000 On Sep 15, 2009, at 11:09 AM, Noel Chiappa wrote: > > It may be that there's just no choice for IPv6 that works for all > parties > (ISPs, routers, hosts). Just to make my personal interests clear in this discussion, there is something I think you should all know... Sam Hartman and I are currently working on a LISP implementation (with his company, Painless Security) that is designed to be portable to several general-purpose and embedded operating systems. Our implementation is targeted at exactly the sort of lower-end router (home gateway, CPE equipment or small business gateway) that I have been discussing. It currently uses the IP stack and other facilities provided by the operating systems on which it runs. So, in addition to my interest in producing a good LISP protocol that will benefit the Internet, I have some personal interest in the outcome of this discussion. I can also say, rather authoritatively, that there is at least one LISP implementation that is targeted at these environments. Margaret From jmh@joelhalpern.com Tue Sep 15 08:55: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 191E93A6BA1 for ; Tue, 15 Sep 2009 08:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_00=-2.599, MANGLED_HRDCOR=2.3, 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 9h7wdPn4g0nv for ; Tue, 15 Sep 2009 08:55:13 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 58EC53A6BD0 for ; Tue, 15 Sep 2009 08:55:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CED4443022B; Tue, 15 Sep 2009 08:56:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 40AEF430202; Tue, 15 Sep 2009 08:56:00 -0700 (PDT) Message-ID: <4AAFB90E.90803@joelhalpern.com> Date: Tue, 15 Sep 2009 11:55:58 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Margaret Wasserman References: <20090915150957.DA9BA6BE5C3@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 15:55:14 -0000 This is a very reasonable question in this context. Unfortunately, the answers are not clear cut. I have been able to find several vendors of relevant devices that could upgrade. I have also found at least one vendor where an upgrade to handle ECMP/LAG on the basis of IPv6 flow spec would be hard (or even not possible in nay meaningful time frame). Several vendors have not answered me. But counting vendors probably does not tell us much. If we count boxes, a LOT of boxes would be very hard to upgrade. Yours, Joel Margaret Wasserman wrote: ... > I'd also like to get a better understanding of the state of the current > IPv6 LAG/ECMP deployment, including how/if those systems could be > upgraded to use the IPv6 flow label as part of the flow-identification. > > Margaret From mrw@sandstorm.net Tue Sep 15 09:08: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 1CD463A67E6 for ; Tue, 15 Sep 2009 09:08:23 -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 EhFHiWaKqvxa for ; Tue, 15 Sep 2009 09:08:22 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 28AE83A6A0B for ; Tue, 15 Sep 2009 09:08:22 -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 n8FG95wk047884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Sep 2009 12:09:05 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <5A05FC70-4152-44A6-84EE-6214638ED80B@sandstorm.net> From: Margaret Wasserman To: Magnus Westerlund In-Reply-To: <4AAFA87B.2020708@ericsson.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, 15 Sep 2009 12:09:04 -0400 References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> <4AAD6D9B.1020400@joelhalpern.com> <4AAE0395.7080009@ericsson.com> <4AAE3A19.8060200@joelhalpern.com> <4AAE6428.40704@ericsson.com> <4AAE680F.6010203@joelhalpern.com> <4AAFA87B.2020708@ericsson.com> X-Mailer: Apple Mail (2.935.3) Cc: Sam Hartman , "Philip F. Chimento" , lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 16:08:23 -0000 Hi Magnus, On Sep 15, 2009, at 10:45 AM, Magnus Westerlund wrote: > Well turning off the checksum makes it 32000 times more likely to > occur > than it currently does. I am at least lacking current data on how > often > corruption occurs. The data that I know of indicates that it was > fairly > common 10 years ago, when the investigate sites sent or received > packets > with corruptions in them in varying degrees between 1:1100 to 1:32000. > This is from Stone and Partridge paper: > > http://doi.acm.org/10.1145/347059.347561 Although less scientific than the Stone Partridge paper, some folks have circulated error logs on the LISP list that indicate that the current rate of corruption is still about the same. The largest sample we saw had corruption of about 1:7000 packets. I've checked a few systems that I have access to, and they are in the same range. So, it's unlikely that the numbers have changed all that much in the last 10 years. Margaret From dino@cisco.com Tue Sep 15 09:24: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 C88353A689C for ; Tue, 15 Sep 2009 09:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 QsYjGAwk8N5U for ; Tue, 15 Sep 2009 09:24:02 -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 E87903A682C for ; Tue, 15 Sep 2009 09:24:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADNdr0qrR7MV/2dsb2JhbADIJohMAY9/BYQXimk X-IronPort-AV: E=Sophos;i="4.44,391,1249257600"; d="scan'208";a="204870089" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 15 Sep 2009 16:24:49 +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 n8FGOnbB005759; Tue, 15 Sep 2009 09:24:49 -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 n8FGOnTH022083; Tue, 15 Sep 2009 16:24: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, 15 Sep 2009 09:24:49 -0700 Received: from [192.168.1.2] ([10.21.148.92]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 09:24:48 -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 v936) Date: Tue, 15 Sep 2009 09:24:48 -0700 References: <8472C95A-6A64-4405-921F-2DD8AB6D0211@sandstorm.net> <9B93E45D-92DE-4D5C-92F8-773C6DDB29D4@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Sep 2009 16:24:48.0536 (UTC) FILETIME=[0B541180:01CA3621] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1228; t=1253031889; x=1253895889; 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#19=3A=20not=20including=20the =20M=20bit |Sender:=20; bh=pavIvtJaJcQdQjriQGzYBdixq3CiAQk648WFFTwIhlQ=; b=mKL+vTGvQ0+2Cn6rzU+qxfbWgc29H15UG0Q34cJoIWFkrs2gCmMLV+MCeh gP7MeOwBk88eBW4+b1wSp16ze+W4tO4UX3S2hi/rzxAZ4Uosi4yXs+fV1Ikh rshl8+vF+3wJlppcgUmwF3INHLgOxiqG8D62V8iB89lp4A9knOd5I=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] #19: not including the 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, 15 Sep 2009 16:24:02 -0000 Sam, I have talked to all the draft-meyer-lisp-mn-00.txt authors. We agreed to pull the M-bit allocation and description from the main spec. Dino On Sep 15, 2009, at 6:12 AM, Sam Hartman wrote: >>>>>> "John" == John Zwiebel writes: > > John> On Sep 13, 2009, at 2:50 AM, Margaret Wasserman wrote: > > > > > John> How many does it take to make a consensus? > > John> I'm for including the M-bit. > John> _______________________________________________ lisp mailing > John> list lisp@ietf.org > John> https://www.ietf.org/mailman/listinfo/lisp > > > This is not so much about lack of consensus (although I don't believe > we have that) as a process problem. > > There are fairness issues if we start assigning bits to proposals that > the WG has not accepted and cannot accept unless we first decide on > guidelines we will apply for those assignments and then make the > assignments. See my write-up of #19. > > The AD proposed the same way forward as I did in that issue in private > mail to the editors and chairs. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Tue Sep 15 09:35: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 7290A3A6A3A for ; Tue, 15 Sep 2009 09:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 iIdG5rmRA2pq for ; Tue, 15 Sep 2009 09:35:18 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 983A53A6B4E for ; Tue, 15 Sep 2009 09:35:18 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 067C56BE5C4; Tue, 15 Sep 2009 12:36:04 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090915163605.067C56BE5C4@mercury.lcs.mit.edu> Date: Tue, 15 Sep 2009 12:36:04 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu, Philip.Chimento@jhuapl.edu Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 16:35:19 -0000 > From: Margaret Wasserman >> It may be that there's just no choice for IPv6 that works for all >> parties (ISPs, routers, hosts). > I actually think of the parties as ISPs, higher-end routers and > lower-end routers. Well, "lower-end routers" and "hosts" to me are, in these circumstances, almost the same thing; they run, as you say, commodity or mostly-commodity hardware, and the software base is usually 'bought-in' software. It's precisely because most of the kit is provided from elsewhere, in both cases, that they have an issue. > My understanding of the ISP requirements is that LISP has to work > with LAG/ECMP equipment, not (specifically) that we have to use UDP. > Is that correct? Yes, as best I understand it. The high-level requirement from the large users who are interested in deploying it (not just ISPs, because large congent providers often have the same issues, I gather) is that the load can be spread, _while keeping individual traffic streams in order_. (I.e. no spreading the packets from a single TCP connection, etc, over multiple paths; making sure this constraint doesn't get violated as a result of steps taken during LISP encapsulation is the reason for some of the encapsulation field-setting algorithms. And apologies if you already] understood that - I occasionally forget it myself.) Since deployed stuff - which includes core routers in the main fabric of the Internet, which LISP is intended to leave untouched - only provide this capability for UDP and TCP (shudder), the choices are pretty limited. Noel From tme@americafree.tv Tue Sep 15 09:45: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 8E99B3A6AA7 for ; Tue, 15 Sep 2009 09:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 1CCYOBO561yM for ; Tue, 15 Sep 2009 09:45:58 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 33C853A6A64 for ; Tue, 15 Sep 2009 09:45:58 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id DFE3F4BB5521; Tue, 15 Sep 2009 12:46:41 -0400 (EDT) Message-Id: <92780460-9C91-4017-948F-BC32E0026F3A@americafree.tv> From: Marshall Eubanks To: Margaret Wasserman In-Reply-To: <5A05FC70-4152-44A6-84EE-6214638ED80B@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, 15 Sep 2009 12:46:36 -0400 References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> <4AAD6D9B.1020400@joelhalpern.com> <4AAE0395.7080009@ericsson.com> <4AAE3A19.8060200@joelhalpern.com> <4AAE6428.40704@ericsson.com> <4AAE680F.6010203@joelhalpern.com> <4AAFA87B.2020708@ericsson.com> <5A05FC70-4152-44A6-84EE-6214638ED80B@sandstorm.net> X-Mailer: Apple Mail (2.936) Cc: Sam Hartman , "Philip F. Chimento" , lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 16:45:59 -0000 On Sep 15, 2009, at 12:09 PM, Margaret Wasserman wrote: > > Hi Magnus, > > On Sep 15, 2009, at 10:45 AM, Magnus Westerlund wrote: >> Well turning off the checksum makes it 32000 times more likely to >> occur >> than it currently does. I am at least lacking current data on how >> often >> corruption occurs. The data that I know of indicates that it was >> fairly >> common 10 years ago, when the investigate sites sent or received >> packets >> with corruptions in them in varying degrees between 1:1100 to >> 1:32000. >> This is from Stone and Partridge paper: >> >> http://doi.acm.org/10.1145/347059.347561 > > Although less scientific than the Stone Partridge paper, some folks > have circulated error logs on the LISP list that indicate that the > current rate of corruption is still about the same. The largest > sample we saw had corruption of about 1:7000 packets. I've checked > a few systems that I have access to, and they are in the same > range. So, it's unlikely that the numbers have changed all that > much in the last 10 years. That mail thread was titled : Flow label redux [Re: IPv6 UDP checksum issue] I don't remember this exact number, the ones I saw were all smaller. Note that 1/7000 = 1.4 x 10^-4 Can you send me the email with that result ? Looking at some http servers here at AmericaFree.TV (we get plenty of IPv4 UDP inbound) the rates seem to be a bit lower for UDP on Gig-E fiber : udp: 2562490909 datagrams received 1 with incomplete header 8 with bad data length field 706 with bad checksum 400791 dropped due to no socket 0 broadcast/multicast datagrams dropped due to no socket 314287 dropped due to full socket buffers 0 not for hashed pcb 2561775116 delivered 2923557119 datagrams output 706 / 2,562,490,909 = 3 x 10^-7 udp: 1705417676 datagrams received 0 with incomplete header 0 with bad data length field 10 with bad checksum 915464 dropped due to no socket 0 broadcast/multicast datagrams dropped due to no socket 19332 dropped due to full socket buffers 0 not for hashed pcb 1704482870 delivered 2728246320 datagrams output 10 / 1,705,417,676 = 6 x 10^-9 udp: 2736395896 datagrams received 0 with incomplete header 0 with bad data length field 2 with bad checksum 233675 dropped due to no socket 162 broadcast/multicast datagrams dropped due to no socket 28232 dropped due to full socket buffers 0 not for hashed pcb 2736133825 delivered 3163915652 datagrams output 2 / 2,736,395,896 = 7 x 10^-10 udp: 37512759 datagrams received 0 with incomplete header 0 with bad data length field 6 with bad checksum 33335 dropped due to no socket 0 broadcast/multicast datagrams dropped due to no socket 2315 dropped due to full socket buffers 0 not for hashed pcb 37477103 delivered 41487516 datagrams output 6 / 37,512,759 = 1.6 x 10^-7 I think that checksum loss rates on fiber will be low - the lower ones here are not that far from what you would expect from fiber bit error rates < 10^-12. Clearly, the checksum rates on fiber will be higher. As it happens, I use some laptops as wireless routers. Here is data from one : UDP : 3732883 datagrams received 4 with bad checksum 4 / 3,732,883 = 10^-6 So, this is higher, but still not as high as 10^-4. I am working on a writeup of the implications of these numbers. Regards Marshall > > Margaret > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jnc@mercury.lcs.mit.edu Tue Sep 15 09:51: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 541BA3A6B6A for ; Tue, 15 Sep 2009 09:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 RTh-5GliVNBE for ; Tue, 15 Sep 2009 09:51:50 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 9FB783A6AAC for ; Tue, 15 Sep 2009 09:51:50 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2E2236BE5C4; Tue, 15 Sep 2009 12:52:27 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090915165227.2E2236BE5C4@mercury.lcs.mit.edu> Date: Tue, 15 Sep 2009 12:52:27 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu, Philip.Chimento@jhuapl.edu Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 16:51:51 -0000 > From: Marshall Eubanks > Clearly, the checksum rates on fiber will be higher. This is header checksum failures we're talking about here, right, not link-level checksums (at the network layer)? Whichever one it is, do you happen to have any numbers on the other? Noel From jmh@joelhalpern.com Tue Sep 15 09:53: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 D2B7A3A6AB2 for ; Tue, 15 Sep 2009 09:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.335 X-Spam-Level: X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 5pFME+zMoBuM for ; Tue, 15 Sep 2009 09:53:30 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 15B3B3A6AAC for ; Tue, 15 Sep 2009 09:53:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 88CBA430240; Tue, 15 Sep 2009 09:54:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 6F6CE430236; Tue, 15 Sep 2009 09:54:16 -0700 (PDT) Message-ID: <4AAFC6B6.2070807@joelhalpern.com> Date: Tue, 15 Sep 2009 12:54:14 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Margaret Wasserman References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> <4AAD6D9B.1020400@joelhalpern.com> <4AAE0395.7080009@ericsson.com> <4AAE3A19.8060200@joelhalpern.com> <4AAE6428.40704@ericsson.com> <4AAE680F.6010203@joelhalpern.com> <4AAFA87B.2020708@ericsson.com> <5A05FC70-4152-44A6-84EE-6214638ED80B@sandstorm.net> In-Reply-To: <5A05FC70-4152-44A6-84EE-6214638ED80B@sandstorm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Hartman , "Philip F. Chimento" , lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 16:53:30 -0000 Assume for now that the corruption rate is really 1 in 7000. Of those, how many arrive at a real machine with a client sitting on the UDP port that is being read. And on which (assuming we permitted it) IPv6 UDP checksums are not enabled. And where the application does not have other check logic allowing it to safely ignore irrelevant packets (probably with a log message.) Because unless that compound number is noticeable, we are still talking about asking every LISP instance to do significant work on every packet to protect against a corner case. Yours, Joel Margaret Wasserman wrote: > > Hi Magnus, > > On Sep 15, 2009, at 10:45 AM, Magnus Westerlund wrote: >> Well turning off the checksum makes it 32000 times more likely to occur >> than it currently does. I am at least lacking current data on how often >> corruption occurs. The data that I know of indicates that it was fairly >> common 10 years ago, when the investigate sites sent or received packets >> with corruptions in them in varying degrees between 1:1100 to 1:32000. >> This is from Stone and Partridge paper: >> >> http://doi.acm.org/10.1145/347059.347561 > > Although less scientific than the Stone Partridge paper, some folks have > circulated error logs on the LISP list that indicate that the current > rate of corruption is still about the same. The largest sample we saw > had corruption of about 1:7000 packets. I've checked a few systems that > I have access to, and they are in the same range. So, it's unlikely > that the numbers have changed all that much in the last 10 years. > > Margaret > > From mrw@sandstorm.net Tue Sep 15 10:05: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 3D37328C12A for ; Tue, 15 Sep 2009 10:05:25 -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 FXKg6YHWacro for ; Tue, 15 Sep 2009 10:05:24 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 6A9DA3A6B65 for ; Tue, 15 Sep 2009 10:05:24 -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 n8FH67gv050375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Sep 2009 13:06:07 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090915163605.067C56BE5C4@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, 15 Sep 2009 13:06:07 -0400 References: <20090915163605.067C56BE5C4@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org, Philip.Chimento@jhuapl.edu Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 17:05:25 -0000 On Sep 15, 2009, at 12:36 PM, Noel Chiappa wrote: > > (I.e. no spreading the packets from a single TCP connection, etc, over > multiple paths; making sure this constraint doesn't get violated as a > result of steps taken during LISP encapsulation is the reason for > some of > the encapsulation field-setting algorithms. And apologies if you > already] > understood that - I occasionally forget it myself.) Right. We determine the UDP source port from a hash of the five-tuple (two IP addresses, IP protocol/next header, and two TCP/UDP ports) in the packet that is being encapsulated. So, the UDP port serves as a flow label, of sorts. This works for LAG/ECMP equipment that load balances based on the five-tuple of the outer header. > > Since deployed stuff - which includes core routers in the main > fabric of > the Internet, which LISP is intended to leave untouched - only provide > this capability for UDP and TCP (shudder), the choices are pretty > limited. Sort of... It is my understanding that the deployed LAG/ECMP equipment that parses on the five-tuple described above will fall back to a three- tuple (2 IP addresses and IP protocol/next header) when the protocol in use is not UDP or TCP. So, if we did a LISP-in-IP encapsulation and varied the IID of the source IP address based on a hash of the original packets' five-tuple, we would get the same load balancing effect as varying the UDP source port. Is that correct? Margaret From mrw@sandstorm.net Tue Sep 15 10:07: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 C21C128C14B for ; Tue, 15 Sep 2009 10:07:48 -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 UxM6U9ifcV+g for ; Tue, 15 Sep 2009 10:07:48 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id E8DE128C12B for ; Tue, 15 Sep 2009 10:07: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 n8FH8SIL050533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Sep 2009 13:08:28 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <5C0EE616-AD65-4FB4-B552-8199D199DE87@sandstorm.net> From: Margaret Wasserman To: Marshall Eubanks In-Reply-To: <92780460-9C91-4017-948F-BC32E0026F3A@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, 15 Sep 2009 13:08:27 -0400 References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> <4AAD6D9B.1020400@joelhalpern.com> <4AAE0395.7080009@ericsson.com> <4AAE3A19.8060200@joelhalpern.com> <4AAE6428.40704@ericsson.com> <4AAE680F.6010203@joelhalpern.com> <4AAFA87B.2020708@ericsson.com> <5A05FC70-4152-44A6-84EE-6214638ED80B@sandstorm.net> <92780460-9C91-4017-948F-BC32E0026F3A@americafree.tv> X-Mailer: Apple Mail (2.935.3) Cc: Sam Hartman , "Philip F. Chimento" , lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 17:07:48 -0000 On Sep 15, 2009, at 12:46 PM, Marshall Eubanks wrote: > > That mail thread was titled : Flow label redux [Re: IPv6 UDP > checksum issue] > > I don't remember this exact number, the ones I saw were all smaller. > Note that > > 1/7000 = 1.4 x 10^-4 > > Can you send me the email with that result ? > > Looking at some http servers here at AmericaFree.TV (we get plenty > of IPv4 UDP inbound) the rates seem to be > a bit lower for UDP on Gig-E fiber : Tell me a little more about your environment... Is this UDP sourced locally? Or from across the Internet? In other words, do you know the average number of hops that it would traverse before hitting this server? Margaret From mrw@sandstorm.net Tue Sep 15 10:12: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 972633A6B34 for ; Tue, 15 Sep 2009 10:12:12 -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 BlDlC3ujyBGf for ; Tue, 15 Sep 2009 10:12:11 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 88DA93A6AA9 for ; Tue, 15 Sep 2009 10:12:11 -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 n8FHCtJF050798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Sep 2009 13:12:56 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Marshall Eubanks In-Reply-To: <92780460-9C91-4017-948F-BC32E0026F3A@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, 15 Sep 2009 13:12:55 -0400 References: <4B4EFE25-BC75-4D96-987D-4F8D6589C6DB@americafree.tv> <8CC8E720-1325-46DB-8458-6EBDB8722209@sandstorm.net> <4AAD5616.3040602@joelhalpern.com> <9E68B6C1-0D47-40BD-BF1E-5CFC4224DB15@sandstorm.net> <4AAD6D9B.1020400@joelhalpern.com> <4AAE0395.7080009@ericsson.com> <4AAE3A19.8060200@joelhalpern.com> <4AAE6428.40704@ericsson.com> <4AAE680F.6010203@joelhalpern.com> <4AAFA87B.2020708@ericsson.com> <5A05FC70-4152-44A6-84EE-6214638ED80B@sandstorm.net> <92780460-9C91-4017-948F-BC32E0026F3A@americafree.tv> X-Mailer: Apple Mail (2.935.3) Cc: Sam Hartman , "Philip F. Chimento" , lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 17:12:12 -0000 On Sep 15, 2009, at 12:46 PM, Marshall Eubanks wrote: >> >> Although less scientific than the Stone Partridge paper, some folks >> have circulated error logs on the LISP list that indicate that the >> current rate of corruption is still about the same. The largest >> sample we saw had corruption of about 1:7000 packets. I've checked >> a few systems that I have access to, and they are in the same >> range. So, it's unlikely that the numbers have changed all that >> much in the last 10 years. > > That mail thread was titled : Flow label redux [Re: IPv6 UDP > checksum issue] > > I don't remember this exact number, the ones I saw were all smaller. > Note that Steiner Haug from nethelp.no sent these numbers to the list on 11 August, 2009: > - 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 This is a little more than 1:7000. Margaret From ljakab@ac.upc.edu Tue Sep 15 10:15: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 0CBCD3A6A8D for ; Tue, 15 Sep 2009 10:15:01 -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 g0U0eZ-LNanu for ; Tue, 15 Sep 2009 10:15:00 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by core3.amsl.com (Postfix) with ESMTP id 1417C28C108 for ; Tue, 15 Sep 2009 10:15:00 -0700 (PDT) Received: from gambus.localnet (gambus.ac.upc.es [147.83.34.118]) by gw.ac.upc.edu (Postfix) with ESMTP id C1B946B023D; Tue, 15 Sep 2009 19:15:44 +0200 (CEST) From: =?iso-8859-1?q?Lor=E1nd_Jakab?= Organization: UPC To: lisp@ietf.org Date: Tue, 15 Sep 2009 19:15:37 +0200 User-Agent: KMail/1.12.1 (Linux/2.6.31-gentoo; KDE/4.3.1; i686; ; ) References: <5A05FC70-4152-44A6-84EE-6214638ED80B@sandstorm.net> <92780460-9C91-4017-948F-BC32E0026F3A@americafree.tv> In-Reply-To: <92780460-9C91-4017-948F-BC32E0026F3A@americafree.tv> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2394366.71jprrNLkE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909151915.44580.ljakab@ac.upc.edu> Subject: Re: [lisp] =?iso-8859-1?q?New_Issue=3A_UDP-TUNNELS_inconsistent_with_?= =?iso-8859-1?q?5=2E4=2E1_MTU=09Handling?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 17:15:01 -0000 --nextPart2394366.71jprrNLkE Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tuesday, September 15, 2009 18:46:36 Marshall Eubanks wrote: > I think that checksum loss rates on fiber will be low - the lower > ones here are not that far from what you > would expect from fiber bit error rates < 10^-12. >=20 > Clearly, the checksum rates on fiber will be higher. As it happens, I > use some laptops as wireless routers. Here is data from one : >=20 > UDP : 3732883 datagrams received > 4 with bad checksum >=20 > 4 / 3,732,883 =3D 10^-6 >=20 > So, this is higher, but still not as high as 10^-4. >=20 > I am working on a writeup of the implications of these numbers. CAIDA, The Cooperative Association for Internet Data Analysis, in=20 cooparation with the DNS Operations, Analysis, and Research Center=20 organize each year since 2006 a 1-day (recently 2-day) DNS data=20 collection event, collecting traffic at DNS root servers, TLD servers=20 and client side iterative/caching resolvers. This may be the most=20 representative UDP dataset currently available. They have a page with statistics on checksum mismatch from the 2009 data=20 collection event here: https://www.dns-oarc.net/node/210 It seems that the failure rate is in the order of 10^-3 (with some=20 outliers in the 50% range). We could contact them for more details, I suppose. Regards, Lor=E1nd Jakab --nextPart2394366.71jprrNLkE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkqvy8AACgkQlUwN75BxDXTSvACgwNirjbkIDB2HrPM6CSm+b3VG TbAAn0Dj1DE4G32EEdOXh3QtmNQnYXbG =/6wJ -----END PGP SIGNATURE----- --nextPart2394366.71jprrNLkE-- From jnc@mercury.lcs.mit.edu Tue Sep 15 10:15: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 C2D743A6A3A for ; Tue, 15 Sep 2009 10:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 BGFojS4QGIge for ; Tue, 15 Sep 2009 10:15:21 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0C1903A68DE for ; Tue, 15 Sep 2009 10:15:18 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 8425E6BE5C4; Tue, 15 Sep 2009 13:16:03 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090915171603.8425E6BE5C4@mercury.lcs.mit.edu> Date: Tue, 15 Sep 2009 13:16:03 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu, Philip.Chimento@jhuapl.edu Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 17:15:21 -0000 > From: Margaret Wasserman > It is my understanding that the deployed LAG/ECMP equipment that > parses on the five-tuple described above will fall back to a three- > tuple (2 IP addresses and IP protocol/next header) when the protocol > in use is not UDP or TCP. You've exceeded my area of knowledge, so I can't say. > if we did a LISP-in-IP encapsulation and varied the IID of the > source IP address based on a hash of the original packets' > five-tuple, we would get the same load balancing effect as varying > the UDP source port. Is that correct? By 'varied the IID of the source IP address', you mean plain old 'varied the source IP address in the outer header', right? The problem with that is that all the control functions piggybacked on user-data traffic (liveness/reachability testing, and also mapping currency) would then stop working, since they packet would no longer contain the source ITR's RLOC. We also wouldn't be able to return LISP error messages (which we don't have yet, but I suspect we might need them) to the source ITR, since we wouldn't have its RLOC. Ditto for any ICMP errors the packet causes in transit - again, not sure if we will need them, though. But in general, at an architectural level, I'm uncomfortable not having a source address in the packet. Noel From mrw@sandstorm.net Tue Sep 15 10:36: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 506D43A6A24 for ; Tue, 15 Sep 2009 10:36:35 -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 1oq-G027RxRp for ; Tue, 15 Sep 2009 10:36:34 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 4DF1C3A6A8D for ; Tue, 15 Sep 2009 10:36:34 -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 n8FHbEkf051781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 15 Sep 2009 13:37:14 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <902ED4FE-3512-4645-8A7F-23CC1A573D90@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: Tue, 15 Sep 2009 13:37:13 -0400 X-Mailer: Apple Mail (2.935.3) Subject: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 17:36:35 -0000 Hi All, I have a new question for the group... I have some concerns about how LISP will perform when TCP is used over LISP when there is a lossy link somewhere in the mapping network and/ or the link from the mapping network to the remote ETR. I've been mapping out packet flows on my whiteboard, and I have a scenario that looks like this... Assume no existing LISP connections/mapping between site A (served by xTR A) and site B (served by xTR B). A host (Host A with EID A) behind ITR A initiates a TCP connection to a host (Host B with EID B) behind ETR B. The packet gets to ITR A, and ITR A sends a map request for EID B to its map resolver. ITR A also drops the original packet. What happens if the map request gets lost before it gets to ETR B? A very short time passes, and Host A retransmits the . The retransmission gets to ITR A, but the LISP spec indicates that map requests for the same EID should be rate limited to no more than one per second. So, the retransmission is dropped. This continues until a second has passed. After 1 second, Host A retransmits the again, and it is dropped by ITR A because there is no mapping. At that point, ITR A sends another map request for EID B. If this request gets a response, the Nth retransmission will finally be sent after 1 second + ~1 round trip of repeated retransmission. By this point, Host A has determined that there is significant congestion between Host A and Host B, when actually only one packet was lost. Host A will have a large retransmission timeout for Host B, and its slow-start mechanism will have significantly backed off due to (apparent) congestion. So, it will take a while for Host A to begin sending to EID B again at full speed. To avoid this scenario, I think we either need to institute some sort of retransmission for map requests that don't get a reply, or consider a more sophisticated rate limiting mechanisms than just one per second. Margaret P.S. I am also concerned about rate limiting the sending of map requests per-EID... Are there any cases where you would want to check the liveness of multiple locators using a map request probe? Wouldn't this effectively limit you to checking the liveness of one locator per second? From mrw@sandstorm.net Tue Sep 15 10:39: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 469253A6A8D for ; Tue, 15 Sep 2009 10:39:19 -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 5AYo55KyOJtE for ; Tue, 15 Sep 2009 10:39:18 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 7B85C3A6A24 for ; Tue, 15 Sep 2009 10:39:18 -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 n8FHe3er051999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Sep 2009 13:40:03 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <75E75D9B-2FBE-4838-B515-2CE99B02E327@sandstorm.net> From: Margaret Wasserman To: Margaret Wasserman In-Reply-To: <902ED4FE-3512-4645-8A7F-23CC1A573D90@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, 15 Sep 2009 13:40:03 -0400 References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 17:39:19 -0000 On Sep 15, 2009, at 1:37 PM, Margaret Wasserman wrote: > > By this point, Host A has determined that there is significant > congestion between Host A and Host B, when actually only one packet > was lost. Oh, and to make this worse, the packet that was lost (the map request) wasn't (necessarily) lost on a link that will be traversed by the TCP traffic... Margaret From dino@cisco.com Tue Sep 15 12:05: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 4D6E628C20E for ; Tue, 15 Sep 2009 12:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.356 X-Spam-Level: X-Spam-Status: No, score=-5.356 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_00=-2.599, MANGLED_HRDCOR=2.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 zDnufdVSKdzI for ; Tue, 15 Sep 2009 12:05:08 -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 E1CD628C200 for ; Tue, 15 Sep 2009 12:05:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHeCr0qrR7O6/2dsb2JhbADIGYhMAZATBYQXgVs X-IronPort-AV: E=Sophos;i="4.44,391,1249257600"; d="scan'208";a="242218263" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 15 Sep 2009 19:05:56 +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 n8FJ5ul4031685; Tue, 15 Sep 2009 12:05:56 -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 n8FJ5u8M013909; Tue, 15 Sep 2009 19:05:56 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, 15 Sep 2009 12:05:56 -0700 Received: from [192.168.1.2] ([10.21.148.92]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 12:05:55 -0700 Message-Id: <05D71F3E-E3AE-4486-AFAA-4F4F967E80A9@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AAFB90E.90803@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, 15 Sep 2009 12:05:55 -0700 References: <20090915150957.DA9BA6BE5C3@mercury.lcs.mit.edu> <4AAFB90E.90803@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Sep 2009 19:05:55.0823 (UTC) FILETIME=[8D7AFFF0:01CA3637] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1817; t=1253041556; x=1253905556; 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]=20New=20Issue=3A=20UDP-TUNNELS=2 0inconsistent=20with=205.4.1=09MTU=09Handling |Sender:=20; bh=+uHySCTVIWUC2ACl/PCaFBUhT9qYRk7IQBGdC1pRBMw=; b=FlDPFuwTNmAjIfK6lezNJo0zkGupMJf3e3/AzOUyHAw/M2+wGhSLjyrXLR 4hVxZVEd8/BLXzRa3pLoxBncvsCaM+SIoO6LgYKAmiWXCda5A2CDpQGwCe7t 5ZTRB89Hqq; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 19:05:10 -0000 Also note, if we depend on core routers to upgrade, LISP deployment will probably take a decade. There are tons of routers out there that do 5-tuple hashes on both an IPv4 and IPv6 headers to load-split traffic over ether-channels, port- channels, and multi-link GRE tunnels. We have two choices if we don't want to upgrade core routers, TCP or UDP. If we use GRE, L2TP, or even IPsec, the core routers will get greater than 10 gig flows (from the LAG router's point of view) that can't be put on one member of a LAG. So you will cut the bandwidth of these boxes by 1/nth where n is the number of members of a LAG. IMHO, if we do this, LISP is a non-starter. If we do this, all the benefit of LISP working "over-the-top" is gone. Dino On Sep 15, 2009, at 8:55 AM, Joel M. Halpern wrote: > This is a very reasonable question in this context. > Unfortunately, the answers are not clear cut. > > I have been able to find several vendors of relevant devices that > could upgrade. > I have also found at least one vendor where an upgrade to handle > ECMP/LAG on the basis of IPv6 flow spec would be hard (or even not > possible in nay meaningful time frame). > Several vendors have not answered me. > > But counting vendors probably does not tell us much. > If we count boxes, a LOT of boxes would be very hard to upgrade. > > Yours, > Joel > > Margaret Wasserman wrote: > ... >> I'd also like to get a better understanding of the state of the >> current IPv6 LAG/ECMP deployment, including how/if those systems >> could be upgraded to use the IPv6 flow label as part of the flow- >> identification. >> Margaret > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Tue Sep 15 12:09: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 A11C23A6A49 for ; Tue, 15 Sep 2009 12:09:25 -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 YXC9dF-CWfSk for ; Tue, 15 Sep 2009 12:09:24 -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 C29D328C147 for ; Tue, 15 Sep 2009 12:09:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGeDr0qrR7PE/2dsb2JhbADIBohMAZATBYQX X-IronPort-AV: E=Sophos;i="4.44,391,1249257600"; d="scan'208";a="189869492" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2009 19:10:12 +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 n8FJACmQ025506; Tue, 15 Sep 2009 12:10:12 -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 n8FJACus010832; Tue, 15 Sep 2009 19:10:12 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, 15 Sep 2009 12:10:12 -0700 Received: from [192.168.1.2] ([10.21.148.92]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 12:10:11 -0700 Message-Id: <1B381DBE-CD3E-44D0-858D-7676D65B958A@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 v936) Date: Tue, 15 Sep 2009 12:10:11 -0700 References: <20090915163605.067C56BE5C4@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Sep 2009 19:10:11.0783 (UTC) FILETIME=[260B6570:01CA3638] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=676; t=1253041812; x=1253905812; 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]=20New=20Issue=3A=20UDP-TUNNELS=2 0inconsistent=20with=205.4.1=20MTU=09Handling |Sender:=20; bh=fvmth7mYPgl+Q9hkFeM+3Eea13mWjNdlNLEJtlfPsRI=; b=cTnpeOjB4sXx5dcEIkhSmCyiC4RneFGaI+py2LW57BT+lI+7LzwfFdwVFL Cm7DvTsSkU3/F2HUzYQXkHdZJagalDPk0EtHe/2s7nFbcOl/VMC5b2ChQ2c8 65iguQFkl0; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Philip.Chimento@jhuapl.edu, Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 19:09:25 -0000 > It is my understanding that the deployed LAG/ECMP equipment that > parses on the five-tuple described above will fall back to a three- > tuple (2 IP addresses and IP protocol/next header) when the protocol > in use is not UDP or TCP. So, if we did a LISP-in-IP encapsulation > and varied the IID of the source IP address based on a hash of the > original packets' five-tuple, we would get the same load balancing > effect as varying the UDP source port. Is that correct? Most cisco equipment falls back to (source, dest) when protocol is not TCP and UDP. Which is not really good because it causes TCP packet drops when UDP is blasting. Dino From mrw@sandstorm.net Tue Sep 15 12:10: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 E19B13A67D2 for ; Tue, 15 Sep 2009 12:10:46 -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 bQ3BHXSvqGsI for ; Tue, 15 Sep 2009 12:10:45 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 710F528C186 for ; Tue, 15 Sep 2009 12:10:45 -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 n8FJAO9g056641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Sep 2009 15:10:24 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <05D71F3E-E3AE-4486-AFAA-4F4F967E80A9@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, 15 Sep 2009 15:10:23 -0400 References: <20090915150957.DA9BA6BE5C3@mercury.lcs.mit.edu> <4AAFB90E.90803@joelhalpern.com> <05D71F3E-E3AE-4486-AFAA-4F4F967E80A9@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 19:10:47 -0000 On Sep 15, 2009, at 3:05 PM, Dino Farinacci wrote: > Also note, if we depend on core routers to upgrade, LISP deployment > will probably take a decade. > > There are tons of routers out there that do 5-tuple hashes on both > an IPv4 and IPv6 headers to load-split traffic over ether-channels, > port-channels, and multi-link GRE tunnels. What do they do for non-UDP/TCP traffic? Do they load balance based on the three-tuple (2 addresses and a protocol/next-header value)? Margaret From Fred.L.Templin@boeing.com Tue Sep 15 12:39: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 C3EAF28C1E4 for ; Tue, 15 Sep 2009 12:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.981 X-Spam-Level: X-Spam-Status: No, score=-5.981 tagged_above=-999 required=5 tests=[AWL=0.618, 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 6onohcL22o2X for ; Tue, 15 Sep 2009 12:39:27 -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 D60FB3A68EA for ; Tue, 15 Sep 2009 12:39:27 -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 n8FJeDR0020202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Sep 2009 12:40:14 -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 n8FJeBQ5004087; Tue, 15 Sep 2009 12:40:12 -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 n8FJe0Lh003670; Tue, 15 Sep 2009 12:40:10 -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); Tue, 15 Sep 2009 12:40:07 -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, 15 Sep 2009 12:40:06 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10665D11B@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1MTU Handling Thread-Index: Aco2G7JDRAN7jnKnTAS+LJjw6Ek9UgAAZKhw References: <20090915150957.DA9BA6BE5C3@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Margaret Wasserman" , "Noel Chiappa" X-OriginalArrivalTime: 15 Sep 2009 19:40:07.0062 (UTC) FILETIME=[541D3B60:01CA363C] Cc: lisp@ietf.org, Philip.Chimento@jhuapl.edu Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 19:39:28 -0000 Margaret, > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@sandstorm.net] > Sent: Tuesday, September 15, 2009 8:46 AM > To: Noel Chiappa > Cc: lisp@ietf.org; Philip.Chimento@jhuapl.edu > Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1MTU Handling >=20 >=20 > On Sep 15, 2009, at 11:09 AM, Noel Chiappa wrote: > > > > It may be that there's just no choice for IPv6 that works for all > > parties > > (ISPs, routers, hosts). >=20 > Just to make my personal interests clear in this discussion, there is > something I think you should all know... >=20 > Sam Hartman and I are currently working on a LISP implementation (with > his company, Painless Security) that is designed to be portable to > several general-purpose and embedded operating systems. Our > implementation is targeted at exactly the sort of lower-end router > (home gateway, CPE equipment or small business gateway) that I have > been discussing. It currently uses the IP stack and other facilities > provided by the operating systems on which it runs. Operation within these sorts of use cases brings on a much broader set of considerations, including autoconfiguration, enterprise virtual partitioning, provider-independent and provider-aggregated addressing, {host,router}-to-{host,router} tunneling, MTU diversity, mobile ad-hoc networking, etc. And, we already have technologies that fit these spaces, namely ISATAP, VET, and SEAL. As you know, ISATAP is already widely deployed. We also have it implemented in Linux in addition to the commercial implementations that already exist. We also have early linux implementations of VET and SEAL. RANGER tells how it all fits together, and RANGERS outlines applicability to the various use cases. To help understand the positioning a bit better, VET is also known as "ISATAP Version 2". Fred fred.l.templin@boeing.com=20 > So, in addition to my interest in producing a good LISP protocol that > will benefit the Internet, I have some personal interest in the > outcome of this discussion. >=20 > I can also say, rather authoritatively, that there is at least one > LISP implementation that is targeted at these environments. >=20 > Margaret >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Tue Sep 15 13:28: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 380183A6ABB for ; Tue, 15 Sep 2009 13:28:21 -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 oHxo3HBLuEY6 for ; Tue, 15 Sep 2009 13:28: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 881B53A6AB3 for ; Tue, 15 Sep 2009 13:28:20 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D45174556; Tue, 15 Sep 2009 16:29:04 -0400 (EDT) To: Dino Farinacci References: <20090915163605.067C56BE5C4@mercury.lcs.mit.edu> <1B381DBE-CD3E-44D0-858D-7676D65B958A@cisco.com> From: Sam Hartman Date: Tue, 15 Sep 2009 16:29:04 -0400 In-Reply-To: <1B381DBE-CD3E-44D0-858D-7676D65B958A@cisco.com> (Dino Farinacci's message of "Tue\, 15 Sep 2009 12\:10\: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: Noel Chiappa , lisp@ietf.org, Philip.Chimento@jhuapl.edu, Margaret Wasserman Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 20:28:21 -0000 >>>>> "Dino" == Dino Farinacci writes: Dino> Most cisco equipment falls back to (source, dest) when Dino> protocol is not TCP and UDP. Which is not really good Dino> because it causes TCP packet drops when UDP is blasting. Dino, I really hate to be sending more messages to this thread. However I'm confused about what you're saying above. I don't understand how the second part of your statement (tcp loss) follows from the first (two-tuple). From jzwiebel@cisco.com Tue Sep 15 13:39: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 A45513A690A for ; Tue, 15 Sep 2009 13:39:15 -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=[AWL=0.001, 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 v+yye9E1PbpY for ; Tue, 15 Sep 2009 13:39: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 BA3443A68F7 for ; Tue, 15 Sep 2009 13:39:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAyYr0qrR7O6/2dsb2JhbADHW4hMAZAmBYQXimk X-IronPort-AV: E=Sophos;i="4.44,391,1249257600"; d="scan'208";a="389375057" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Sep 2009 20:40:02 +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 n8FKe2FZ019963; Tue, 15 Sep 2009 13:40:02 -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 n8FKe2qf024964; Tue, 15 Sep 2009 20:40:02 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 13:40:02 -0700 Received: from [10.0.1.3] ([10.21.121.147]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 13:40:01 -0700 In-Reply-To: References: <20090915163605.067C56BE5C4@mercury.lcs.mit.edu> <1B381DBE-CD3E-44D0-858D-7676D65B958A@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <578E5344-314C-4A60-B211-3C65CDD87790@cisco.com> Content-Transfer-Encoding: 7bit From: John Zwiebel Date: Tue, 15 Sep 2009 10:39:59 -1000 To: Sam Hartman X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 15 Sep 2009 20:40:01.0857 (UTC) FILETIME=[B2C76B10:01CA3644] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=811; t=1253047202; x=1253911202; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[lisp]=20New=20Issue=3A=20UDP-TUNNELS=2 0inconsistent=20with=205.4.1=20MTU=20Handling |Sender:=20; bh=trowYjy09ppb2YiS/RIEDkFd9ekhQGE+edeoZWcQyMw=; b=2WjBTEmpDqPA1HEGP+0f/fwJECKyOCh78pVMJlkCrG0UIMO68t6GfcZ9eE bISiXN59s0a4v1k8++A8eK4T7Z4oyRYhhDJxPHP3o2LjRmQo0IIIc0ARxjub grUnru7a3t; Authentication-Results: sj-dkim-2; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Noel Chiappa , Margaret Wasserman , Philip.Chimento@jhuapl.edu, lisp@ietf.org Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 20:39:15 -0000 On Sep 15, 2009, at 10:29 AM, Sam Hartman wrote: >>>>>> "Dino" == Dino Farinacci writes: > > Dino> Most cisco equipment falls back to (source, dest) when > Dino> protocol is not TCP and UDP. Which is not really good > Dino> because it causes TCP packet drops when UDP is blasting. > > > Dino, I really hate to be sending more messages to this thread. > However I'm confused about what you're saying above. > > > I don't understand how the second part of your statement (tcp loss) > follows from the first (two-tuple). > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp The packets are not spread over the LAG but only over one link One link gets full, the other can be empty. From dino@cisco.com Tue Sep 15 14:04: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 1CEAF3A6831 for ; Tue, 15 Sep 2009 14:04:40 -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 BMuDEyg3ZA05 for ; Tue, 15 Sep 2009 14:04: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 30E303A68D1 for ; Tue, 15 Sep 2009 14:04:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJeer0qrR7O6/2dsb2JhbADHPIhMAZArBYQXimk X-IronPort-AV: E=Sophos;i="4.44,392,1249257600"; d="scan'208";a="242296790" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 15 Sep 2009 21:05:27 +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 n8FL5Qtu016135; Tue, 15 Sep 2009 14:05:26 -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 n8FL5QIL023063; Tue, 15 Sep 2009 21:05:26 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, 15 Sep 2009 14:05:26 -0700 Received: from dhcp-171-71-55-217.cisco.com ([171.71.55.217]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 14:05:26 -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 v936) Date: Tue, 15 Sep 2009 14:05:25 -0700 References: <20090915163605.067C56BE5C4@mercury.lcs.mit.edu> <1B381DBE-CD3E-44D0-858D-7676D65B958A@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Sep 2009 21:05:26.0363 (UTC) FILETIME=[3F7492B0:01CA3648] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=890; t=1253048726; x=1253912726; 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]=20New=20Issue=3A=20UDP-TUNNELS=2 0inconsistent=20with=205.4.1=20=20MTU=20Handling |Sender:=20; bh=kmRUNd5e8W7/5otetzSAgLmfXAfNWA6Ezu49n2sldGI=; b=pPDxFeBViw8JbdpTRpakcUQ9saxbSWKEIaD4sR/+C5Qu5/f0XkFAy6il36 KknbQc+7vdDMyYrnsQAYkP7L13nEUQFdvm+qDHC3TuKFrDuzmoiSeS3WjGMM vKlkv0PIcq; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Noel Chiappa , lisp@ietf.org, Philip.Chimento@jhuapl.edu, Margaret Wasserman Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 21:04:40 -0000 >>>>>> "Dino" == Dino Farinacci writes: > > Dino> Most cisco equipment falls back to (source, dest) when > Dino> protocol is not TCP and UDP. Which is not really good > Dino> because it causes TCP packet drops when UDP is blasting. > > > Dino, I really hate to be sending more messages to this thread. > However I'm confused about what you're saying above. > > > I don't understand how the second part of your statement (tcp loss) > follows from the first (two-tuple). No prob. Let me explain. If TCP and UDP are encapsulated in IPsec or GRE, then TCP suffers because it is competing with UDP for bandwidth and output queue resources for a member of a LAG. Having a 3-tuple hash would work as Margaret suggests, if it was (outer-source,outer-dest,inner-protocol) then you could have TCP and UDP possibly hash differently. Dino From hartmans@mit.edu Tue Sep 15 16:41: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 4A3693A6943 for ; Tue, 15 Sep 2009 16:41:52 -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 NNRGqrwK86uv for ; Tue, 15 Sep 2009 16:41:51 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id CAD503A686C for ; Tue, 15 Sep 2009 16:41:50 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BF75D4556; Tue, 15 Sep 2009 19:42:35 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Tue, 15 Sep 2009 19:42:35 -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] #9, #10, #11: UDP checksum consensus call X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 15 Sep 2009 23:41:52 -0000 One line answer: Friday diff with an additional note Folks, we've spent a lot of bits discussing UDP checksums. I think we're going in circles at this point and are not significantly covering new ground. remember that what we were trying to do was to describe what LISP would do well enough that we could put this issue aside until 6man and the rest of the IETF decided for the IETF as a whole. Obviously, we'll go along with whatever IETF consensus emerges. So, we don't need to get this perfect. It's not actually clear we needed to say anything at all, although I believe a lot of us see value in telling implementations what is going on today. I don't think there is more value in discussing the referenced UDP issues (and see a separate note on #12 I'll send) So, to remind ourselves, especially for the tracker: * We get significant benefit from using UDP or TCP because it makes working with existing ECMP/LAG boxes possible. * For IPv6 the current specs do not allow sending 0 UDP checksum; we believe that there are significant hardware implementations that cannot calculate UDP checksums without forcing the checksum calculation to software. That's a non-starter for some of the deployment environments that these vendors want to use their hardware implementation in because the load would be higher than what could be handled in software. * We believe there are implementations that would be difficult to change to send 0 checksums ** Several commodity operating systems have removed the configuration parameter to send 0 checksums; where it exists, it tends to be per-system and not per socket/flow. ** Existing commodity IP stacks definitely don't send 0 checksums for IPv6. ** One implementor and several individuals have indicated that is desirable to be able to implement on commodity IP stacks. * We don't actually need to require that you send 0 checksums; there is debate about whether you should do so when you can. * For hardware implementations that cannot reasonably send UDP checksums to be able to turn them off, all receivers must be able to receive 0 checksums. * There are implementations of IP and UDP that would be very difficult to change in order to accept 0 checksums for UDP for IPv6. There are hardware, software and politics issues, depending on the implementation * Based on the discussion I think it likely that we will not achieve universal interoperability for lisp over IPv6 if 0 checksums are sent. It's unclear how big of a problem this will be in practice. Alternatives proposed: * Give up on the LAG/ECMP requirement. ** It's not clear how soon we need LAG/ECMP for V6; some have said today, but other WG participants questions this. ** It seems that it might be a full hardware cycle (7 years? 10 years?) before you could depend on different LAG behavior. * Use multiple source addresses--twiddle the V6 IID in order to work with ECMP/LAG and use something other than UDP ** The chairs called for people to flesh out such alternatives but none were fleshed out ** Doing this is very tricky. For example, the control plane needs to be adapted so that things like locator reachability work. ** Some participants have claimed this is impossible. I don't think that claim has been substantiated. However there is no version of this proposal fleshed out sufficiently to be evaluated, and we have given ample opportunity for such a proposal to be developed. Sausage was made. There was a lot of discussion. In the judgment of the chairs, the LISP working group has reached rough consensus on the text in Dino's Friday diff. We do not believe that additional discussion of the same issues will yield a better result within the LISP working group. Someone's going to ask when it would be appropriate to re-open this discussion. This is my personal opinion; I have not discussed in detail with Darrel. * When the IETF comes to consensus on handling UDP encapsulation for tunnels we will need to revisit this issue. Even if what is now our preferred behavior is permitted by IETF standards track documents, it is quite conceivable that the larger discussion will bring forward information that changes our thinking. * #13 discusses analysis that we need to do in order to confirm that LISP itself does not require integrity protection and that LISP will not damage other Internet hosts. I think we should leave concerns about damaging other Internet hosts to the rest of the IETF, at least until they tell us what the bar is. If we find that LISP itself needs integrity protection, we could potentially revisit this discussion, although we should probably prefer other approaches. * I don't think we've come to an informed consensus about the tradeoff between various classes of implementation and for example how bad it would be not to have interop with commodity IP stacks. In particular, the WG has not become sufficiently informed about the lisp deployment model. I think there is a presumption in the WG (one I suspect that once I understand the deployment model I'll probably support) that it's really important for LISP to be able to run on high-end routers. I think there is a presumption in the WG that it is less important for it to be able to run on stock IP stacks. If the deployment discussion significantly changes our thinking, we may revisit this issue for that reason. However I think it would have to be a significant shift for it to be worthwhile. Jari has asked the chairs to make it clear that this is a broader issue and that we'll align with what the. IETF does. So, I'm asking Dino to take his Friday text plus a sentence noting that we will align with the IETF when it is done. I have not wordsmithed this; I'd like to go with this for 04, and we can revise in 05 if really needed. However I ask you to carefully consider whether you really want to re-open this can of worms before you propose textual changes. UDP Checksum: this field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion. From dino@cisco.com Tue Sep 15 17:00: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 98FB83A6A69 for ; Tue, 15 Sep 2009 17:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIvZzo1qBjpw for ; Tue, 15 Sep 2009 17:00: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 133D63A690B for ; Tue, 15 Sep 2009 17:00:07 -0700 (PDT) X-Files: rfcdiff-lisp-03-to-04.html, draft-ietf-lisp-04.txt : 166107, 151145 X-IronPort-AV: E=Sophos;i="4.44,393,1249257600"; d="txt'?html'217?scan'217,208,217";a="242380076" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Sep 2009 00:00:55 +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 n8G00sQ7026294; Tue, 15 Sep 2009 17:00:54 -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 n8G00sGc024870; Wed, 16 Sep 2009 00:00:55 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, 15 Sep 2009 17:00:54 -0700 Received: from dhcp-171-71-55-217.cisco.com ([171.71.55.217]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 17:00:54 -0700 Message-Id: <41850239-E55B-47E3-9A3B-E124F350851A@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: multipart/mixed; boundary=Apple-Mail-9--125850251 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 15 Sep 2009 17:00:56 -0700 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Sep 2009 00:00:54.0213 (UTC) FILETIME=[C28AFF50:01CA3660] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=326733; t=1253059255; x=1253923255; 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#9,=20#10,=20#11=3A=20UDP=20ch ecksum=20consensus=20call |Sender:=20; bh=BiRl/+hJf+sW7GTl445lYdcuNdXA2FzDfqDD5jpLAX4=; b=i1egF3KEF3GibH6YmC5GLTbmtq4Invc+fHbLGBtma6jsCWARfELjKT5jYt /aQ0XQ+6tbusc6g3s+gC6DXY1iW1+qkISTxebAUDkwrkUUm+3sTenMTskZwA mO+uOVALcV; 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] #9, #10, #11: UDP checksum consensus call X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 00:00:07 -0000 --Apple-Mail-9--125850251 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > Jari has asked the chairs to make it clear that this is a broader > issue and that we'll align with what the. IETF does. So, I'm asking > Dino to take his Friday text plus a sentence noting that we will align > with the IETF when it is done. I have not wordsmithed this; I'd like > to go with this for 04, and we can revise in 05 if really needed. > However I ask you to carefully consider whether you really want to > re-open this can of worms before you propose textual changes. > > UDP Checksum: this field SHOULD be transmitted as zero by an ITR > for > either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. > When a > packet with a zero UDP checksum is received by an ETR, the ETR > MUST accept the packet for decapsulation. When an ITR > transmits a > non-zero value for the UDP checksum, it MUST send a correctly > computed value in this field. When an ETR receives a packet with > a non-zero UDP checksum, it MAY choose to verify the checksum > value. If it chooses to perform such verification, and the > verification fails, the packet MUST be silently dropped. If the > ETR chooses not to perform the verification, or performs the > verification successfully, the packet MUST be accepted for > decapsulation. The handling of UDP checksums for all tunneling > protocols, including LISP, is under active discussion within the > IETF. When that discussion concludes, any necessary changes > will be made to align LISP with the outcome of the broader > discussion. Here are the latest diffs with the above change included. I have also removed the Mobility-bit from the spec per Jari, among others, who indicated that mobility stuff is out of scope for the working group. Chairs, let me know when we can post -04. Thanks! Dino/Dave/Darrel/Vince --Apple-Mail-9--125850251 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 19, 2010                                         D. Lewis
                                                           cisco Systems
                                                           July 27,
                                                      September 15, 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 19, 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 22
       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 36
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 36 37
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 38 39
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 39 41
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 40 42
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 40 43
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 41 44
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 43 46
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 44 47
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 45 48
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 45 48
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 46 49
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 47 50
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 51
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 51
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 48 51
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 50 53
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 50 53
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 53
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 53
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 52 55
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 52 55
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 54 57
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 55 58
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 56 59
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 62
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 59 62
     14.2. Informative References . . . . . . . . . . . . . . . . . . 60 63
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 63 66
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 67

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 statically 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 prepends 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
      statically 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 prepends 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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 /   |N|L|E|  rflags |                       Locator Reach Bits                 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

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

   OH

   Outer 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 SHOULD be transmitted as 0 and ignored on
      receipt zero by the ETR.  Note, even when the an ITR for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
      packet with a zero UDP checksum is
      transmitted as 0 received by an intervening NAT device can recalculate ETR, the
      checksum and rewrite ETR
      MUST accept the UDP checksum field to non-zero.  For
      performance reasons, packet for decapsulation.  When an ITR transmits a
      non-zero value for the ETR UDP checksum, it MUST ignore send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not
      do a checksum computation. to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.  The handling of UDP checksums for all tunneling
      protocols, including LISP, is under active discussion within the
      IETF.  When that discussion concludes, any necessary changes will
      be made to align LISP with the outcome of the broader discussion.

   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

   N: this is 8 bytes when no loc-reach-bit the nonce-present bit.  When this bit is set to 1, the
      low-order 24-bits of the first 32-bits of the LISP header contains
      a Nonce.  See section Section 6.3.1 for details.

   L: this is the Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header extensions are used. in use.

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1.  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.

   rflags:  this 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
      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.  When the E-bit is clear but the N-bit
      is set, an ITR is either echoing a previously requested echo-nonce
      or providing a random nonce.  See section Section 6.3.1 for more
      details.

   LISP Locator Reach Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the reachability up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator
      Reach Status Bits are numbered from 0 to n-1 from the right least
      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 is
      reachable. 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 Reach Status Bits
      setting in an encapsulated packet MUST reflect the mapping for the
      EID-prefix that the inner-header source EID address matches.

   S: this is the Solicit-Map-Request (SMR) bit.  See section
      Section 6.5.2 for details.

   E: this is the echo-nonce-request bit.  See section Section 6.3.1 for
      details.

   rsvd-flags:  this 6-bit

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The outer header Time to Live 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.
      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 is set to solicit the other side to send a Map-
      Request containing this nonce.  See section Section 6.5.2 for
      details.

   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 (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

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

   When doing Re-encapsulated Tunneling:

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

   o  The new OH outer header Type of Service field SHOULD be copied from
      the stripped OH header Type of Service field (with one caveat, see
      below)..
      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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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 Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record count. Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  A 4-byte  An 8-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.  The
      security of the LISP mapping protocol depends critically on the
      strength of the nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   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

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request, it may
   originate a "verifying Map-Request", addressed to the original ITR.
   If the ETR has a map-cache entry that matches the "piggybacked" EID
   and the RLOC is in the locator-set for the entry, then it may send
   the "verifying Map-Request" to the original Map-Request source.  If
   not, then it MUST send it to the "piggybacked" EID.  Doing this
   forces the "verifying Map-Request" to go through the mapping database
   system to reach the authoritative source of information about that
   EID, guarding against RLOC-spoofing in in the "piggybacked" 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  |A| ACT  | ACT |A|      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
      advertising that the site 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 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request
      that is echoed here in this Nonce field of the Map-Reply. 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.

   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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  |A| ACT  | ACT |A|      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  This 8-byte 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, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply and or that stored in the database
   mapping service does not database system provide any reachability status information for Locators.  This is done outside RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the mapping service.  See Routing Locator Reachability Algorithms described in the
   next section for details. section.

6.3.  Routing Locator Reachability

   There are 4 methods

   Several mechanisms for determining when a Locator is either
   reachable or has become unreachable:

   1.  Locator RLOC reachability is determined by an are currently
   defined:

   1.  An ETR by examining may examine the Loc-Status-Bits in the
       Loc-Reach-Bits from a LISP header of a an
       encapsulated data packet
       which received from an ITR.  If the ETR is provided by
       also acting as an ITR when an and has traffic to return to the original
       ITR encapsulates data.

   2.  Locator unreachability is determined by site, it can use this status information to help select an
       RLOC.

   2.  An ITR by receiving may receive an ICMP Network or ICMP Host Unreachable messages.

   3.  Locator unreachability can also be determined by
       message for an BGP-enabled RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  An ITR when there which participates in the global routing system can
       determine that an RLOC is down if no prefix matching a Locator address from the BGP RIB. RIB route exists that
       matches the RLOC IP address.

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

   5.  Locator reachability is determined by receiving  An ITR may receive a Map-Reply
       message from a ETR's Locator address ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  Locator reachability can also be determined by receiving packets  When an ETR receives an encapsulated by packet from an ITR, the ITR assigned to
       source RLOC from the locator address. outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   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 an encapsulating ITR closest to the Locators about
   reachability for all ETRs at the source site.  The  CE-based ITRs at the source
   site can determine reachability when running their
   IGP at the site.  When relative to each other using the ITRs are deployed on CE routers, typically site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route is injected into the site's IGP from each of the
   ITRs. site IGP.

   o  If an ITR goes down, the CE-PE link goes down, fails or if the upstream link to its PE
   router goes down, the CE router withdraws the fails, its
      default route.  This
   allows the other ITRs at route will either time-out or be withdrawn.

   Each ITR can thus observe the site presence or lack of a default route
   originated by the others to determine one of the Locators
   has gone unreachable.

   The Locators Locator Status Bits it sets
   for them.

   RLOCs 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 encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit numbered as 0.  So,
   for bit.  For example, if the ITR with locator an RLOC
   listed as in the 3rd Locator position in of the Map-Reply goes down, down (ordinal value
   2), then all other ITRs at the site will
   have clear the 3rd least significant
   bit from (xxxx x0xx) of the right cleared (the bit that corresponds to
   ordinal 2). Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will look check for a any change in
   the
   Loc-Reach-Bits value. Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to the Locator an RLOC that has just gone
   unreachable. is indicated as
   down.  It can start will only resume using the Locator again when the bit that
   corresponds to RLOC if the Locator goes from 0 corresponding Loc-
   Status-Bit returns to a value of 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 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 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 which transmits traffic from that site or to determine when the site path to site
   traffic is unidirectional so there a specific locator is no ITR returning traffic.

   Note that other
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator reachability mechanisms are being researched
   and 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.

   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 more secure to reach an authoritative ETR,
   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 24-bit Nonce field in the LISP encapsulation header. header and a
   64-bit Nonce field in the LISP control message.  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 have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   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,  Two are the Echo-Noncing and
        RLOC-Probing algorithms which is are documented in this
        specification.  The other two are third is 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.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

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

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

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.

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, Sam Hartman, Michael Hofling, and Pedro Marques.

   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-9--125850251 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-9--125850251 Content-Disposition: attachment; filename=draft-ietf-lisp-04.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-04.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: March 19, 2010 D. Lewis cisco Systems September 15, 2009 Locator/ID Separation Protocol (LISP) 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 March 19, 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. Farinacci, et al. Expires March 19, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . 36 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 37 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 39 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 41 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 42 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 43 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 44 7. Router Performance Considerations . . . . . . . . . . . . . . 46 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 47 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 48 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 48 Farinacci, et al. Expires March 19, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 49 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 50 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 51 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 51 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 51 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 53 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 53 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 55 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 55 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 57 12. Security Considerations . . . . . . . . . . . . . . . . . . . 58 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 59 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 14.1. Normative References . . . . . . . . . . . . . . . . . . . 62 14.2. Informative References . . . . . . . . . . . . . . . . . . 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 Farinacci, et al. Expires March 19, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 19, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 19, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 19, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 19, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 statically 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 prepends 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 statically configured. Farinacci, et al. Expires March 19, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 prepends 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 Farinacci, et al. Expires March 19, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 19, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | | Farinacci, et al. Expires March 19, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer 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 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 SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion. 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 Farinacci, et al. Expires March 19, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 headers are used. The UDP header length is 8 bytes. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See section Section 6.3.1 for details. L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. E: this is the echo-nonce-request bit. When this bit is set to 1, the N bit must be 1. 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. rflags: this 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 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. When the E-bit is clear but the N-bit is set, an ITR is either echoing a previously requested echo-nonce or providing a random nonce. See section Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least 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 outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Farinacci, et al. Expires March 19, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 Type of Service field (with one caveat, see below). When doing Re-encapsulated Tunneling: o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer 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. Farinacci, et al. Expires March 19, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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. Farinacci, et al. Expires March 19, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet with DF bit set to 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. Farinacci, et al. Expires March 19, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires March 19, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 | | + 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. Farinacci, et al. Expires March 19, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D1 |A|M|P|S| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . 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: Farinacci, et al. Expires March 19, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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 Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. 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. Farinacci, et al. Expires March 19, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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. An ITR that is configured with mapping database information (i.e. it Farinacci, et al. Expires March 19, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request, it may originate a "verifying Map-Request", addressed to the original ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map-Request" to the original Map-Request source. If not, then it MUST send it to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" 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=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| 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: Farinacci, et al. Expires March 19, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. See section Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is advertising that the site 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 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of 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. 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. Farinacci, et al. Expires March 19, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 (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. 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. Farinacci, et al. Expires March 19, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 [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 [RFC4302] is: Farinacci, et al. Expires March 19, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 SHA-1 or SHA-128 HMAC. The Map-Register message format is: Farinacci, et al. Expires March 19, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D3 |P| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| 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: This 8-byte 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. Farinacci, et al. Expires March 19, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o A "gleaned" map-cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. Farinacci, et al. Expires March 19, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the 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 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 Farinacci, et al. Expires March 19, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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 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 Farinacci, et al. Expires March 19, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 nonce echo, it sets the 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 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 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. 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. Farinacci, et al. Expires March 19, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 obtain those benefits, especially if the 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. Farinacci, et al. Expires March 19, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 19, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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-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-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-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. Farinacci, et al. Expires March 19, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the 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 ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- prefix uses is the one copied from the SMR 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 Farinacci, et al. Expires March 19, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 the loc-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending 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 more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. Farinacci, et al. Expires March 19, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 19, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, Farinacci, et al. Expires March 19, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 19, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 19, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 19, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 19, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. 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. Farinacci, et al. Expires March 19, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Interoperable implementations have been available since the beginning of 2009. We are trying to converge on a packet format so implementations can converge on the -04 and later drafts. 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. Farinacci, et al. Expires March 19, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts 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. Farinacci, et al. Expires March 19, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. [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. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [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. Farinacci, et al. Expires March 19, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 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), Farinacci, et al. Expires March 19, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-02.txt (work in progress), 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", Farinacci, et al. Expires March 19, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 19, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, and Pedro Marques. 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. Farinacci, et al. Expires March 19, 2010 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 19, 2010 [Page 67] =0C --Apple-Mail-9--125850251 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-9--125850251-- From dino@cisco.com Tue Sep 15 17:57: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 C39C03A689B for ; Tue, 15 Sep 2009 17:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 RNNvxS1i9qi2 for ; Tue, 15 Sep 2009 17:57:16 -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 586BB3A6778 for ; Tue, 15 Sep 2009 17:57:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPfUr0qrR7MV/2dsb2JhbADGTohMAZAyBYQX X-IronPort-AV: E=Sophos;i="4.44,393,1249257600"; d="scan'208";a="389527294" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Sep 2009 00:58:04 +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 n8G0w4XY027529; Tue, 15 Sep 2009 17:58:04 -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 n8G0w4b6004572; Wed, 16 Sep 2009 00:58:04 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, 15 Sep 2009 17:58:04 -0700 Received: from dhcp-171-71-55-217.cisco.com ([171.71.55.217]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 17:58:03 -0700 Message-Id: From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <902ED4FE-3512-4645-8A7F-23CC1A573D90@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, 15 Sep 2009 17:58:06 -0700 References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Sep 2009 00:58:03.0989 (UTC) FILETIME=[BED94850:01CA3668] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9182; t=1253062684; x=1253926684; 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]=20LISP=20Over=20Lossy=20Links |Sender:=20; bh=LCysEnDsiZN4ol/HzqOFtWBRDLqXNRPs0NdIwFLemfw=; b=G/h/euiC/sb+MH3CMF0Shmy+C6DS2Ou1st2Hvt1zTFMUCkUWs5b3TgsGLc xxbv2byGQnz7UUgO5XoZG3wFwphVNFdwKWJbt+jDAltISreAljCI21JsR1K1 Q2qkOnUUN27b3ZYyhwFtM0hUZfoEdsz4dExq/toK7pS/J47pCMjms=; 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] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 00:57:17 -0000 Let me show you what happens from this trace. I indented the trace data and my comments follow. This is an ITR that is ssh'ing to an ETR when the map-cache for the ETR does not exist. Note EIDs are in 240.0.0.0/8 space and locators are in 1.0.0.0/8. > dr22(config-if)# ssh 240.23.0.23 > 18:55:09.290262 netstack: [3620] (default) Send packet on > Ethernet2/2 (prty 7): s=1.22.23.22, d=1.11.22.11, nh=1.11.22.11, > proto=17 (udp), sport=65375, dport=4341, udp_len=120, chksum=0, tos/ > dscp=0xc0/0x30, This is the encapsulated Map-Request. Yes, the SYN is dropped. > 18:55:09.292337 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), > sport=4342, dport=65375, udp_len=60, chksum=c0ce, tos/dscp=0xc0/0x30, This is the returning Map-Reply. Notice 2ms RTT because boxes are in the same rack. > 18:55:12.310387 netstack: [3620] (default) Send packet on > Ethernet2/6 (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, > proto=17 (udp), sport=61567, dport=4341, udp_len=76, chksum=0, tos/ > dscp=0x0/0x0, This is the retransmitted SYN LISP encapsulated packet. Note the retransmission timer is 3 seconds. > 18:55:12.311510 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), > sport=61567, dport=4341, udp_len=72, chksum=0, tos/dscp=0x0/0x0, > ip_len=92, id=f02c, ttl=64 > 18:55:12.311585 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), > sport=22, dport=33390, seq=ce934c58, flags: SYN ACK, tos/dscp=0x0/0x0, The first line is the encapsulated SYN/ACK and then when decapsulated, you see the SYN/ACK packet. > 18:55:12.311843 netstack: [3620] (default) Send packet on > Ethernet2/6 (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, > proto=17 (udp), sport=61567, dport=4341, udp_len=68, chksum=0, tos/ > dscp=0x0/0x0, This is the ACK going back LISP encapsulated. What follows is data going back and forth: > 18:55:12.363370 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), > sport=61567, dport=4341, udp_len=88, chksum=0, tos/dscp=0x0/0x0, > ip_len=108, id=f02d, ttl=64 > 18:55:12.363455 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), > sport=22, dport=33390, seq=ce934c59, flags: ACK PUSH, tos/ > dscp=0x0/0x0, > 18:55:12.365107 netstack: [3620] (default) Send packet on > Ethernet2/6 (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, > proto=17 (udp), sport=61567, dport=4341, udp_len=88, chksum=0, tos/ > dscp=0x0/0x0, > 18:55:12.370773 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), > sport=61567, dport=4341, udp_len=592, chksum=0, tos/dscp=0x0/0x0, > ip_len=612, id=f02e, ttl=64 > 18:55:12.370856 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), > sport=22, dport=33390, seq=ce934c6d, flags: ACK, tos/dscp=0x0/0x0, > ip_len=576, id=0e8e, ttl=64 > 18:55:12.371121 netstack: [3620] (default) Send packet on > Ethernet2/6 (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, > proto=17 (udp), sport=61567, dport=4341, udp_len=592, chksum=0, tos/ > dscp=0x0/0x0, > 18:55:12.371380 netstack: [3620] (default) Send packet on > Ethernet2/6 (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, > proto=17 (udp), sport=61567, dport=4341, udp_len=328, chksum=0, tos/ > dscp=0x0/0x0, > 18:55:12.371484 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), > sport=61567, dport=4341, udp_len=280, chksum=0, tos/dscp=0x0/0x0, > ip_len=300, id=f02f, ttl=64 > 18:55:12.371552 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), > sport=22, dport=33390, seq=ce934e79, flags: ACK PUSH, tos/ > dscp=0x0/0x0, > 18:55:12.446838 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), > sport=61567, dport=4341, udp_len=68, chksum=0, tos/dscp=0x0/0x0, > ip_len=88, id=f030, ttl=64 > 18:55:12.446919 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), > sport=22, dport=33390, seq=ce934f4d, flags: ACK, tos/dscp=0x0/0x0, > ip_len=52, id=0e90, ttl=64 > 18:55:12.447168 netstack: [3620] (default) Send packet on > Ethernet2/6 (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, > proto=17 (udp), sport=61567, dport=4341, udp_len=92, chksum=0, tos/ > dscp=0x0/0x0, > 18:55:12.452147 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), > sport=61567, dport=4341, udp_len=220, chksum=0, tos/dscp=0x0/0x0, > ip_len=240, id=f031, ttl=64 > 18:55:12.452217 netstack: [3620] (default) Rcvd packet on > Ethernet2/6 (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), > sport=22, dport=33390, seq=ce934f4d, flags: ACK PUSH, tos/ > dscp=0x0/0x0, > 18:55:12.456347 netstack: [3620] (default) Send packet on > Ethernet2/6 (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, > proto=17 (udp), sport=61567, dport=4341, udp_len=212, chksum=0, tos/ > dscp=0x0/0x0, > 18:55:12.467629 netstack2008 Mar 30 18:55:12.640315 netstack: [3620] > (default) Send packet on Ethernet2/6 (prty 7): s=1.22.23.22, > d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), sport=615The > authenticity of host '240.23.0.23 (240.23.0.23)' can't be established. And here you see visual data: > RSA key fingerprint is 24:cb:8b:1f:8b:d7:a1:3d:a3:59:db:de: > 9b:b6:f7:f1. > Are you sure you want to continue connecting (yes/no)? This only happens for the first connection (if no other packet was sent before) between Site A and Site B. The point here is that TCP RTT estimates are not affected since early retransmission timers are larger than the Map-Request rate-limiting. I know we don't show a Map-Request loss case here but the next Map- Request would have been sent 3 seconds later. If a packet today would get dropped the same thing would happen. The TCP connection would take 3 seconds to come up. But *it's not for every connection* in the LISP case. Dino On Sep 15, 2009, at 10:37 AM, Margaret Wasserman wrote: > > Hi All, > > I have a new question for the group... > > I have some concerns about how LISP will perform when TCP is used > over LISP when there is a lossy link somewhere in the mapping > network and/or the link from the mapping network to the remote ETR. > > I've been mapping out packet flows on my whiteboard, and I have a > scenario that looks like this... > > Assume no existing LISP connections/mapping between site A (served > by xTR A) and site B (served by xTR B). > > A host (Host A with EID A) behind ITR A initiates a TCP connection > to a host (Host B with EID B) behind ETR B. The packet gets > to ITR A, and ITR A sends a map request for EID B to its map > resolver. ITR A also drops the original packet. What happens > if the map request gets lost before it gets to ETR B? > > A very short time passes, and Host A retransmits the . > > The retransmission gets to ITR A, but the LISP spec indicates that > map requests for the same EID should be rate limited to no more than > one per second. So, the retransmission is dropped. This continues > until a second has passed. > > After 1 second, Host A retransmits the again, and it is > dropped by ITR A because there is no mapping. At that point, ITR A > sends another map request for EID B. If this request gets a > response, the Nth retransmission will finally be sent after 1 second > + ~1 round trip of repeated retransmission. > > By this point, Host A has determined that there is significant > congestion between Host A and Host B, when actually only one packet > was lost. Host A will have a large retransmission timeout for Host > B, and its slow-start mechanism will have significantly backed off > due to (apparent) congestion. So, it will take a while for Host A > to begin sending to EID B again at full speed. > > To avoid this scenario, I think we either need to institute some > sort of retransmission for map requests that don't get a reply, or > consider a more sophisticated rate limiting mechanisms than just one > per second. > > Margaret > > P.S. I am also concerned about rate limiting the sending of map > requests per-EID... Are there any cases where you would want to > check the liveness of multiple locators using a map request probe? > Wouldn't this effectively limit you to checking the liveness of one > locator per second? > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From mrw@sandstorm.net Tue Sep 15 19:49: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 75FDE3A67F0 for ; Tue, 15 Sep 2009 19:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=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 1zo-RNicAB7N for ; Tue, 15 Sep 2009 19:49:38 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 93A6A3A685C for ; Tue, 15 Sep 2009 19:49:38 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8G2nCFX074538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Sep 2009 22:49:17 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: 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, 15 Sep 2009 22:49:11 -0400 References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 02:49:39 -0000 On Sep 15, 2009, at 8:58 PM, Dino Farinacci wrote: > Let me show you what happens from this trace. I indented the trace > data and my comments follow. This is an ITR that is ssh'ing to an > ETR when the map-cache for the ETR does not exist. > > Note EIDs are in 240.0.0.0/8 space and locators are in 1.0.0.0/8. > >> dr22(config-if)# ssh 240.23.0.23 >> 18:55:09.290262 netstack: [3620] (default) Send packet on >> Ethernet2/2 (prty 7): s=1.22.23.22, d=1.11.22.11, nh=1.11.22.11, >> proto=17 (udp), sport=65375, dport=4341, udp_len=120, chksum=0, tos/ >> dscp=0xc0/0x30, > > This is the encapsulated Map-Request. Yes, the SYN is dropped. > >> 18:55:09.292337 netstack: [3620] (default) Rcvd packet on >> Ethernet2/6 (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), >> sport=4342, dport=65375, udp_len=60, chksum=c0ce, tos/dscp=0xc0/0x30, > > This is the returning Map-Reply. Notice 2ms RTT because boxes are in > the same rack. This isn't the same case as I was describing. The map request obviously wasn't dropped, as the reply came back. >> 18:55:12.310387 netstack: [3620] (default) Send packet on >> Ethernet2/6 (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, >> proto=17 (udp), sport=61567, dport=4341, udp_len=76, chksum=0, tos/ >> dscp=0x0/0x0, > > This is the retransmitted SYN LISP encapsulated packet. Note the > retransmission timer is 3 seconds. That seems like a long initial TCP retransmission timer. I see the initial retransmission happening in under a second on my system. > > This only happens for the first connection (if no other packet was > sent before) between Site A and Site B. > > The point here is that TCP RTT estimates are not affected since > early retransmission timers are larger than the Map-Request rate- > limiting. The initial RTT estimates on your system seem to be considerably longer than on mine. Is that something you needed to set in order to make TCP work properly with LISP? > > > If a packet today would get dropped the same thing would happen. The > TCP connection would take 3 seconds to come up. But *it's not for > every connection* in the LISP case. I understand that. Margaret From ljakab@ac.upc.edu Wed Sep 16 05:36: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 B34CF3A69D9 for ; Wed, 16 Sep 2009 05:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 P7vxw4Lq-mWG for ; Wed, 16 Sep 2009 05:36:20 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by core3.amsl.com (Postfix) with ESMTP id E320B3A69CC for ; Wed, 16 Sep 2009 05:36:19 -0700 (PDT) Received: from gambus.localnet (gambus.ac.upc.es [147.83.34.118]) by gw.ac.upc.edu (Postfix) with ESMTP id 132026B0260; Wed, 16 Sep 2009 14:37:08 +0200 (CEST) From: =?iso-8859-1?q?Lor=E1nd_Jakab?= Organization: UPC To: lisp@ietf.org Date: Wed, 16 Sep 2009 14:36:59 +0200 User-Agent: KMail/1.12.1 (Linux/2.6.31-gentoo; KDE/4.3.1; i686; ; ) References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1343984.0DGtk9N2Cg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909161437.06949.ljakab@ac.upc.edu> Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 12:36:20 -0000 --nextPart1343984.0DGtk9N2Cg Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dino, On Wednesday, September 16, 2009 02:58:06 Dino Farinacci wrote: > This only happens for the first connection (if no other packet was > sent before) between Site A and Site B. Indeed, but take for example typical web pages today: they have dozens=20 of external references on different domains, with different IP=20 addresses. The first time I load any web page, load time will increase=20 with 3 seconds for each external IP it references, in addition to DNS=20 lookups and download times. Of course this is not really an issue if the ITR is a border router of a=20 busy domain, most popular destinations will be cached. But if we=20 consider the other deployment scenarios discussed recently on list, it=20 may become an issue. Waiting 30+ seconds for each new web page to load=20 is really bad user experience. Regards, Lor=E1nd Jakab --nextPart1343984.0DGtk9N2Cg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkqw2/IACgkQlUwN75BxDXS8ywCgsBYg8EHP95hhI1/GqQEerkhT 8ZEAn3QkkwtGO7g1ZGukfvGeEiFmpHpG =a7fv -----END PGP SIGNATURE----- --nextPart1343984.0DGtk9N2Cg-- From damien.saucez@uclouvain.be Wed Sep 16 05:44: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 8B7163A688D for ; Wed, 16 Sep 2009 05:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.113 X-Spam-Level: X-Spam-Status: No, score=-4.113 tagged_above=-999 required=5 tests=[AWL=-2.114, BAYES_00=-2.599, J_CHICKENPOX_33=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 2AHpLauVXkO0 for ; Wed, 16 Sep 2009 05:44:40 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id EBA693A67A7 for ; Wed, 16 Sep 2009 05:44:39 -0700 (PDT) Received: from [130.104.228.15] (sleipnier-lite.dhcp.info.ucl.ac.be [130.104.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id DE208E8D2B; Wed, 16 Sep 2009 14:45:24 +0200 (CEST) Message-ID: <4AB0DDE3.7090503@uclouvain.be> Date: Wed, 16 Sep 2009 14:45:23 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Dino Farinacci References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: DE208E8D2B.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 12:44:41 -0000 Dino Farinacci wrote: > Let me show you what happens from this trace. I indented the trace > data and my comments follow. This is an ITR that is ssh'ing to an ETR > when the map-cache for the ETR does not exist. > > Note EIDs are in 240.0.0.0/8 space and locators are in 1.0.0.0/8. > >> dr22(config-if)# ssh 240.23.0.23 >> 18:55:09.290262 netstack: [3620] (default) Send packet on Ethernet2/2 >> (prty 7): s=1.22.23.22, d=1.11.22.11, nh=1.11.22.11, proto=17 (udp), >> sport=65375, dport=4341, udp_len=120, chksum=0, tos/dscp=0xc0/0x30, > > This is the encapsulated Map-Request. Yes, the SYN is dropped. > >> 18:55:09.292337 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=4342, >> dport=65375, udp_len=60, chksum=c0ce, tos/dscp=0xc0/0x30, > > This is the returning Map-Reply. Notice 2ms RTT because boxes are in > the same rack. > >> 18:55:12.310387 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=76, chksum=0, tos/dscp=0x0/0x0, > > This is the retransmitted SYN LISP encapsulated packet. Note the > retransmission timer is 3 seconds. > >> 18:55:12.311510 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=61567, >> dport=4341, udp_len=72, chksum=0, tos/dscp=0x0/0x0, ip_len=92, >> id=f02c, ttl=64 >> 18:55:12.311585 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), sport=22, >> dport=33390, seq=ce934c58, flags: SYN ACK, tos/dscp=0x0/0x0, > > The first line is the encapsulated SYN/ACK and then when decapsulated, > you see the SYN/ACK packet. > >> 18:55:12.311843 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=68, chksum=0, tos/dscp=0x0/0x0, > > This is the ACK going back LISP encapsulated. > > What follows is data going back and forth: > >> 18:55:12.363370 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=61567, >> dport=4341, udp_len=88, chksum=0, tos/dscp=0x0/0x0, ip_len=108, >> id=f02d, ttl=64 >> 18:55:12.363455 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), sport=22, >> dport=33390, seq=ce934c59, flags: ACK PUSH, tos/dscp=0x0/0x0, >> 18:55:12.365107 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=88, chksum=0, tos/dscp=0x0/0x0, >> 18:55:12.370773 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=61567, >> dport=4341, udp_len=592, chksum=0, tos/dscp=0x0/0x0, ip_len=612, >> id=f02e, ttl=64 >> 18:55:12.370856 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), sport=22, >> dport=33390, seq=ce934c6d, flags: ACK, tos/dscp=0x0/0x0, ip_len=576, >> id=0e8e, ttl=64 >> 18:55:12.371121 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=592, chksum=0, tos/dscp=0x0/0x0, >> 18:55:12.371380 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=328, chksum=0, tos/dscp=0x0/0x0, >> 18:55:12.371484 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=61567, >> dport=4341, udp_len=280, chksum=0, tos/dscp=0x0/0x0, ip_len=300, >> id=f02f, ttl=64 >> 18:55:12.371552 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), sport=22, >> dport=33390, seq=ce934e79, flags: ACK PUSH, tos/dscp=0x0/0x0, >> 18:55:12.446838 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=61567, >> dport=4341, udp_len=68, chksum=0, tos/dscp=0x0/0x0, ip_len=88, >> id=f030, ttl=64 >> 18:55:12.446919 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), sport=22, >> dport=33390, seq=ce934f4d, flags: ACK, tos/dscp=0x0/0x0, ip_len=52, >> id=0e90, ttl=64 >> 18:55:12.447168 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=92, chksum=0, tos/dscp=0x0/0x0, >> 18:55:12.452147 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=61567, >> dport=4341, udp_len=220, chksum=0, tos/dscp=0x0/0x0, ip_len=240, >> id=f031, ttl=64 >> 18:55:12.452217 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), sport=22, >> dport=33390, seq=ce934f4d, flags: ACK PUSH, tos/dscp=0x0/0x0, >> 18:55:12.456347 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=212, chksum=0, tos/dscp=0x0/0x0, >> 18:55:12.467629 netstack2008 Mar 30 18:55:12.640315 netstack: [3620] >> (default) Send packet on Ethernet2/6 (prty 7): s=1.22.23.22, >> d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), sport=615The >> authenticity of host '240.23.0.23 (240.23.0.23)' can't be established. > > And here you see visual data: > >> RSA key fingerprint is 24:cb:8b:1f:8b:d7:a1:3d:a3:59:db:de:9b:b6:f7:f1. >> Are you sure you want to continue connecting (yes/no)? > > This only happens for the first connection (if no other packet was > sent before) between Site A and Site B. > > The point here is that TCP RTT estimates are not affected since early > retransmission timers are larger than the Map-Request rate-limiting. > > I know we don't show a Map-Request loss case here but the next > Map-Request would have been sent 3 seconds later. > > If a packet today would get dropped the same thing would happen. The > TCP connection would take 3 seconds to come up. But *it's not for > every connection* in the LISP case. > 3 seconds seems to be the best case. Source Destination ---------SYN---------> Dropped -------------Request -->... <-----------Reply---------... ---------SYN --------------------------------------------> Dropped <----------- SYN + ACK----- ... <----------------- Request ------------ ... ---------------------- Reply ------------> ----- SYN ------------------------------------------------> <---------------------------------------------------SYN + ACK ----- The minimum time here is 6 seconds. If the reply needs more than 3 seconds to come, it jump easily to 18 seconds. And a 3+second mapping time could be observed on lossy links. Damien Saucez > Dino > > On Sep 15, 2009, at 10:37 AM, Margaret Wasserman wrote: > >> >> Hi All, >> >> I have a new question for the group... >> >> I have some concerns about how LISP will perform when TCP is used >> over LISP when there is a lossy link somewhere in the mapping network >> and/or the link from the mapping network to the remote ETR. >> >> I've been mapping out packet flows on my whiteboard, and I have a >> scenario that looks like this... >> >> Assume no existing LISP connections/mapping between site A (served by >> xTR A) and site B (served by xTR B). >> >> A host (Host A with EID A) behind ITR A initiates a TCP connection to >> a host (Host B with EID B) behind ETR B. The packet gets to >> ITR A, and ITR A sends a map request for EID B to its map resolver. >> ITR A also drops the original packet. What happens if the map >> request gets lost before it gets to ETR B? >> >> A very short time passes, and Host A retransmits the . >> >> The retransmission gets to ITR A, but the LISP spec indicates that >> map requests for the same EID should be rate limited to no more than >> one per second. So, the retransmission is dropped. This continues >> until a second has passed. >> >> After 1 second, Host A retransmits the again, and it is dropped >> by ITR A because there is no mapping. At that point, ITR A sends >> another map request for EID B. If this request gets a response, the >> Nth retransmission will finally be sent after 1 second + ~1 round >> trip of repeated retransmission. >> >> By this point, Host A has determined that there is significant >> congestion between Host A and Host B, when actually only one packet >> was lost. Host A will have a large retransmission timeout for Host >> B, and its slow-start mechanism will have significantly backed off >> due to (apparent) congestion. So, it will take a while for Host A to >> begin sending to EID B again at full speed. >> >> To avoid this scenario, I think we either need to institute some sort >> of retransmission for map requests that don't get a reply, or >> consider a more sophisticated rate limiting mechanisms than just one >> per second. >> >> Margaret >> >> P.S. I am also concerned about rate limiting the sending of map >> requests per-EID... Are there any cases where you would want to >> check the liveness of multiple locators using a map request probe? >> Wouldn't this effectively limit you to checking the liveness of one >> locator per second? >> >> >> >> _______________________________________________ >> 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 tme@americafree.tv Wed Sep 16 06:09: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 9FB5D3A6A02 for ; Wed, 16 Sep 2009 06:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=-0.160, 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 cUHdP8PIFfit for ; Wed, 16 Sep 2009 06:09:23 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id D58E83A677E for ; Wed, 16 Sep 2009 06:09:22 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 511984BD2942; Wed, 16 Sep 2009 09:10:11 -0400 (EDT) Message-Id: From: Marshall Eubanks To: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= In-Reply-To: <200909161437.06949.ljakab@ac.upc.edu> 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: Wed, 16 Sep 2009 09:10:10 -0400 References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> <200909161437.06949.ljakab@ac.upc.edu> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 13:09:23 -0000 On Sep 16, 2009, at 8:36 AM, Lor=E1nd Jakab wrote: > Hi Dino, > > On Wednesday, September 16, 2009 02:58:06 Dino Farinacci wrote: >> This only happens for the first connection (if no other packet was >> sent before) between Site A and Site B. > > Indeed, but take for example typical web pages today: they have dozens > of external references on different domains, with different IP > addresses. The first time I load any web page, load time will increase > with 3 seconds for each external IP it references, in addition to DNS > lookups and download times. I absolutely agree. Some major sites (such as news aggregation sites) =20= have literally hundreds of pieces of other people's content to download. As of right now Google News - http://news.google.com/news?ned=3D - 37 files (mostly = non-=20 Google images) Washington Post http://www.washingtonpost.com/ - 133 files (who knows, =20= but at least some are external) Maybe LISP would change the way that people construct web sites, but I =20= wouldn't count on it. > > Of course this is not really an issue if the ITR is a border router =20= > of a > busy domain, most popular destinations will be cached. But if we > consider the other deployment scenarios discussed recently on list, it > may become an issue. Waiting 30+ seconds for each new web page to load > is really bad user experience. It seems to me that this would make LISP caching into a good business =20= model for a CDN, but it would not find favor otherwise. Regards Marshall > > Regards, > Lor=E1nd Jakab > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ljakab@ac.upc.edu Wed Sep 16 07:08: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 6981C3A6A2B for ; Wed, 16 Sep 2009 07:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.149, 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 IRlXUpKAW5wk for ; Wed, 16 Sep 2009 07:08:57 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by core3.amsl.com (Postfix) with ESMTP id 5307E3A6A2F for ; Wed, 16 Sep 2009 07:08:56 -0700 (PDT) Received: from gambus.localnet (gambus.ac.upc.es [147.83.34.118]) by gw.ac.upc.edu (Postfix) with ESMTP id 0FAFE6B0259; Wed, 16 Sep 2009 16:09:45 +0200 (CEST) From: =?iso-8859-1?q?Lor=E1nd_Jakab?= Organization: UPC To: lisp@ietf.org Date: Wed, 16 Sep 2009 16:09:37 +0200 User-Agent: KMail/1.12.1 (Linux/2.6.31-gentoo; KDE/4.3.1; i686; ; ) References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4108106.HVhlkWOGhp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909161609.44539.ljakab@ac.upc.edu> Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 14:08:58 -0000 --nextPart4108106.HVhlkWOGhp Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Margaret, On Wednesday, September 16, 2009 04:49:11 Margaret Wasserman wrote: > > This is the retransmitted SYN LISP encapsulated packet. Note the > > retransmission timer is 3 seconds. >=20 > That seems like a long initial TCP retransmission timer. I see the > initial retransmission happening in under a second on my system. RFC1122 recommends (with SHOULD) a 3 second initial RTO. This is the=20 default on most current operating systems. There is a presentation from=20 Stockholm by a Googler, advocating for a 1 second initial RTO here: http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf According to they survey only Mac OS X has a 1 second initial RTO, the=20 rest use 3 (or 3.38 in the case of Solaris). I have checked, and it is possible to change this value in Windows by=20 modifying the registry. I couldn't find the appropriate sysctl on Linux=20 and right now I have no access to a FreeBSD machine, but I suppose it is=20 also possible to do it. > > This only happens for the first connection (if no other packet was > > sent before) between Site A and Site B. > > > > The point here is that TCP RTT estimates are not affected since > > early retransmission timers are larger than the Map-Request rate- > > limiting. >=20 > The initial RTT estimates on your system seem to be considerably > longer than on mine. Is that something you needed to set in order to > make TCP work properly with LISP? Actually, LISP would benefit from a _lower_ initial RTO, just like=20 Google is advocating for. Lor=E1nd Jakab --nextPart4108106.HVhlkWOGhp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkqw8agACgkQlUwN75BxDXRqUgCfQeaOYEsl6rIYu7XvsAtREt5D gmwAoOBHUkquM/X9vRZ+3UCi4EMaCCgw =8jXd -----END PGP SIGNATURE----- --nextPart4108106.HVhlkWOGhp-- From lear@cisco.com Wed Sep 16 07:31: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 65D6D3A68AE for ; Wed, 16 Sep 2009 07:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vwv2SQ7F8tli for ; Wed, 16 Sep 2009 07:31:41 -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 BAC4C3A6895 for ; Wed, 16 Sep 2009 07:31:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncAAL+TsEqQ/uCKe2dsb2JhbACBU1MwmEYBARYkBqpgiEwBkFAFhBc X-IronPort-AV: E=Sophos;i="4.44,397,1249257600"; d="scan'208,217";a="49516702" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Sep 2009 14:32:29 +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 n8GEWTHK016844; Wed, 16 Sep 2009 16:32:29 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp6693.cisco.com [10.61.90.36]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8GEWSsN029303; Wed, 16 Sep 2009 14:32:28 GMT Message-ID: <4AB0F6FC.8020609@cisco.com> Date: Wed, 16 Sep 2009 16:32: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: Marshall Eubanks References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> <200909161437.06949.ljakab@ac.upc.edu> In-Reply-To: X-Enigmail-Version: 0.97a Content-Type: multipart/alternative; boundary="------------050802040501030605060804" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7296; t=1253111549; x=1253975549; 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]=20LISP=20Over=20Lossy=20Links |Sender:=20; bh=qSmjg3F7GikpnyF/8C+4niMcTa0792+1bYPlwQdi1H0=; b=jXUSamASg4x0FOXImIMZBp4CVBLL74xicDYu5pcIKtfK+fFKb2qz5qx1tF ye0rSSs+bJ3X/xYOORRx6os9lCEMeTcJWSoA7VI5P5vqnbhQHnGD93DzyWS2 qgfd1FpLp6; 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] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 14:31:42 -0000 This is a multi-part message in MIME format. --------------050802040501030605060804 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Marshall, Loránd, Indeed there are worst case scenarios that could make things seem "bad". However, these are likely to not be all that common. There is a whole lot of shared infrastructure out there that means that you'll already have the lookup cached from one web site to another. Also, there are ample methods to mitigate such scenarios. Here are just a few possibilities: * Carry the first packet over the ALT backbone. There are challenges with handling bearer traffic. * Have a slightly more robust mapping timer that doesn't simply discard expired entries, but holds them in reserve. * Combine the above with an LRU very large secondary cache. This would give you performance approximating today, assuming the mapping entries don't actually change. * Pre-cache popular sites. I'm sure there other possibilities. These are just a few. Eliot On 9/16/09 3:10 PM, Marshall Eubanks wrote: > > On Sep 16, 2009, at 8:36 AM, Loránd Jakab wrote: > >> Hi Dino, >> >> On Wednesday, September 16, 2009 02:58:06 Dino Farinacci wrote: >>> This only happens for the first connection (if no other packet was >>> sent before) between Site A and Site B. >> >> Indeed, but take for example typical web pages today: they have dozens >> of external references on different domains, with different IP >> addresses. The first time I load any web page, load time will increase >> with 3 seconds for each external IP it references, in addition to DNS >> lookups and download times. > > I absolutely agree. Some major sites (such as news aggregation sites) > have literally hundreds of pieces of > other people's content to download. As of right now > > Google News - http://news.google.com/news?ned= - 37 files (mostly > non-Google images) > Washington Post http://www.washingtonpost.com/ - 133 files (who knows, > but at least some are external) > > Maybe LISP would change the way that people construct web sites, but I > wouldn't count on it. > > >> >> Of course this is not really an issue if the ITR is a border router of a >> busy domain, most popular destinations will be cached. But if we >> consider the other deployment scenarios discussed recently on list, it >> may become an issue. Waiting 30+ seconds for each new web page to load >> is really bad user experience. > > It seems to me that this would make LISP caching into a good business > model for a CDN, but it would not find > favor otherwise. > > Regards > Marshall > >> >> Regards, >> Loránd Jakab >> _______________________________________________ >> 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 > --------------050802040501030605060804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Marshall, Loránd,

Indeed there are worst case scenarios that could make things seem "bad".  However, these are likely to not be all that common.  There is a whole lot of shared infrastructure out there that means that you'll already have the lookup cached from one web site to another.  Also, there are ample methods to mitigate such scenarios.
Here are just a few possibilities:
  • Carry the first packet over the ALT backbone.  There are challenges with handling bearer traffic.
  • Have a slightly more robust mapping timer that doesn't simply discard expired entries, but holds them in reserve.
  • Combine the above with an LRU very large secondary cache.  This would give you performance approximating today, assuming the mapping entries don't actually change.
  • Pre-cache popular sites.
I'm sure there other possibilities.  These are just a few.

Eliot

On 9/16/09 3:10 PM, Marshall Eubanks wrote:

On Sep 16, 2009, at 8:36 AM, Loránd Jakab wrote:

Hi Dino,

On Wednesday, September 16, 2009 02:58:06 Dino Farinacci wrote:
This only happens for the first connection (if no other packet was
sent before) between Site A and Site B.

Indeed, but take for example typical web pages today: they have dozens
of external references on different domains, with different IP
addresses. The first time I load any web page, load time will increase
with 3 seconds for each external IP it references, in addition to DNS
lookups and download times.

I absolutely agree. Some major sites (such as news aggregation sites) have literally hundreds of pieces of
other people's content to download. As of right now

Google News - http://news.google.com/news?ned= -  37 files (mostly non-Google images)
Washington Post http://www.washingtonpost.com/ - 133 files (who knows, but at least some are external)

Maybe LISP would change the way that people construct web sites, but I wouldn't count on it.



Of course this is not really an issue if the ITR is a border router of a
busy domain, most popular destinations will be cached. But if we
consider the other deployment scenarios discussed recently on list, it
may become an issue. Waiting 30+ seconds for each new web page to load
is really bad user experience.

It seems to me that this would make LISP caching into a good business model for a CDN, but it would not find
favor otherwise.

Regards
Marshall


Regards,
Loránd Jakab
_______________________________________________
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


--------------050802040501030605060804-- From jnc@mercury.lcs.mit.edu Wed Sep 16 07:52: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 4E4EA3A6959 for ; Wed, 16 Sep 2009 07:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 EsJAMt2q0aiA for ; Wed, 16 Sep 2009 07:52:10 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 764273A69A7 for ; Wed, 16 Sep 2009 07:52:10 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 19CA16BE5D7; Wed, 16 Sep 2009 10:52:59 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090916145259.19CA16BE5D7@mercury.lcs.mit.edu> Date: Wed, 16 Sep 2009 10:52:59 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 14:52:11 -0000 > From: =?iso-8859-1?q?Lor=E1nd_Jakab?= > The first time I load any web page, load time will increase with 3 > seconds for each external IP it references, in addition to DNS > lookups and download times. > Of course this is not really an issue if the ITR is a border router > of a busy domain, most popular destinations will be cached. Exactly. Also, the mapping system in use for this experimental phase (i.e. the ALT mapping system) was adopted in large part because it re-used lots of existing stuff (e.g. BGP and GRE tunnels), minimizing the amount of new code that had to be written before the experiment could get off the ground. We did design another mapping system, CONS, which had extensive caching, etc to speed up finding mappings (i.e. to reduce the resolution time to less than the RTT to the location of the destination's authoritative mapping, on average), but it has been temporarily put to the side in order to get the experiment running. I expect the decision on what to do with CONS, eventually, will depend on the outcome of the experiment: maybe it will be adopted for other reasons (e.g. traffic loads in the mapping system), but later rather than sooner; maybe we will do something else; who knows? It will depend on what we find out with the experimental deployment. > But if we consider the other deployment scenarios discussed recently > on list, it may become an issue. Exactly - which is why it is important to have an experiment, to see what actually happens. There is a small LISP testbed at the moment, divided into alpha- and beta-test groups, but it will be necessary to to run a more extensive system, with a good amount of actual traffic on it, to see how well it actually works for actual real usage. Noel From mrw@sandstorm.net Wed Sep 16 07:58: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 54EAD3A6AD9 for ; Wed, 16 Sep 2009 07:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, 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 ao-El-y021uu for ; Wed, 16 Sep 2009 07:58:01 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id E97163A69CD for ; Wed, 16 Sep 2009 07:58:00 -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 n8GEwh3b010901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Sep 2009 10:58:43 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <6573A4E1-8A08-4599-A0D0-E715D92540F4@sandstorm.net> From: Margaret Wasserman To: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= In-Reply-To: <200909161609.44539.ljakab@ac.upc.edu> 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: Wed, 16 Sep 2009 10:58:43 -0400 References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> <200909161609.44539.ljakab@ac.upc.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 14:58:02 -0000 Hi Lor=E1nd, On Sep 16, 2009, at 10:09 AM, Lor=E1nd Jakab wrote: > > According to they survey only Mac OS X has a 1 second initial RTO, the > rest use 3 (or 3.38 in the case of Solaris). Thanks for the information. I am using a Mac, which (in my testing, =20 ftp'ing to a non-existing host) retransmitted in just over 900ms the =20 first time, followed by subsequent 1 second retransmissions until the =20= application layer timed out. So, on the Mac, I'd normally see a 1 second delay in establishing =20 every TCP connection (initial packet dropped for map request, first =20 retransmission acknowedged). However, on most systems we'd see a 3 second delay, even when no =20 packets are lost at all. Do you think we should suggest that LISP routers queue packets with no =20= map cache hit, and send them when the map response is received? At =20 least then we'd only introduce a single RTT of delay for session =20 establishment, instead of 3 seconds per connection. Dino indicated that this delay would only happen for the first packet =20= of a connection where there is no map cache entry, but won't there be =20= a packet drop and retransmission for existing connections whenever the =20= LISP mapping TTL expires? Or are we expecting implementations to =20 renew LISP mappings more frequently than that? Margaret From jmh@joelhalpern.com Wed Sep 16 08: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 4BFB428C148 for ; Wed, 16 Sep 2009 08:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 WxEoD79yBvMw for ; Wed, 16 Sep 2009 08:02: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 8FAF13A677C for ; Wed, 16 Sep 2009 08:02:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 50AE743045F; Wed, 16 Sep 2009 08:02:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 8AAFF4303ED; Wed, 16 Sep 2009 08:02:49 -0700 (PDT) Message-ID: <4AB0FE18.1010705@joelhalpern.com> Date: Wed, 16 Sep 2009 11:02:48 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Margaret Wasserman References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> <200909161609.44539.ljakab@ac.upc.edu> <6573A4E1-8A08-4599-A0D0-E715D92540F4@sandstorm.net> In-Reply-To: <6573A4E1-8A08-4599-A0D0-E715D92540F4@sandstorm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp@ietf.org Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 15:02:01 -0000 I had always assumed that if there is a cache entry, and it is being used, that the ITR would refresh the cache entry before it expires. (I see no reason to standardize exactly when.) Yours, Joel Margaret Wasserman wrote: > > Hi Loránd, > > On Sep 16, 2009, at 10:09 AM, Loránd Jakab wrote: >> >> According to they survey only Mac OS X has a 1 second initial RTO, the >> rest use 3 (or 3.38 in the case of Solaris). > > Thanks for the information. I am using a Mac, which (in my testing, > ftp'ing to a non-existing host) retransmitted in just over 900ms the > first time, followed by subsequent 1 second retransmissions until the > application layer timed out. > > So, on the Mac, I'd normally see a 1 second delay in establishing every > TCP connection (initial packet dropped for map request, first > retransmission acknowedged). > > However, on most systems we'd see a 3 second delay, even when no packets > are lost at all. > > Do you think we should suggest that LISP routers queue packets with no > map cache hit, and send them when the map response is received? At > least then we'd only introduce a single RTT of delay for session > establishment, instead of 3 seconds per connection. > > Dino indicated that this delay would only happen for the first packet of > a connection where there is no map cache entry, but won't there be a > packet drop and retransmission for existing connections whenever the > LISP mapping TTL expires? Or are we expecting implementations to renew > LISP mappings more frequently than that? > > Margaret > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From mrw@sandstorm.net Wed Sep 16 08:04: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 8F3203A693F for ; Wed, 16 Sep 2009 08:04:35 -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 BvwLvQy589m2 for ; Wed, 16 Sep 2009 08:04:34 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 9B9923A69CF for ; Wed, 16 Sep 2009 08:04:34 -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 n8GF3f0W011294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Sep 2009 11:03:41 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <3B14BEEE-5088-4F35-B34E-7C219A2E3737@sandstorm.net> From: Margaret Wasserman To: Eliot Lear In-Reply-To: <4AB0F6FC.8020609@cisco.com> 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: Wed, 16 Sep 2009 11:03:41 -0400 References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> <200909161437.06949.ljakab@ac.upc.edu> <4AB0F6FC.8020609@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 15:04:35 -0000 Hi Elliot, On Sep 16, 2009, at 10:32 AM, Eliot Lear wrote: > Indeed there are worst case scenarios that could make things seem =20 > "bad". However, these are likely to not be all that common. There =20= > is a whole lot of shared infrastructure out there that means that =20 > you'll already have the lookup cached from one web site to another. It's actually pretty common that a lot of people get up (or get into =20 work) around the same time and start loading websites that haven't =20 been loaded for hours. In our network, at least, you see a lot of DNS =20= traffic at that time, as the DNS caches have timed out over night. > Also, there are ample methods to mitigate such scenarios. > Here are just a few possibilities: > =95 Carry the first packet over the ALT backbone. There are =20 > challenges with handling bearer traffic. Wouldn't this cause the same sorts of problems that folks are trying =20 to avoid by making sure that all of the packets from a given flow are =20= load-balanced across the same path? > > =95 Have a slightly more robust mapping timer that doesn't = simply =20 > discard expired entries, but holds them in reserve. I think that this is a better, and simpler, choice than above. > =95 Combine the above with an LRU very large secondary cache. = This =20 > would give you performance approximating today, assuming the mapping =20= > entries don't actually change. It doesn't matter how large the cache is if the map cache entries time =20= out when the network is quiet. > =95 Pre-cache popular sites. I _suppose_ this could work, although which sites are popular seems to =20= change rather rapidly. Margaret From lear@cisco.com Wed Sep 16 08: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 43C343A684B for ; Wed, 16 Sep 2009 08:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.235 X-Spam-Level: X-Spam-Status: No, score=-10.235 tagged_above=-999 required=5 tests=[AWL=0.364, 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 yoY1dvfmSLXo for ; Wed, 16 Sep 2009 08:11:36 -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 CD8153A6879 for ; Wed, 16 Sep 2009 08:11:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQAAB+dsEqQ/uCKe2dsb2JhbACBU5lJAQEWJAarQohMAZBUBYIygWU X-IronPort-AV: E=Sophos;i="4.44,398,1249257600"; d="scan'208";a="49522171" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Sep 2009 15:12:23 +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 n8GFCNId030361; Wed, 16 Sep 2009 17:12:23 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp6693.cisco.com [10.61.90.36]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8GFCMm5014397; Wed, 16 Sep 2009 15:12:23 GMT Message-ID: <4AB10056.60100@cisco.com> Date: Wed, 16 Sep 2009 17:12:22 +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: Margaret Wasserman References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> <200909161437.06949.ljakab@ac.upc.edu> <4AB0F6FC.8020609@cisco.com> <3B14BEEE-5088-4F35-B34E-7C219A2E3737@sandstorm.net> In-Reply-To: <3B14BEEE-5088-4F35-B34E-7C219A2E3737@sandstorm.net> X-Enigmail-Version: 0.97a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2496; t=1253113943; x=1253977943; 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]=20LISP=20Over=20Lossy=20Links |Sender:=20; bh=f5JafN8XWODb7sSJBg9p2dHCbY79DNCCOo5B3eb4UNI=; b=UIPiBqL44906wpu+BVIVLSrDvyBqOJu1qiaLjlJBU5zT02hODcXpeLASwc Rv29dg4mVVi5SH3blSujKiQVlopV5AMMJoxK4AUKFujEk3dKbQB1u2ievCny nfIiD3JaP2; 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] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 15:11:37 -0000 Hey Margaret, > > On Sep 16, 2009, at 10:32 AM, Eliot Lear wrote: >> Indeed there are worst case scenarios that could make things seem >> "bad". However, these are likely to not be all that common. There >> is a whole lot of shared infrastructure out there that means that >> you'll already have the lookup cached from one web site to another. > > It's actually pretty common that a lot of people get up (or get into > work) around the same time and start loading websites that haven't > been loaded for hours. In our network, at least, you see a lot of DNS > traffic at that time, as the DNS caches have timed out over night. That's right, and so one area of research I think would be useful would be to look at caching strategy. I suspect there is a whole lot of existing work from which one could borrow in the area of file systems, by the way. > >> Also, there are ample methods to mitigate such scenarios. >> Here are just a few possibilities: >> • Carry the first packet over the ALT backbone. There are >> challenges with handling bearer traffic. > > Wouldn't this cause the same sorts of problems that folks are trying > to avoid by making sure that all of the packets from a given flow are > load-balanced across the same path? It really depends on how many packets ACTUALLY traverse the ALT. But it would seem safe to say that the path behavior would shift as the map reply is answered. >> >> • Have a slightly more robust mapping timer that doesn't simply >> discard expired entries, but holds them in reserve. > > I think that this is a better, and simpler, choice than above. > >> • Combine the above with an LRU very large secondary cache. This >> would give you performance approximating today, assuming the mapping >> entries don't actually change. > > It doesn't matter how large the cache is if the map cache entries time > out when the network is quiet. Right -- again, I would suggest this as an area for research, but what I would try is literally storing old entries on disk and using them for data until you have a better route. This will fall back to what is currently discussed today, but it would make the worst case all the more rare. > >> • Pre-cache popular sites. > > I _suppose_ this could work, although which sites are popular seems to > change rather rapidly. Right- you could even envision pre-caching services, based on observed popularity in the core. Eliot From jnc@mercury.lcs.mit.edu Wed Sep 16 08:13: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 504903A684B for ; Wed, 16 Sep 2009 08:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 O-1ppfwsRR3S for ; Wed, 16 Sep 2009 08:13:38 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 7072D3A6A1F for ; Wed, 16 Sep 2009 08:13:35 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 966C36BE5D8; Wed, 16 Sep 2009 11:14:24 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090916151424.966C36BE5D8@mercury.lcs.mit.edu> Date: Wed, 16 Sep 2009 11:14:24 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 15:13:39 -0000 > From: Margaret Wasserman > Do you think we should suggest that LISP routers queue packets with > no map cache hit, and send them when the map response is received? Holding packets like that is a real no-no in a router. (Routers do not, for instance, generally even hold packets waiting for an ARP reply, and that's a lot shorter RTT.) If we discover that there's a problem, we would probably want to look at other ways of solving it (e.g. sending packets through the resolution hierarchy) rather than holding packets. But let's see how things actually work in practise, before we add a 'fix'? In theory, ARP and DNS could cause problems too, but in practise they work fine. (Heck, in theory old Ethernet - the non-hub kind - doesn't work well under heavy loads... but in practise it worked just fine.) It's one thing to pro-actively fix something that could lead to a real problem, something else to fix something that _might_ be a performance issue - before we know if there _is_ a performance issue. Noel From jnc@mercury.lcs.mit.edu Wed Sep 16 08:24: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 054633A68AA for ; Wed, 16 Sep 2009 08:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 RxSbWp2Rkeha for ; Wed, 16 Sep 2009 08:24: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 E5B883A69B1 for ; Wed, 16 Sep 2009 08:23:44 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A97136BE5DA; Wed, 16 Sep 2009 11:24:33 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090916152433.A97136BE5DA@mercury.lcs.mit.edu> Date: Wed, 16 Sep 2009 11:24:33 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 15:24:06 -0000 > From: Margaret Wasserman >> Have a slightly more robust mapping timer that doesn't simply >> discard expired entries, but holds them in reserve. > I think that this is a better, and simpler, choice than above. It also doesn't require any protocol changes; it can be added in a machine-by-machine way. So it's trvial to add to the spec/deploy. Marking expired entries as 'provisional' (i.e. you keep using them while you start a refresh) would be an obvious thing to do if we discover issues in actual service. >> Pre-cache popular sites. > I _suppose_ this could work, although which sites are popular seems > to change rather rapidly. CONS had a very elegant (i.e. simple, cheap _and_ effective :-) algorithm for automatically 'floating' commonly-used entries back through the mesh, closer to the entities asking for the mappings; I devised it (at no little cost in brain-sweat :-) precisely to avoid the problem you allude to! :-) Depending on exactly where we go with the mapping system, we could I am sure do something along these lines. Noel From damien.saucez@uclouvain.be Wed Sep 16 08:24: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 DD4993A69C8 for ; Wed, 16 Sep 2009 08:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.761 X-Spam-Level: X-Spam-Status: No, score=-3.761 tagged_above=-999 required=5 tests=[AWL=-1.762, BAYES_00=-2.599, J_CHICKENPOX_33=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 PaiNFyfhC84Y for ; Wed, 16 Sep 2009 08:24:16 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id C0EDC3A6452 for ; Wed, 16 Sep 2009 08:24:15 -0700 (PDT) Received: from [130.104.228.15] (sleipnier-lite.dhcp.info.ucl.ac.be [130.104.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id F10251C5CEA; Wed, 16 Sep 2009 17:24:40 +0200 (CEST) Message-ID: <4AB1033A.2010207@uclouvain.be> Date: Wed, 16 Sep 2009 17:24:42 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Margaret Wasserman References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> <200909161609.44539.ljakab@ac.upc.edu> <6573A4E1-8A08-4599-A0D0-E715D92540F4@sandstorm.net> In-Reply-To: <6573A4E1-8A08-4599-A0D0-E715D92540F4@sandstorm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: F10251C5CEA.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 15:24:18 -0000 Margaret, Margaret Wasserman wrote: > > Hi Loránd, > > On Sep 16, 2009, at 10:09 AM, Loránd Jakab wrote: >> >> According to they survey only Mac OS X has a 1 second initial RTO, the >> rest use 3 (or 3.38 in the case of Solaris). > > Thanks for the information. I am using a Mac, which (in my testing, > ftp'ing to a non-existing host) retransmitted in just over 900ms the > first time, followed by subsequent 1 second retransmissions until the > application layer timed out. > > So, on the Mac, I'd normally see a 1 second delay in establishing > every TCP connection (initial packet dropped for map request, first > retransmission acknowedged). > > However, on most systems we'd see a 3 second delay, even when no > packets are lost at all. > > Do you think we should suggest that LISP routers queue packets with no > map cache hit, and send them when the map response is received? At > least then we'd only introduce a single RTT of delay for session > establishment, instead of 3 seconds per connection. Loránd has presented that approach in Stockholm. Whatever the speed of the link, you can do buffering, when the buffer is full, just drop new packets in miss and thus have the same behavior for these packets than without buffering. Regards, Damien Saucez > > Dino indicated that this delay would only happen for the first packet > of a connection where there is no map cache entry, but won't there be > a packet drop and retransmission for existing connections whenever the > LISP mapping TTL expires? Or are we expecting implementations to > renew LISP mappings more frequently than that? > > Margaret > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From mrw@sandstorm.net Wed Sep 16 08:40: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 9EDC63A69B1 for ; Wed, 16 Sep 2009 08:40:32 -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 1XPZWf7cjjTh for ; Wed, 16 Sep 2009 08:40:31 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id A37713A6452 for ; Wed, 16 Sep 2009 08:40: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 n8GFfHsm013125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Sep 2009 11:41:17 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090916151424.966C36BE5D8@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, 16 Sep 2009 11:41:17 -0400 References: <20090916151424.966C36BE5D8@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 15:40:32 -0000 On Sep 16, 2009, at 11:14 AM, Noel Chiappa wrote: >> From: Margaret Wasserman > >> Do you think we should suggest that LISP routers queue packets with >> no map cache hit, and send them when the map response is received? > > Holding packets like that is a real no-no in a router. (Routers do > not, for > instance, generally even hold packets waiting for an ARP reply, and > that's a > lot shorter RTT.) Are you sure that routers don't queue packets waiting for an ARP reply? It's my understanding that routers _do_ queue packets when they send an ARP request,, and that those packets are transmitted when a matching ARP response is received. IP stacks that I've worked on have had small packet queues associated with each outstanding ARP request for this purpose. It is also suggested by RFC 1812 (Router Requirements), which says: "The link layer MUST NOT report a Destination Unreachable error to IP solely because there is no ARP cache entry for a destination; it SHOULD queue up to a small number of datagrams breifly while performing the ARP request/reply sequence, and reply that the destination is unreachable to one of the queued datagrams only when this proves fruitless." Margaret From florin.coras@net.utcluj.ro Wed Sep 16 08:42: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 B1C0728C17B for ; Wed, 16 Sep 2009 08:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.14 X-Spam-Level: X-Spam-Status: No, score=0.14 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RO=1.235, HOST_EQ_RO=0.904, J_CHICKENPOX_33=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 dbqFiKIUxzIs for ; Wed, 16 Sep 2009 08:42:42 -0700 (PDT) Received: from bavaria.utcluj.ro (bavaria.utcluj.ro [193.226.5.35]) by core3.amsl.com (Postfix) with ESMTP id 93D7028C179 for ; Wed, 16 Sep 2009 08:42:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id B6F61B242F; Wed, 16 Sep 2009 18:43:15 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on local.mail.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7xBojL3GhPl; Wed, 16 Sep 2009 18:43:09 +0300 (EEST) Received: from [192.168.1.100] (unknown [78.97.165.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: florincoras) by bavaria.utcluj.ro (Postfix) with ESMTPSA id B62D4B2420; Wed, 16 Sep 2009 18:43:09 +0300 (EEST) Message-ID: <4AB10787.2060801@net.utcluj.ro> Date: Wed, 16 Sep 2009 18:43:03 +0300 From: Florin Coras User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Dino Farinacci References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 15:42:47 -0000 Hi Dino, Dino Farinacci wrote: > Let me show you what happens from this trace. I indented the trace data > and my comments follow. This is an ITR that is ssh'ing to an ETR when > the map-cache for the ETR does not exist. > > Note EIDs are in 240.0.0.0/8 space and locators are in 1.0.0.0/8. > >> dr22(config-if)# ssh 240.23.0.23 >> 18:55:09.290262 netstack: [3620] (default) Send packet on Ethernet2/2 >> (prty 7): s=1.22.23.22, d=1.11.22.11, nh=1.11.22.11, proto=17 (udp), >> sport=65375, dport=4341, udp_len=120, chksum=0, tos/dscp=0xc0/0x30, > > This is the encapsulated Map-Request. Yes, the SYN is dropped. > >> 18:55:09.292337 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=4342, >> dport=65375, udp_len=60, chksum=c0ce, tos/dscp=0xc0/0x30, > > This is the returning Map-Reply. Notice 2ms RTT because boxes are in the > same rack. > >> 18:55:12.310387 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=76, chksum=0, tos/dscp=0x0/0x0, > > This is the retransmitted SYN LISP encapsulated packet. Note the > retransmission timer is 3 seconds. > >> 18:55:12.311510 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=61567, >> dport=4341, udp_len=72, chksum=0, tos/dscp=0x0/0x0, ip_len=92, >> id=f02c, ttl=64 >> 18:55:12.311585 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), sport=22, >> dport=33390, seq=ce934c58, flags: SYN ACK, tos/dscp=0x0/0x0, > > The first line is the encapsulated SYN/ACK and then when decapsulated, > you see the SYN/ACK packet. > >> 18:55:12.311843 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=68, chksum=0, tos/dscp=0x0/0x0, > > This is the ACK going back LISP encapsulated. > > What follows is data going back and forth: > >> 18:55:12.363370 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=61567, >> dport=4341, udp_len=88, chksum=0, tos/dscp=0x0/0x0, ip_len=108, >> id=f02d, ttl=64 >> 18:55:12.363455 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), sport=22, >> dport=33390, seq=ce934c59, flags: ACK PUSH, tos/dscp=0x0/0x0, >> 18:55:12.365107 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=88, chksum=0, tos/dscp=0x0/0x0, >> 18:55:12.370773 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=61567, >> dport=4341, udp_len=592, chksum=0, tos/dscp=0x0/0x0, ip_len=612, >> id=f02e, ttl=64 >> 18:55:12.370856 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), sport=22, >> dport=33390, seq=ce934c6d, flags: ACK, tos/dscp=0x0/0x0, ip_len=576, >> id=0e8e, ttl=64 >> 18:55:12.371121 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=592, chksum=0, tos/dscp=0x0/0x0, >> 18:55:12.371380 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=328, chksum=0, tos/dscp=0x0/0x0, >> 18:55:12.371484 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=61567, >> dport=4341, udp_len=280, chksum=0, tos/dscp=0x0/0x0, ip_len=300, >> id=f02f, ttl=64 >> 18:55:12.371552 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), sport=22, >> dport=33390, seq=ce934e79, flags: ACK PUSH, tos/dscp=0x0/0x0, >> 18:55:12.446838 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=61567, >> dport=4341, udp_len=68, chksum=0, tos/dscp=0x0/0x0, ip_len=88, >> id=f030, ttl=64 >> 18:55:12.446919 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), sport=22, >> dport=33390, seq=ce934f4d, flags: ACK, tos/dscp=0x0/0x0, ip_len=52, >> id=0e90, ttl=64 >> 18:55:12.447168 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=92, chksum=0, tos/dscp=0x0/0x0, >> 18:55:12.452147 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=1.22.23.23, d=1.22.23.22, proto=17 (udp), sport=61567, >> dport=4341, udp_len=220, chksum=0, tos/dscp=0x0/0x0, ip_len=240, >> id=f031, ttl=64 >> 18:55:12.452217 netstack: [3620] (default) Rcvd packet on Ethernet2/6 >> (prty 7): s=240.23.0.23, d=240.22.0.22, proto=6 (tcp), sport=22, >> dport=33390, seq=ce934f4d, flags: ACK PUSH, tos/dscp=0x0/0x0, >> 18:55:12.456347 netstack: [3620] (default) Send packet on Ethernet2/6 >> (prty 7): s=1.22.23.22, d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), >> sport=61567, dport=4341, udp_len=212, chksum=0, tos/dscp=0x0/0x0, >> 18:55:12.467629 netstack2008 Mar 30 18:55:12.640315 netstack: [3620] >> (default) Send packet on Ethernet2/6 (prty 7): s=1.22.23.22, >> d=1.22.23.23, nh=1.22.23.23, proto=17 (udp), sport=615The authenticity >> of host '240.23.0.23 (240.23.0.23)' can't be established. > > And here you see visual data: > >> RSA key fingerprint is 24:cb:8b:1f:8b:d7:a1:3d:a3:59:db:de:9b:b6:f7:f1. >> Are you sure you want to continue connecting (yes/no)? > > This only happens for the first connection (if no other packet was sent > before) between Site A and Site B. > > The point here is that TCP RTT estimates are not affected since early > retransmission timers are larger than the Map-Request rate-limiting. > > I know we don't show a Map-Request loss case here but the next > Map-Request would have been sent 3 seconds later. > > If a packet today would get dropped the same thing would happen. The TCP > connection would take 3 seconds to come up. But *it's not for every > connection* in the LISP case. > > Dino > >From what I see in your example, if the Map-Reply takes more than 3s due to the delay brought by the Mapping System or is lost, the ITR would send another Map-Request because the SYN timer (3 seconds) has expired on the host that initiated the communication. Such delay in the mapping system isn't impossible in a global mapping system and we showed in Stockholm that the ALT might have, occasionally, delays larger than 3s. Moreover, having LISP closer to the edge will further increase the delay. Therefore the ITR should retransmit Map-Requests using an independent timer instead of depending on receiving the next TCP syn. I guess this can be implemented easily because there is state related to the nonce already kept on the ITR. Thanks, Florin From jnc@mercury.lcs.mit.edu Wed Sep 16 08:51: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 59A4428C1B1 for ; Wed, 16 Sep 2009 08:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 1CvUn2XF+95J for ; Wed, 16 Sep 2009 08:51: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 232E53A6877 for ; Wed, 16 Sep 2009 08:51:03 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 5B1F56BE5E3; Wed, 16 Sep 2009 11:51:52 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090916155152.5B1F56BE5E3@mercury.lcs.mit.edu> Date: Wed, 16 Sep 2009 11:51:52 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 15:51:05 -0000 > From: Florin Coras > if the Map-Reply takes more than 3s due to the delay brought by the > Mapping System or is lost, the ITR would send another Map-Request > because the SYN timer (3 seconds) has expired > ... > Therefore the ITR should retransmit Map-Requests using an > independent timer instead of depending on receiving the next TCP > syn. Again, this is a change that is easy to do later, because there is no protocol change. We can change the spec, and it can be deployed in each LISP device independently. So let's see if experience shows we need it, before we make things more complicated? Noel From hartmans@mit.edu Wed Sep 16 08:51: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 C4E1728C1B1 for ; Wed, 16 Sep 2009 08:51:29 -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 HFMVi6sxFcbd for ; Wed, 16 Sep 2009 08:51: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 CC4BE3A6A1D for ; Wed, 16 Sep 2009 08:51:28 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 21CF451B4; Wed, 16 Sep 2009 11:52:14 -0400 (EDT) To: lisp@ietf.org References: <20090916151424.966C36BE5D8@mercury.lcs.mit.edu> From: Sam Hartman Date: Wed, 16 Sep 2009 11:52:14 -0400 In-Reply-To: (Margaret Wasserman's message of "Wed\, 16 Sep 2009 11\:41\:17 -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] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 15:51:29 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> Are you sure that routers don't queue packets waiting Margaret> for an ARP reply? It's my understanding that routers Margaret> _do_ queue packets when they send an ARP request,, and Margaret> that those packets are transmitted when a matching ARP Margaret> response is received. IP stacks that I've worked on Margaret> have had small packet queues associated with each Margaret> outstanding ARP request for this purpose. be sure to scope answers to either higher-end routers or low-end routers unless you're sure they apply globally. From root@core3.amsl.com Wed Sep 16 09:30:02 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BA1CE3A68C8; Wed, 16 Sep 2009 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090916163001.BA1CE3A68C8@core3.amsl.com> Date: Wed, 16 Sep 2009 09:30:01 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action: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, 16 Sep 2009 16:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : D. Farinacci, et al. Filename : draft-ietf-lisp-04.txt Pages : 67 Date : 2009-09-16 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-16092044.I-D@ietf.org> --NextPart-- From mrw@sandstorm.net Wed Sep 16 12:51: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 B38A83A695E for ; Wed, 16 Sep 2009 12:51: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 6UhOQtggZq1E for ; Wed, 16 Sep 2009 12:51:14 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id B431A3A6904 for ; Wed, 16 Sep 2009 12:51:14 -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 n8GJprrD026337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 16 Sep 2009 15:51:55 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: lisp@ietf.org In-Reply-To: <20090916151424.966C36BE5D8@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, 16 Sep 2009 15:51:53 -0400 References: <20090916151424.966C36BE5D8@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 19:51:15 -0000 I sent the information below in response to a private e-mail, and then I realized that the rest of the group might be interested in my (admittedly informal and unscientific) findings... There is an important difference between LISP and ARP that may make the trade-offs quite different for LISP than they are for ARP. With ARP, a given router will only have L + P = N ARP entries, where L is the number of locally attached hosts, and P is the number of other router interfaces attached to the same link. However, a LISP node will have a much larger number of possible map cache entries -- one for every EID prefix on the Internet. Let's take a real-life example... Sandstorm has a fairly simple leaf network with a single Internet connection serving a network with ~30 attached hosts. We have one main router, and an e-mail/web server on that communicates directly with the outside. I put a forensics tool just outside of our router/NAT/firewall, where the LISP xTR function would go if we were using it for address independence and multihoming. In a typical hour of workday traffic (captured from 10am-11am this morning), our forensics tool recorded ~18000 "connections" with ~2050 nodes outside of our site. This includes connections initiated from within our company, including DNS "connections", as well inbound connection attempts (most of which did not succeed). In that hour, hosts behind our firewall initiated 3006 DNS requests with 43 different servers, 3728 HTTP connections with 493 different servers, 96 SSL connections with 35 different servers, 45 NTP connections with 13 different servers, and a smattering of other connections. All told, we communicated _outbound_ with about 650 different systems. During the same period about 30 different systems established inbound connections with us. In that hour, our main router ARP'ed 5 different IP addresses on its outside link -- all of them routers or servers attached to its local interfaces. It probably also arp'ed for most, if not all, of our 30 internal nodes (I didn't see those messages, because I wasn't watching the internal network). So, our router maintained an ARP cache of < 50 entries. On our (pretty typical small business) network in a typical hour, our (theoretical) LISP ITR would need to do > 7000 map cache lookups (assuming it performed map cache lookups only for outbound traffic). I looked at the external IP addresses in use, and only a very small number of them were grouped in a way that suggested they might be from the same network, so it is likely that, in a typical working hour, our LISP router would need to send map requests and establish map cache entries for > 600 EID prefixes. The huge majority of these 600 entries represent the start of a connection (either with a DNS request or a TCP ). In many cases (where, for example, URLs with hostnames are used to refer to external HTTP images), the establishment of a single connection might require the creation of two different map cache entries, one for the DNS server and one for the TCP connection. This doubles the delay before an image can even start loading. I am sympathetic to arguments that we should take a "wait and see" attitude about whether fixes are needed in this area, but I do consider this to be a major area of concern for LISP. So, when we define the actual experiments that we intend to run (which I believe we have to do, in order to get our experimental RFCs published), I think we should pay special attention to covering the performance impact of LISP on connection establishment. Margaret P.S. BTW, it appears from the traffic I captured that our small enterprise router/NAT/firewall _does_ queue at least one outbound packet when it sends an ARP request, and that it sends the packet as soon as the ARP response is received (just judging from the temporal proximity of the two events). From jnc@mercury.lcs.mit.edu Wed Sep 16 13:14: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 B58D93A69F6 for ; Wed, 16 Sep 2009 13:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 EWsaxPuVvEbk for ; Wed, 16 Sep 2009 13:14: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 ECBC73A6805 for ; Wed, 16 Sep 2009 13:14:08 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 169F56BE614; Wed, 16 Sep 2009 16:14:58 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090916201458.169F56BE614@mercury.lcs.mit.edu> Date: Wed, 16 Sep 2009 16:14:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 20:14:09 -0000 > From: Margaret Wasserman > There is an important difference between LISP and ARP that may make the > trade-offs quite different for LISP than they are for ARP. This is quite a valid point, and your data is also very interesting. Nonetheless, the fact remains that most of the solutions people have discussed for this (refreshing old mappings that are in use; keeping mappings that time out, and using them provisionally; retransmitting Map-Requests - all of which I find excellent suggestions) do not involve protocol changes, and can thus be added without any up-heaval, later on. So at this point in time, it might be more productive overall to focus on things that _will_ require protocol changes? The longer those are put off, the more painful it will be (since we're still in a 'flag day' deployment model on the testbed). There is also some concern, I gather, that the protocol is perceived by some as being 'too complex'. So adding that factor to the decision-making process is another reason to leave things out, if the cost of doing so is minimal, until we have empirical evidence that the performance seen by users is inadequate. > I do consider this to be a major area of concern for LISP. This is quite understandable, and reasonable. > So, when we define the actual experiments that we intend to run .. I > think we should pay special attention to covering the performance > impact of LISP on connection establishment. This is an excellent idea, one I completely agree with. Once we have more data from actual experience - which will guide us to know how big the problem is, and therefore how big a hammer, out of the list of suggestions available, we will need - we can pick some set of these suggestions up and implement them. Noel From jzwiebel@cisco.com Wed Sep 16 13: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 4C1DC3A696C for ; Wed, 16 Sep 2009 13:24:51 -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=[AWL=-0.000, 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 DGE0DFOLm9Um for ; Wed, 16 Sep 2009 13:24:50 -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 0D8D63A6804 for ; Wed, 16 Sep 2009 13:24:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAATmsEqrR7PD/2dsb2JhbACCJy7DZ4hMAZBQBYQX X-IronPort-AV: E=Sophos;i="4.44,400,1249257600"; d="scan'208,217";a="390170549" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Sep 2009 20:25:40 +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 n8GKPeTo021215; Wed, 16 Sep 2009 13:25:40 -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 n8GKPexN027587; Wed, 16 Sep 2009 20:25:40 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, 16 Sep 2009 13:25:39 -0700 Received: from [10.0.1.3] ([10.21.78.159]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Sep 2009 13:25:39 -0700 In-Reply-To: <6573A4E1-8A08-4599-A0D0-E715D92540F4@sandstorm.net> References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> <200909161609.44539.ljakab@ac.upc.edu> <6573A4E1-8A08-4599-A0D0-E715D92540F4@sandstorm.net> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-106--52369837 Message-Id: <36BE594A-4836-4984-86BF-5DD04592457C@cisco.com> From: John Zwiebel Date: Wed, 16 Sep 2009 10:25:36 -1000 To: Margaret Wasserman X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 16 Sep 2009 20:25:39.0757 (UTC) FILETIME=[DB5725D0:01CA370B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2244; t=1253132740; x=1253996740; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[lisp]=20LISP=20Over=20Lossy=20Links |Sender:=20; bh=rGjYU2H1Rhj50QSxFqmPC4AuFv3UbFOdZvGlB0A4fLE=; b=b8EpmPecoGLo7/mmPB5wuPwGH7pCex6spxujPRnUomQEZ5u9t4qo0PbIOH bUU6RIur5nrjEa/rHP89H/6Yq7LhakUqKgE7YEJfO9V1hLkaN8BZtiw3zQek GCQ8BnlkLj; Authentication-Results: sj-dkim-3; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 20:24:51 -0000 --Apple-Mail-106--52369837 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 16, 2009, at 4:58 AM, Margaret Wasserman wrote: > > > Do you think we should suggest that LISP routers queue packets with > no map cache hit, and send them when the map response is received? > At least then we'd only introduce a single RTT of delay for session > establishment, instead of 3 seconds per connection. Absolutely not. We went around and around on this for multicast with app developers insisting that the first packet not be dropped. A hole lot of extra protocol was developed to "fix" this problem. None of that worked, a lot of time was wasted. And in the real world no one misses it. --Apple-Mail-106--52369837 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII
On Sep 16, 2009, at 4:58 AM, Margaret Wasserman = wrote:



Do you think we should suggest that LISP = routers queue packets with no map cache hit, and send them when the map = response is received?  = At least then we'd only introduce a single RTT of delay for = session establishment, instead of 3 seconds per connection.

=

Absolutely not.

We = went around and around on this for multicast with
app = developers insisting that the first packet not be dropped.
A = hole lot of extra protocol was developed to "fix" this = problem.
None of that worked, a lot of time was wasted. =  And in the
real world no one misses = it.

= --Apple-Mail-106--52369837-- From tme@americafree.tv Wed Sep 16 15:21: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 75BB23A6B51 for ; Wed, 16 Sep 2009 15:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 IAWqht1ii0JV for ; Wed, 16 Sep 2009 15:21:01 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 980283A67D8 for ; Wed, 16 Sep 2009 15:21:01 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 0B10C4BE022E; Wed, 16 Sep 2009 18:21:51 -0400 (EDT) Message-Id: <5021A8E2-372C-4891-92C2-6ED1FCCD37B3@americafree.tv> From: Marshall Eubanks To: John Zwiebel In-Reply-To: <36BE594A-4836-4984-86BF-5DD04592457C@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: Wed, 16 Sep 2009 18:21:50 -0400 References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> <200909161609.44539.ljakab@ac.upc.edu> <6573A4E1-8A08-4599-A0D0-E715D92540F4@sandstorm.net> <36BE594A-4836-4984-86BF-5DD04592457C@cisco.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 22:21:02 -0000 On Sep 16, 2009, at 4:25 PM, John Zwiebel wrote: > > On Sep 16, 2009, at 4:58 AM, Margaret Wasserman wrote: > >> >> >> Do you think we should suggest that LISP routers queue packets with >> no map cache hit, and send them when the map response is received? >> At least then we'd only introduce a single RTT of delay for session >> establishment, instead of 3 seconds per connection. > > Absolutely not. +1 Marshall > > We went around and around on this for multicast with > app developers insisting that the first packet not be dropped. > A hole lot of extra protocol was developed to "fix" this problem. > None of that worked, a lot of time was wasted. And in the > real world no one misses it. > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Wed Sep 16 15:54: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 9F0B83A6911 for ; Wed, 16 Sep 2009 15:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 MlMtLHPUlkEM for ; Wed, 16 Sep 2009 15:54:38 -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 BAC473A6B6F for ; Wed, 16 Sep 2009 15:54:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACUKsUqrR7O6/2dsb2JhbADFR4hMAZBRBYQY X-IronPort-AV: E=Sophos;i="4.44,400,1249257600"; d="scan'208";a="205502466" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 16 Sep 2009 22:55:29 +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 n8GMtTdT002316; Wed, 16 Sep 2009 15:55:29 -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 n8GMtTBn012804; Wed, 16 Sep 2009 22:55:29 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); Wed, 16 Sep 2009 15:55:28 -0700 Received: from [192.168.1.2] ([10.21.116.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Sep 2009 15:55:28 -0700 Message-Id: <96BFDFD6-4A32-4730-8063-BE2687FF5EE7@cisco.com> From: Dino Farinacci To: Florin Coras In-Reply-To: <4AB10787.2060801@net.utcluj.ro> 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, 16 Sep 2009 15:55:28 -0700 References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> <4AB10787.2060801@net.utcluj.ro> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Sep 2009 22:55:28.0607 (UTC) FILETIME=[C91CCEF0:01CA3720] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1528; t=1253141729; x=1254005729; 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]=20LISP=20Over=20Lossy=20Links |Sender:=20; bh=l+kp91aNVeT2kyuAXjk3cD2vkwyPK819odM7nu6I/iU=; b=sOBqgnQv8uecKZJcBt+/q+ER+SxeLhPQHeNYUJMEK4BQsRLELQg8T8PEBq W58yzioftSbZBsI2VgBG+BuA8bctMDG2ctTD/Lagqg2Q8AO0ea1EODgXVRA+ TUYeq9hEIn; 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] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 16 Sep 2009 22:54:39 -0000 > From what I see in your example, if the Map-Reply takes more than 3s > due > to the delay brought by the Mapping System or is lost, the ITR would > send another Map-Request because the SYN timer (3 seconds) has expired The 3 second delay is TCP not the mapping system. And if any other host at the site sent to the same destination sort during that 3 second period, then a Map-Request would be generated. > on the host that initiated the communication. > Such delay in the mapping system isn't impossible in a global mapping > system and we showed in Stockholm that the ALT might have, > occasionally, > delays larger than 3s. Moreover, having LISP closer to the edge will > further increase the delay. > Therefore the ITR should retransmit Map-Requests using an independent > timer instead of depending on receiving the next TCP syn. I guess this > can be implemented easily because there is state related to the nonce > already kept on the ITR. The delay of the mapping system is based on the paths the Map-Request takes. The path can be pretty much on path into the core. In our test network, my site has an EID-prefix out of RIPE's allocation. My site is in San Jose. I register to the Map-Server in Amsterdam. So when I send a Map-Request from another site in San Jose to my site, the Map-Request travels to Amsterdam, then gets encapsulated to the ETR in San Jose. Then the Map-Reply goes to the source site in San Jose. We have measured times of 200-300ms. Dino From hartmans@mit.edu Thu Sep 17 05:52: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 8E8B23A6985 for ; Thu, 17 Sep 2009 05:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 KRhYjBAjxWw5 for ; Thu, 17 Sep 2009 05:52:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id D65863A67EA for ; Thu, 17 Sep 2009 05:52:23 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0E35C51C2; Thu, 17 Sep 2009 08:53:09 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Thu, 17 Sep 2009 08:53: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 Subject: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 17 Sep 2009 12:52:24 -0000 Folks, we've had some discussion on issue #5 regarding LISP protocol versioning. It's quite clear that we don't have consensus behind any specific proposal at the moment. However I've starting to see vague support behind doing something in this space. In particular, we have Margaret's LISP format proposal, which was discussed under #16. Damien made a different proposal--to actually have an ordered set of versions. noel seems to support something especially in terms of control plane negotiation. Dino raised an objection against Damien's proposal that you don't want to have multiple round trips of negotiation. As far as I can tell, Damien's proposal doesn't suffer from the issue Dino is concerned about. In particular, the only form of negotiation he had is that the sender let you know what version he supported, often before you sent a packet to the sender. I'd encourage those interested in seeing forward progress on this issue to get together and see if they can form a concrete proposal. It may turn out that we don't know enough to turn this into something concrete. From jesper@cisco.com Thu Sep 17 05:57: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 BD6C528C1EC for ; Thu, 17 Sep 2009 05:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 vbjkX4cXjPiZ for ; Thu, 17 Sep 2009 05:57:25 -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 787D128C202 for ; Thu, 17 Sep 2009 05:57:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,403,1249257600"; d="scan'208";a="49613102" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Sep 2009 12:58:15 +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 n8HCwFp7008171; Thu, 17 Sep 2009 14:58:15 +0200 Received: from [127.0.0.1] (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8HCwDU0001044; Thu, 17 Sep 2009 12:58:14 GMT Message-Id: <1F6D2BA3-5457-467A-9EE0-4BF4F8AF194B@cisco.com> From: Jesper Skriver To: John Zwiebel In-Reply-To: <36BE594A-4836-4984-86BF-5DD04592457C@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: Thu, 17 Sep 2009 15:58:13 +0300 References: <902ED4FE-3512-4645-8A7F-23CC1A573D90@sandstorm.net> <200909161609.44539.ljakab@ac.upc.edu> <6573A4E1-8A08-4599-A0D0-E715D92540F4@sandstorm.net> <36BE594A-4836-4984-86BF-5DD04592457C@cisco.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1187; t=1253192295; x=1254056295; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jesper@cisco.com; z=From:=20Jesper=20Skriver=20 |Subject:=20Re=3A=20[lisp]=20LISP=20Over=20Lossy=20Links |Sender:=20; bh=+uFMk2HkgvJ2/LuG3keokedf5Gark+pgUxiNcb4Cytg=; b=L2ibtptSHtTBPdZteR7JWXOakBk94mFeisPzAre6Ykdm7RqetR6+mewkGi fw1MteKKwyr5CfDdaUzv3zRj+WTsvVzMm1a1fF4MiMAeR4ktAAZgLfUb6BqL Psyw8upHxi; Authentication-Results: ams-dkim-1; header.From=jesper@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] LISP Over Lossy Links X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 17 Sep 2009 12:57:25 -0000 On 16 Sep 2009, at 23:25, John Zwiebel wrote: > > On Sep 16, 2009, at 4:58 AM, Margaret Wasserman wrote: > >> >> >> Do you think we should suggest that LISP routers queue packets with >> no map cache hit, and send them when the map response is received? >> At least then we'd only introduce a single RTT of delay for session >> establishment, instead of 3 seconds per connection. > > Absolutely not. +1 In real life it doesn't make any difference. For example, when a typical Cisco IOS router needs to send a packet to a next-hop for which it does not have an ARP entry, it will send out an ARP request after having dropped the user packet, that it could not forward due to an ARP entry missing. /Jesper > > We went around and around on this for multicast with > app developers insisting that the first packet not be dropped. > A hole lot of extra protocol was developed to "fix" this problem. > None of that worked, a lot of time was wasted. And in the > real world no one misses it. > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp /Jesper From hartmans@mit.edu Thu Sep 17 05:59: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 4F48B3A6816 for ; Thu, 17 Sep 2009 05:59:49 -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.370, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_53=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 WsOuytUKCQKT for ; Thu, 17 Sep 2009 05:59:48 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 8479C3A688D for ; Thu, 17 Sep 2009 05:59:48 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4980D51C2; Thu, 17 Sep 2009 09:00:34 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Thu, 17 Sep 2009 09:00:34 -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/data plane consensus call X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 17 Sep 2009 12:59:49 -0000 Darrel and I have discussed the resolution of the map versioning proposal. At this point, the WG has not received a request to adopt Luigi's draft, although he indicated we might receive such a request in the future. The chairs believe that we'd need to see somewhat more support for a specific proposal than we've seen for map versioning to date in order to adopt that proposal. If we did receive sufficient support to adopt something as a WG draft, assigning the flag would be easy. The question of whether something belongs in the data plane seems to be all over the map. Dino has indicated that he wants to see this in the control plane. Margaret wants to pursue the path of using short TTLs and mechanisms to refresh TTLs before they expire. Luigi of course wants to see some sort of map versioning in the data plane. We definitely don't have consensus today,but we also don't have consensus to rule things out. I think we may be revisiting the question of what belongs in the data plane when we get more data. Meanwhile I think we can close out this issue as no consensus. From hartmans@mit.edu Thu Sep 17 06: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 8EABB3A6AFA for ; Thu, 17 Sep 2009 06:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 8pKdwVWV+VBG for ; Thu, 17 Sep 2009 06:24: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 D8A973A69CB for ; Thu, 17 Sep 2009 06:24:37 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CC44E51C2; Thu, 17 Sep 2009 09:25:22 -0400 (EDT) To: Dino Farinacci References: <8472C95A-6A64-4405-921F-2DD8AB6D0211@sandstorm.net> <9B93E45D-92DE-4D5C-92F8-773C6DDB29D4@cisco.com> From: Sam Hartman Date: Thu, 17 Sep 2009 09:25:22 -0400 In-Reply-To: (Dino Farinacci's message of "Tue\, 15 Sep 2009 09\:24\:48 -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] #19: not including the 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: Thu, 17 Sep 2009 13:24:38 -0000 >>>>> "Dino" == Dino Farinacci writes: Dino> Sam, I have talked to all the draft-meyer-lisp-mn-00.txt Dino> authors. We agreed to pull the M-bit allocation and Dino> description from the main spec. I think we can close this issue as fixed. I think the discussion supported developing IANA policies and an IANA section for the spec with Dino as a notable objection. So, we may be back to the general IANA issue whenever someone wants to drive it. From jnc@mercury.lcs.mit.edu Thu Sep 17 08:21: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 F28EA28C115 for ; Thu, 17 Sep 2009 08:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 hV3AqqXtxZTw for ; Thu, 17 Sep 2009 08:21:41 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 4C4693A6A86 for ; Thu, 17 Sep 2009 08:21:41 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2BC336BE609; Thu, 17 Sep 2009 11:22:32 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090917152232.2BC336BE609@mercury.lcs.mit.edu> Date: Thu, 17 Sep 2009 11:22:32 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #19: not including the 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: Thu, 17 Sep 2009 15:21:42 -0000 > From: Sam Hartman > I think the discussion supported developing IANA policies and an > IANA section for the spec ... > So, we may be back to the general IANA issue whenever someone wants > to drive it. As long as there's a WG open for LISP, I think it should be in control of allocating bits headers in the header, not the IANA. Header bits are a very limited resource, and an allocation authority is by its very nature just not in as good a position to judge what is a good way to 'spend' them as the technical group developing the protocol is. Noel From lear@cisco.com Thu Sep 17 08:30: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 7D4DF3A67F2 for ; Thu, 17 Sep 2009 08:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.263 X-Spam-Level: X-Spam-Status: No, score=-10.263 tagged_above=-999 required=5 tests=[AWL=0.336, 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 betZcQ+WLmtn for ; Thu, 17 Sep 2009 08:30:28 -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 122EA28C0EF for ; Thu, 17 Sep 2009 08:30:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMAAE/zsUqQ/uCKe2dsb2JhbACBU5lVAQEWJAaqbIhOASsIkAIFgkAIgVCLAQ X-IronPort-AV: E=Sophos;i="4.44,404,1249257600"; d="scan'208";a="49629848" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Sep 2009 15:31:18 +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 n8HFVIQm019441; Thu, 17 Sep 2009 17:31:18 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp7686.cisco.com [10.61.94.5]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8HFVIaw017764; Thu, 17 Sep 2009 15:31:18 GMT Message-ID: <4AB25646.1090302@cisco.com> Date: Thu, 17 Sep 2009 17:31:18 +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: Noel Chiappa References: <20090917152232.2BC336BE609@mercury.lcs.mit.edu> In-Reply-To: <20090917152232.2BC336BE609@mercury.lcs.mit.edu> 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=622; t=1253201478; x=1254065478; 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#19=3A=20not=20including=20the =20M=20bit |Sender:=20; bh=WGAWQY41/nZPRGXBqHinIvzq9TJktl2kXn66atB1WFQ=; b=dKY/lYUyqwDbgx0TZTPoWPfqRc0OyarYu8SNiYWhRa+h7wDCRgDIJ8BiZW fY5ub60TBLLAwMp4ExKI7QQe3SPQQagrVUgA0Uvv5x/fuKn+lvmTKUx5B1Te fXf/T5b6z9; 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] #19: not including the 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: Thu, 17 Sep 2009 15:30:29 -0000 Noel, When you specify a registry for IANA you also specify an update policy. I agree with your concerns about the limited availability of bits. That should be taken into account when specifying the policy. You can require designated expert review, working group review, or perhaps other mechanisms. Because these are still early days for LISP you don't want to make it impossible to get a bit, but you also want people to be serious when they ask. Thus, my suggestion would be to start with a designated expert review and then as time goes on you up the requirement to a heavier review process. Eliot From jnc@mercury.lcs.mit.edu Thu Sep 17 08:34: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 480213A6822 for ; Thu, 17 Sep 2009 08:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 t4JIBDpQkDXL for ; Thu, 17 Sep 2009 08:34: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 6608F3A63CB for ; Thu, 17 Sep 2009 08:34:47 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 02C406BE609; Thu, 17 Sep 2009 11:35:38 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090917153539.02C406BE609@mercury.lcs.mit.edu> Date: Thu, 17 Sep 2009 11:35:38 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #16: map versioning/data plane consensus call X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 17 Sep 2009 15:34:48 -0000 > From: Sam Hartman > The chairs believe that we'd need to see somewhat more support for a > specific proposal than we've seen for map versioning to date in > order to adopt that proposal. Well, I think we're a ways from that point, yet; the proposal has not yet received in-depth scrutiny from the WG, and I suspect that in such a process, a number of changes would likely happen. (I know a number of people, including me, would prefer an automatic 'fingerprint' to a version number, for instance.) Also, the whole area of discovering and dealing with out-dated mappings has yet to be systematically analyzed. (For instance, what happens if a packet gets to an xTR which is no longer a valid xTR for the destination EID? That should be easy to detect, and relatively easy - module DoS concerns - to fix, but I don't think there's anything in the spec about it yet.) And of course we don't have a lot of real experience yet, to guide us in that systematic analysis. > If we did receive sufficient support to adopt something as a WG > draft, assigning the flag would be easy. Exactly. > The question of whether something belongs in the data plane seems to > be all over the map. For good reason, though. On the one hand, in high-end boxes (which is where the majority of LISP packets will be handled, if it succeeds) doing control functions in the data plane is usually a major PITA - the overall box architecture just isn't set up for it. On the other hand, doing it in the control plane makes it impossible to piggyback these functions on existing traffic - and with the fan-outs we expect to see in LISP, the overhead of dedicated control traffic for these functions is a lot of traffic. (Although I do think the concern over this might be a bit exaggerated... although that's quite possibly true of a lot of the other concerns that are expressed without much actual experience to guide us.) > I think we may be revisiting the question of what belongs in the > data plane when we get more data. Sounds like a plan.... Noel From jnc@mercury.lcs.mit.edu Thu Sep 17 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 78C0028C110 for ; Thu, 17 Sep 2009 08:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 iy77kCXAfDBj for ; Thu, 17 Sep 2009 08:39:38 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id CF2533A6915 for ; Thu, 17 Sep 2009 08:39:38 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 5991B6BE609; Thu, 17 Sep 2009 11:40:30 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090917154030.5991B6BE609@mercury.lcs.mit.edu> Date: Thu, 17 Sep 2009 11:40:30 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #19: not including the 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: Thu, 17 Sep 2009 15:39:39 -0000 > From: Eliot Lear > When you specify a registry for IANA you also specify an update > policy. ... You can require designated expert review, working group > review, or perhaps other mechanisms. I guess I don't see the point of going through the overhead of setting up an IANA registry if we're just going to set the WG as the arbiters of the update. What does it buy us? Noel From hartmans@mit.edu Thu Sep 17 08:40: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 106133A6A63 for ; Thu, 17 Sep 2009 08:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 yYZ6q3rZLOJF for ; Thu, 17 Sep 2009 08:40:09 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4AD513A682D for ; Thu, 17 Sep 2009 08:40:09 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6B01351C2; Thu, 17 Sep 2009 11:40:54 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090917152232.2BC336BE609@mercury.lcs.mit.edu> From: Sam Hartman Date: Thu, 17 Sep 2009 11:40:54 -0400 In-Reply-To: <20090917152232.2BC336BE609@mercury.lcs.mit.edu> (Noel Chiappa's message of "Thu\, 17 Sep 2009 11\:22\:32 -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: [lisp] IANA allocations X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 17 Sep 2009 15:40:13 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Sam Hartman I think the >> discussion supported developing IANA policies and an IANA >> section for the spec ... So, we may be back to the general >> IANA issue whenever someone wants to drive it. Noel> As long as there's a WG open for LISP, I think it should be Noel> in control of allocating bits headers in the header, not the Noel> IANA. Header bits are a very limited resource, and an Noel> allocation authority is by its very nature just not in as Noel> good a position to judge what is a good way to 'spend' them Noel> as the technical group developing the protocol is. *sigh* I think you completely misunderstand what IANA does and how it works, especially for a document not yet published. IANA basically never makes decisions about protocol assignments except for first-come-first-serve registries. They used to make a few more decisions, for example for specification required registries, but I believe even those have experts assigned. Take a look at RFC 5226 for details. Here's how using IANA would work for us. 1) Step one: the step we most care about. We'd decide what policy we're going to use for allocating scarce resources. "Whenever we decide to do so for WG documents," would be fine. Especially when making allocations for non-WG documents I'd want us to have more guidelines than simply "we come to consensus." Especially since some of the proposed uses are for things that are out of scope, we need guidelines that are easier to evaluate for fairness. We can definitely use judgment, but we should at least write down the factors we're going to consider. 2) We write up some text that describes the namespaces that our document creates and the assignment guidelines we're using. 3) We effectively already have the initial assignments in the form of the flags we're using today. 4) As the spec progresses within the WG, we can modify the allocations/initial assignments consistent with our guidelines. We can even modify our assignment guidelines although doing so has certain fairness considerations that are important. 5) When our document gets published as an RFC, IANA creates registries for the namespaces we create. In the future, they will update them according to the guidelines we established. If we want to retain control, one of the common guidelines is "IETF review," meaning that the IETF must publish an RFC to make the change. There's complexity surrounding things like early assignments, etc, but once we figure out what the WG wants as a high level we can figure out the right process text to affect that. I don't think it is particularly negotiable that by the time it is published as an RFC, the LISP spec will create a bunch of IANA namespaces. Whether we create one for the flags probably is negotiable, and teh assignment guidelines certainly are. The main thrust of my point in #19 is that we're not going to make assignments for non-WG documents without coming up with guidelines for how we make those assignments. The framework the IETF uses to discuss such issues is IANA assignments. From mrw@sandstorm.net Thu Sep 17 08:47: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 A6AB13A69CA for ; Thu, 17 Sep 2009 08:47:07 -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 s-IBUtjPp-kv for ; Thu, 17 Sep 2009 08:47:07 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id CEFDB3A6940 for ; Thu, 17 Sep 2009 08:47:06 -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 n8HFlhw1081559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Sep 2009 11:47:43 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: 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: Thu, 17 Sep 2009 11:47:42 -0400 References: <20090917152232.2BC336BE609@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] IANA allocations X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 17 Sep 2009 15:47:07 -0000 On Sep 17, 2009, at 11:40 AM, Sam Hartman wrote: > > I don't think it is particularly negotiable that by the time it is > published as an RFC, the LISP spec will create a bunch of IANA > namespaces. Whether we create one for the flags probably is > negotiable, and teh assignment guidelines certainly are. If we don't create a loser assignment policy for the flags, the de- facto policy will be "RFC required" or thereabouts, because the IETF has been pretty ferocious about not having documents from other standards bodies allocate code points for parts of our standards that don't have IANA-controlled registries. So, if we want a loser policy than requiring an RFC (that updates our RFC) to allocate new options, we should specify an IANA policy for them. Margaret From mrw@sandstorm.net Thu Sep 17 08:51: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 CA81B3A69CD for ; Thu, 17 Sep 2009 08:51:37 -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 gA-wdJqlEp15 for ; Thu, 17 Sep 2009 08:51:37 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 10F903A69CA for ; Thu, 17 Sep 2009 08:51:36 -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 n8HFqRNH081776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Sep 2009 11:52:27 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <9C8A24E4-A5B5-4F3D-A8B3-193E03581D8F@sandstorm.net> From: Margaret Wasserman 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: Thu, 17 Sep 2009 11:52:26 -0400 References: <20090917152232.2BC336BE609@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] IANA allocations X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 17 Sep 2009 15:51:37 -0000 On Sep 17, 2009, at 11:47 AM, Margaret Wasserman wrote: > > On Sep 17, 2009, at 11:40 AM, Sam Hartman wrote: >> >> I don't think it is particularly negotiable that by the time it is >> published as an RFC, the LISP spec will create a bunch of IANA >> namespaces. Whether we create one for the flags probably is >> negotiable, and teh assignment guidelines certainly are. > > If we don't create a loser assignment policy for the flags... I meant a _looser_ assignment policy, not a _loser_ one. Sorry. Margaret From hartmans@mit.edu Thu Sep 17 08: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 17B8F3A6899 for ; Thu, 17 Sep 2009 08:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_62=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 gA5khzfjZzA8 for ; Thu, 17 Sep 2009 08:55: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 49B8A3A68A6 for ; Thu, 17 Sep 2009 08:55:05 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D8B6051C2; Thu, 17 Sep 2009 11:55:50 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090917154030.5991B6BE609@mercury.lcs.mit.edu> From: Sam Hartman Date: Thu, 17 Sep 2009 11:55:50 -0400 In-Reply-To: <20090917154030.5991B6BE609@mercury.lcs.mit.edu> (Noel Chiappa's message of "Thu\, 17 Sep 2009 11\:40\: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] #19: not including the 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: Thu, 17 Sep 2009 15:55:06 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Eliot Lear When you specify a registry >> for IANA you also specify an update policy. ... You can require >> designated expert review, working group review, or perhaps >> other mechanisms. Noel> I guess I don't see the point of going through the overhead Noel> of setting up an IANA registry if we're just going to set Noel> the WG as the arbiters of the update. What does it buy us? Fairness, mostly. It makes us decide how we're going to allocate things. If someone comes forward and says "Hey, you approved 95% of vendor A's registration requests and only 5% of vendor B's," I as chair want us to be able to show that it isn't simply because we like vendor A better. That is one of the reasons, but there are a bunch of others. So, I want to write down the criteria we're going to use. Until we do, the default criteria I will use is that resources can be assigned to WG documents under WG consensus. I think I may have said that of course there will be objective elements to this in another message. What I intended to say is that of course there will be subjective elements. However I'm not saying we need to do this. I'm saying that there seemed to be enough support that if someone in the WG wants to drive the effort,it sounds like they might succeed. If no one wants to allocate codepoints to non-WG documents, then we don't need to do it until much later in the process, very near submitting to Jari. From hartmans@mit.edu Thu Sep 17 09:26: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 640D828C2B0 for ; Thu, 17 Sep 2009 09:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 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 vd4elqtHemTV for ; Thu, 17 Sep 2009 09:26:54 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 00EF428C2AE for ; Thu, 17 Sep 2009 09:26:48 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BF4BE51C2; Thu, 17 Sep 2009 12:27:34 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Thu, 17 Sep 2009 12:27:34 -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] #22: rough support for fixing MS requires XTRs to consume packets not address to them X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 17 Sep 2009 16:26:55 -0000 Based on discussion so far, there appears to be a rough consensus in favor of changing the MS/MR protocol so that XTRs do not need to consume packets not addressed to them. I'm going to start a one week timer on this; any objections should be received by September 18. If there are no significant objections we'll declare rough consensus on the technical direction proposed in the issue at http://tools.ietf.org/wg/lisp/trac/ticket/22. Joel provided a bit more detail on the cross-AFI case. Obviously we would have a later consensus call on specific text. I raised the issue. Dino raised concerns about the cross-AFI case. My original proposal and Joel's response contained solutions to Dino's concerns. Margaret also expressed support. This is one of the threads where there isn't really a lot of discussion of things other than issue #22 with that subject line. That said, this call is being made more to move the discussion along than because I have high confidence we're done. I do think there is sufficient support to call consensus on a rough technical direction if no one comments. However I also suspect this message will result in comments. That's fine. The goal here is to move along discussions and to make steady progress, not to shut out discussion. Sam Hartman LISP co-chair From dino@cisco.com Thu Sep 17 15:59: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 9318A3A6AA0 for ; Thu, 17 Sep 2009 15:59:57 -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 4hl4tJtTTgGu for ; Thu, 17 Sep 2009 15:59:56 -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 3DC383A6858 for ; Thu, 17 Sep 2009 15:59:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANdbskqrR7PD/2dsb2JhbAC8A4hQAZAtBYQciwE X-IronPort-AV: E=Sophos;i="4.44,405,1249257600"; d="scan'208";a="390978512" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Sep 2009 23:00: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 n8HN0k6N024196; Thu, 17 Sep 2009 16:00:46 -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 n8HN0kxj020438; Thu, 17 Sep 2009 23:00:46 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, 17 Sep 2009 16:00:46 -0700 Received: from [192.168.1.2] ([10.21.75.139]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 16:00:46 -0700 Message-Id: <88BE40EC-0E8B-4B24-8ACB-6D732222BF96@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 v936) Date: Thu, 17 Sep 2009 16:00:45 -0700 References: <20090917152232.2BC336BE609@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Sep 2009 23:00:46.0134 (UTC) FILETIME=[B0C95560:01CA37EA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3953; t=1253228446; x=1254092446; 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]=20IANA=20allocations |Sender:=20; bh=XYrwPLhd3hwIBEPdjJESJK4kocBv+J870U4wfZVzDJQ=; b=ciui+ccGxhstADrvvzwraV21zV+gFxUgCvsL9gXhFIQfNOpuDn6gY8uhnV u00dflLHFbb8lMsbIqdIq87xThpsC9zhVtwPBxwj0Sa0GQm+/Tz4TQqJiFHc goyjJ31FvX; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] IANA allocations X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 17 Sep 2009 22:59:57 -0000 I think your proposal needs to be greatly simplified. I think any contention points for allocations can be easily resolve by talking to each other. Can we wait for the drafts to be published as experimental RFCs before we go through this process? That would seem simpler and we can focus on design and not IETF procedure. Tell me what adding all this formalism earlier is going to buy us? Dino On Sep 17, 2009, at 8:40 AM, Sam Hartman wrote: >>>>>> "Noel" == Noel Chiappa writes: > >>> From: Sam Hartman I think the >>> discussion supported developing IANA policies and an IANA >>> section for the spec ... So, we may be back to the general >>> IANA issue whenever someone wants to drive it. > > Noel> As long as there's a WG open for LISP, I think it should be > Noel> in control of allocating bits headers in the header, not the > Noel> IANA. Header bits are a very limited resource, and an > Noel> allocation authority is by its very nature just not in as > Noel> good a position to judge what is a good way to 'spend' them > Noel> as the technical group developing the protocol is. > > *sigh* I think you completely misunderstand what IANA does and how it > works, especially for a document not yet published. IANA basically > never makes decisions about protocol assignments except for > first-come-first-serve registries. They used to make a few more > decisions, for example for specification required registries, but I > believe even those have experts assigned. Take a look at RFC 5226 for > details. > > Here's how using IANA would work for us. > > 1) Step one: the step we most care about. We'd decide what policy > we're going to use for allocating scarce resources. "Whenever we > decide to do so for WG documents," would be fine. Especially when > making allocations for non-WG documents I'd want us to have more > guidelines than simply "we come to consensus." Especially since some > of the proposed uses are for things that are out of scope, we need > guidelines that are easier to evaluate for fairness. We can > definitely use judgment, but we should at least write down the factors > we're going to consider. > > 2) We write up some text that describes the namespaces that our > document creates and the assignment guidelines we're using. > > 3) We effectively already have the initial assignments in the form of > the flags we're using today. > > 4) As the spec progresses within the WG, we can modify the > allocations/initial assignments consistent with our guidelines. We > can even modify our assignment guidelines although doing so has > certain fairness considerations that are important. > > 5) When our document gets published as an RFC, IANA creates registries > for the namespaces we create. In the future, they will update them > according to the guidelines we established. If we want to retain > control, one of the common guidelines is "IETF review," meaning that > the IETF must publish an RFC to make the change. There's complexity > surrounding things like early assignments, etc, but once we figure out > what the WG wants as a high level we can figure out the right process > text to affect that. > > I don't think it is particularly negotiable that by the time it is > published as an RFC, the LISP spec will create a bunch of IANA > namespaces. Whether we create one for the flags probably is > negotiable, and teh assignment guidelines certainly are. > > The main thrust of my point in #19 is that we're not going to make > assignments for non-WG documents without coming up with guidelines for > how we make those assignments. The framework the IETF uses to discuss > such issues is IANA assignments. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From mrw@sandstorm.net Thu Sep 17 17:42: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 784293A681D for ; Thu, 17 Sep 2009 17:42:04 -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 4BtmIGXuOCu7 for ; Thu, 17 Sep 2009 17:42:03 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 9DD1E3A6B1F for ; Thu, 17 Sep 2009 17:42:03 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8I0gKRW006521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Sep 2009 20:42:21 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <4AD19AB4-2785-4487-9C1B-186CF5F11465@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <88BE40EC-0E8B-4B24-8ACB-6D732222BF96@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: Thu, 17 Sep 2009 20:42:19 -0400 References: <20090917152232.2BC336BE609@mercury.lcs.mit.edu> <88BE40EC-0E8B-4B24-8ACB-6D732222BF96@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] IANA allocations X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 00:42:04 -0000 On Sep 17, 2009, at 7:00 PM, Dino Farinacci wrote: > > Can we wait for the drafts to be published as experimental RFCs > before we go through this process? That would seem simpler and we > can focus on design and not IETF procedure. An "IANA Considerations" section is required in all I-Ds that are submitted for RFC publication (per http://www.ietf.org/id-info/checklist.html) , so we definitely have to add one before the Experimental RFCs can be published. It is up to the WG to decide what IANA registries are needed, and what the allocation policy should be for those registries. The allocation policy choices are described in RFC 2434: "Guidelines for Writing an IANA Considerations Section". Margaret From dino@cisco.com Thu Sep 17 17:52: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 C5CE63A693E for ; Thu, 17 Sep 2009 17:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 0tXv3emdrccP for ; Thu, 17 Sep 2009 17:52:21 -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 0A4153A6B0C for ; Thu, 17 Sep 2009 17:52:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANV2skqrR7MV/2dsb2JhbAC8J4hQAZApBYQc X-IronPort-AV: E=Sophos;i="4.44,406,1249257600"; d="scan'208";a="391037366" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Sep 2009 00:53:14 +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 n8I0rESr018761; Thu, 17 Sep 2009 17:53:14 -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 n8I0rE05015621; Fri, 18 Sep 2009 00:53:14 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, 17 Sep 2009 17:53:13 -0700 Received: from [192.168.1.2] ([10.21.75.139]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 17:53:13 -0700 Message-Id: From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <4AD19AB4-2785-4487-9C1B-186CF5F11465@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, 17 Sep 2009 17:53:13 -0700 References: <20090917152232.2BC336BE609@mercury.lcs.mit.edu> <88BE40EC-0E8B-4B24-8ACB-6D732222BF96@cisco.com> <4AD19AB4-2785-4487-9C1B-186CF5F11465@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Sep 2009 00:53:13.0328 (UTC) FILETIME=[666D6F00:01CA37FA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=842; t=1253235194; x=1254099194; 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]=20IANA=20allocations |Sender:=20; bh=g7FKILu8yS/5X3pZNzRij/RnNf14pXG6HNH5I/YUgMg=; b=uxWVkcf7hQZvpfOx5gsXZl+4QIRdEL02NvCpFKdX2qH0qIxyUknxn9I42D WGdA0fijOsgid9bAydlY8CZD7i9EJM633W/YLV6prjeg9ZNFa3LlMVnXRp9p PIlGBXmPhYjtpVylUTchmmJudKitw5glqAT9BptAvcy0Xttv4UtjE=; 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] IANA allocations X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 00:52:21 -0000 > On Sep 17, 2009, at 7:00 PM, Dino Farinacci wrote: >> >> Can we wait for the drafts to be published as experimental RFCs >> before we go through this process? That would seem simpler and we >> can focus on design and not IETF procedure. > > An "IANA Considerations" section is required in all I-Ds that are > submitted for RFC publication (per http://www.ietf.org/id-info/checklist.html) > , so we definitely have to add one before the Experimental RFCs can > be published. It is up to the WG to decide what IANA registries are > needed, and what the allocation policy should be for those > registries. The allocation policy choices are described in RFC > 2434: "Guidelines for Writing an IANA Considerations Section". The former is fine to put in the specs now. It's the later we could wait on. Dino From brian.e.carpenter@gmail.com Thu Sep 17 18:08: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 162A33A6A63 for ; Thu, 17 Sep 2009 18:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 H6fW1mjXJKKZ for ; Thu, 17 Sep 2009 18:08:26 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 583EE3A693E for ; Thu, 17 Sep 2009 18:08:25 -0700 (PDT) Received: by pxi3 with SMTP id 3so466561pxi.31 for ; Thu, 17 Sep 2009 18:09:16 -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=3xNy3VWjOE885LC5lJa/4Lbywz8rhXUYD79OzOdmSUk=; b=E9zW3lad8/RHZMyIaP80wly162SNnmVVJLVticGRRH/W5rZXnovOyVrglkh00hvsPq dSMy1CL6csEvMS720uWLFtfx/nlFFI7XyD79TG2lbhFv9K/C/gTT2wyifuDZGNAtGQEh x/y2z8qlzSi91EImDZbGBvfGaBKJY3JulmgCA= 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=h92Nr+KX6esa1DuY1T4XDwlj/W3RAhtGJcCfIwyxPNUsIRTWjHKn2k30Zm/In9vzvr olasBpuXH3tjayPchA/1OhVK38kH/znAz5Oj1/ix5A+rezidUEDaGwX8RcnJgOR5qVuK Xu1thT+tln6GTtt+M852ZqvP6DNUAP9ry3m/I= Received: by 10.115.66.9 with SMTP id t9mr1282240wak.56.1253236156386; Thu, 17 Sep 2009 18:09:16 -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 21sm607735pxi.7.2009.09.17.18.09.14 (version=SSLv3 cipher=RC4-MD5); Thu, 17 Sep 2009 18:09:16 -0700 (PDT) Message-ID: <4AB2DDBE.3000809@gmail.com> Date: Fri, 18 Sep 2009 13:09:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dino Farinacci References: <20090917152232.2BC336BE609@mercury.lcs.mit.edu> <88BE40EC-0E8B-4B24-8ACB-6D732222BF96@cisco.com> <4AD19AB4-2785-4487-9C1B-186CF5F11465@sandstorm.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org, Noel Chiappa , Margaret Wasserman Subject: Re: [lisp] IANA allocations X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 01:08:27 -0000 BTW, RFC2434 is obsolete. You need to check the latest choices in RFC5226. Brian On 2009-09-18 12:53, Dino Farinacci wrote: >> On Sep 17, 2009, at 7:00 PM, Dino Farinacci wrote: >>> >>> Can we wait for the drafts to be published as experimental RFCs >>> before we go through this process? That would seem simpler and we can >>> focus on design and not IETF procedure. >> >> An "IANA Considerations" section is required in all I-Ds that are >> submitted for RFC publication (per >> http://www.ietf.org/id-info/checklist.html), so we definitely have to >> add one before the Experimental RFCs can be published. It is up to >> the WG to decide what IANA registries are needed, and what the >> allocation policy should be for those registries. The allocation >> policy choices are described in RFC 2434: "Guidelines for Writing an >> IANA Considerations Section". > > The former is fine to put in the specs now. It's the later we could wait > on. > > Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From luigi@net.t-labs.tu-berlin.de Thu Sep 17 21:53: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 CD78A3A6857 for ; Thu, 17 Sep 2009 21:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_53=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 FJ0D5vK7P515 for ; Thu, 17 Sep 2009 21:53:47 -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 BAA673A6907 for ; Thu, 17 Sep 2009 21:53:46 -0700 (PDT) Received: from [192.168.2.101] (p4FC253D6.dip.t-dialin.net [79.194.83.214]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 61DDB7067A97; Fri, 18 Sep 2009 06:54:38 +0200 (CEST) Message-Id: <988A52ED-1805-4615-BB2D-24FE464E0080@net.t-labs.tu-berlin.de> From: Luigi Iannone 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: Fri, 18 Sep 2009 06:54:37 +0200 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] #16: map versioning/data plane consensus call X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 04:53:47 -0000 On Sep 17, 2009, at 15:00 , Sam Hartman wrote: > Darrel and I have discussed the resolution of the map versioning > proposal. > > At this point, the WG has not received a request to adopt Luigi's > draft, although he indicated we might receive such a request in the > future. > Before the request, there will be a new draft that, hopefully, will trigger new discussion. Then, depending on the discussion, there could be a request. > The chairs believe that we'd need to see somewhat more support for a > specific proposal than we've seen for map versioning to date in order > to adopt that proposal. Yes, and we are not yet there... > If we did receive sufficient support to adopt > something as a WG draft, assigning the flag would be easy. > > The question of whether something belongs in the data plane seems to > be all over the map. Dino has indicated that he wants to see this in > the control plane. Margaret wants to pursue the path of using short > TTLs and mechanisms to refresh TTLs before they expire. Luigi of > course wants to see some sort of map versioning in the data plane. Looks like we need to select only one solution. Why? Since the WG is for experimental purposes, we should provide something sufficiently open to make experimentations. Which means that we can include all of the above solutions, just pay attention to create something coherent. Then, operational experience will say which solution is better than the other. (Incidentally, I do not believe there _one_ solution that fits all, rather it really depends on the context/scenario) > We > definitely don't have consensus today,but we also don't have consensus > to rule things out. I think we may be revisiting the question of what > belongs in the data plane when we get more data. What about waiting the I issue the new map versioning draft, before re- opening the discussion on this subject? Luigi > > Meanwhile I think we can close out this issue as no consensus. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From damien.saucez@uclouvain.be Fri Sep 18 00:19: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 C222B3A6926 for ; Fri, 18 Sep 2009 00:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.809 X-Spam-Level: X-Spam-Status: No, score=-3.809 tagged_above=-999 required=5 tests=[AWL=-1.210, 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 Gktr8KegUilg for ; Fri, 18 Sep 2009 00:19:08 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 4EF043A6AB6 for ; Fri, 18 Sep 2009 00:18:49 -0700 (PDT) Received: from [130.104.228.15] (sleipnier-lite.dhcp.info.ucl.ac.be [130.104.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 4F14D1C5B90; Fri, 18 Sep 2009 09:19:34 +0200 (CEST) Message-ID: <4AB33485.5050000@uclouvain.be> Date: Fri, 18 Sep 2009 09:19:33 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 4F14D1C5B90.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 07:19:10 -0000 Sam Hartman wrote: > Folks, we've had some discussion on issue #5 regarding LISP protocol > versioning. It's quite clear that we don't have consensus behind any > specific proposal at the moment. > > However I've starting to see vague support behind doing something in > this space. In particular, we have Margaret's LISP format proposal, > which was discussed under #16. Damien made a different proposal--to > actually have an ordered set of versions. noel seems to support > something especially in terms of control plane negotiation. > > Dino raised an objection against Damien's proposal that you don't want > to have multiple round trips of negotiation. As far as I can tell, > Damien's proposal doesn't suffer from the issue Dino is concerned > about. In particular, the only form of negotiation he had is that the > sender let you know what version he supported, often before you sent a > packet to the sender. > > Yes, we do not really need negotiation. The first time a packet has to be exchanged between A and B, a Map-Request has to be sent. For the example, we will consider 1 packet from A to B and then a packet from B to A. Consider A runs version 42 of the LISP protocol and B runs version 666. 1. A sends a Map-Request. 2. A receives a Map-Reply for B's EIDs: in the mapping, the LISP protocol version is 666 3. A sees that version is 666 but she only supports up to 42 4. A sends a data packet to B with protocol version 42 and a field indicates this protocol version number. 5. When B want to send a packet to A. Two solutions: 6a. B sends a Map-Request for A. 7a. The Map-Reply for A's EID is with protocol version number 42 6b. B has a data gleaning entry for A with protocol version field 42 7b. NOP 8. B sees that version is 42 then, even if B supports versions up to 666, she will decide to use version 42 only. 9. B sends a data packet to A with protocol version 42 and a field indicates this protocol version number. That's it! The negotiation is half-implicit ( ;-) ) And no extra delay is required. The previous mails was just to show that protocol version must be in the data packets if we want to avoid extra delay due to explicit negotiation. Regards, Damien Saucez > I'd encourage those interested in seeing forward progress on this > issue to get together and see if they can form a concrete proposal. > It may turn out that we don't know enough to turn this into something > concrete. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Fri Sep 18 00:44: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 697C83A69A4 for ; Fri, 18 Sep 2009 00:44:56 -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 BuVaw1KAyzwx for ; Fri, 18 Sep 2009 00:44:55 -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 5D1403A6B05 for ; Fri, 18 Sep 2009 00:44:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANLXskqrR7PD/2dsb2JhbAC7TohQAZArBYI8gWA X-IronPort-AV: E=Sophos;i="4.44,408,1249257600"; d="scan'208";a="243651075" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 18 Sep 2009 07:45:46 +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 n8I7jkJA031334; Fri, 18 Sep 2009 00:45:46 -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 n8I7jkuZ029265; Fri, 18 Sep 2009 07: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); Fri, 18 Sep 2009 00:45:45 -0700 Received: from [192.168.1.2] ([10.21.75.139]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 00:45:45 -0700 Message-Id: From: Dino Farinacci To: Damien Saucez In-Reply-To: <4AB33485.5050000@uclouvain.be> 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, 18 Sep 2009 00:45:45 -0700 References: <4AB33485.5050000@uclouvain.be> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Sep 2009 07:45:45.0551 (UTC) FILETIME=[07E6EDF0:01CA3834] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5538; t=1253259946; x=1254123946; 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#5=3A=20LISP=20protocol=20vers ion=20is=20alive=20and=20kicking |Sender:=20; bh=g7tpsYgXpLspemzlXLsjWz6OnlsbAvXg7r9v1e5qkUU=; b=jiCsJ84sp9xVxqtOiflBG3NkfWzBUqd9bep6fo+rbyMTYiXzCkyDK2aK3Q cPXeu4zRM4lyAt71Fk+H1HPUOZbNLE0tXgzEqdkDv143cR4jBhz7c8pGCw8R FzIIIBwBk3; 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] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 07:44:56 -0000 Are we talking about mapping versions or protocol versions. This is very confusing. My comment about negotiation was about protocol versions. I object to protocol versions because they can be implemented with a new UDP port number of a new LISP control packet type in port number 4342. The statement below "A runs version 42 of the LISP protocol ..." is misleading. So let me comment below as if you are talking about mapping updates. > Sam Hartman wrote: >> Folks, we've had some discussion on issue #5 regarding LISP protocol >> versioning. It's quite clear that we don't have consensus behind any >> specific proposal at the moment. >> >> However I've starting to see vague support behind doing something in >> this space. In particular, we have Margaret's LISP format proposal, >> which was discussed under #16. Damien made a different proposal--to >> actually have an ordered set of versions. noel seems to support >> something especially in terms of control plane negotiation. >> >> Dino raised an objection against Damien's proposal that you don't >> want >> to have multiple round trips of negotiation. As far as I can tell, >> Damien's proposal doesn't suffer from the issue Dino is concerned >> about. In particular, the only form of negotiation he had is that >> the >> sender let you know what version he supported, often before you >> sent a >> packet to the sender. >> >> > Yes, we do not really need negotiation. The first time a packet has > to be exchanged between A and B, a Map-Request has to be sent. For > the example, we will consider 1 packet from A to B and then a packet > from B to A. Consider A runs version 42 of the LISP protocol and B > runs version 666. > > 1. A sends a Map-Request. > 2. A receives a Map-Reply for B's EIDs: in the mapping, the LISP > protocol version is 666 When A receives a Map-Reply from B, it gets the latest version. > 3. A sees that version is 666 but she only supports up to 42 > 4. A sends a data packet to B with protocol version 42 and a field > indicates this protocol version number. > 5. When B want to send a packet to A. Two solutions: > > 6a. B sends a Map-Request for A. You don't have to do this. When A sent the initial Map-Request, the mapping was present for A. B can just verify it by sending a Map- Request back. > 7a. The Map-Reply for A's EID is with protocol version number 42 > > > 6b. B has a data gleaning entry for A with protocol version field 42 > 7b. NOP > > 8. B sees that version is 42 then, even if B supports versions up to > 666, she will decide to use version 42 only. > 9. B sends a data packet to A with protocol version 42 and a field > indicates this protocol version number. > > That's it! The negotiation is half-implicit ( ;-) ) And no extra > delay is required. > > The previous mails was just to show that protocol version must be in > the data packets if we want to avoid extra delay due to explicit > negotiation. This is a long description to make this point: o Putting a mapping version number in a data packet is useful to tell an ETR when an ITR has an old mapping. o This is useful because PTRs encapsulate packets to ETRs. But ETRs never return traffic to them so ETRs don't and can't have mappings for the PTRs (because PTRs don't have database-mapping entries since they are only encapsulators). So ETRs cannot send SMR-based Map-Requests to them. o So the PTR can only tell the ETR to update it when the ETR finds out it has an old mapping. That is the only and best use for version numbers in a data packet. And as Noel said, you only want to use versions when you want to support multiple variants of the mapping at one time. That's not necessary so a checksum is sufficient so the PTR can tell the ETR it has something different than the ETR does. And of course, the ETR always has the most current information because it owns it and is authoritative for it. So if mapping updates don't happen often, why do mapping version numbers or checksums have to go in every data packet? That is the crux of the argument. If you say that the mapping version number can go in some packets versus others. That means the PTR is asking at its own defined frequency for updates. So if it can do that, it can do it in the control plane. It can do that with Map-Requests, and if it sends Map-Requests, it gets path liveness detection at the same time. That is why I suggest using RLOC- Probes. So if you are sensitive to RLOC-Probes and say putting the request in a data-packet would be cheaper, then you have to deal with idle sources, and you still have the overhead of a Map-Reply returning. Having said all this, my conclusion is that doing this in the control- plane gives you more flexibility and is not dependent on data frequency or behavior. Dino > > Regards, > > Damien Saucez > >> I'd encourage those interested in seeing forward progress on this >> issue to get together and see if they can form a concrete proposal. >> It may turn out that we don't know enough to turn this into something >> concrete. >> _______________________________________________ >> 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 damien.saucez@uclouvain.be Fri Sep 18 01:55: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 9838A3A6958 for ; Fri, 18 Sep 2009 01:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-1.059, 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 b8MAKospp1VA for ; Fri, 18 Sep 2009 01:55:44 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 317AF3A6995 for ; Fri, 18 Sep 2009 01:55:44 -0700 (PDT) Received: from [130.104.228.15] (sleipnier-lite.dhcp.info.ucl.ac.be [130.104.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 9EACDE927A; Fri, 18 Sep 2009 10:56:09 +0200 (CEST) Message-ID: <4AB34B27.9050306@uclouvain.be> Date: Fri, 18 Sep 2009 10:56:07 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Dino Farinacci References: <4AB33485.5050000@uclouvain.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 9EACDE927A.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 08:55:45 -0000 Dino, I am talking about protocol version (e.g., the build release of the protocol), not the version of the mappping. Dino Farinacci wrote: > Are we talking about mapping versions or protocol versions. This is > very confusing. My comment about negotiation was about protocol versions. mine too. > I object to protocol versions because they can be implemented with a > new UDP port number of a new LISP control packet type in port number > 4342. > I don't like the idea that the port give the version if you support several version, you consume several ports. If every body does like this, will face the port exhaustion rapidly and have the same problem that we have today with IPv4 address exhaustion. I am convinced that the cost of reserving 8 bits for a protocol version field is a cost that we can afford. > The statement below "A runs version 42 of the LISP protocol ..." is > misleading. > > So let me comment below as if you are talking about mapping updates. > sure, but I was not discussing mapping versions ;-) >> Sam Hartman wrote: >>> Folks, we've had some discussion on issue #5 regarding LISP protocol >>> versioning. It's quite clear that we don't have consensus behind any >>> specific proposal at the moment. >>> >>> However I've starting to see vague support behind doing something in >>> this space. In particular, we have Margaret's LISP format proposal, >>> which was discussed under #16. Damien made a different proposal--to >>> actually have an ordered set of versions. noel seems to support >>> something especially in terms of control plane negotiation. >>> >>> Dino raised an objection against Damien's proposal that you don't want >>> to have multiple round trips of negotiation. As far as I can tell, >>> Damien's proposal doesn't suffer from the issue Dino is concerned >>> about. In particular, the only form of negotiation he had is that the >>> sender let you know what version he supported, often before you sent a >>> packet to the sender. >>> >>> >> Yes, we do not really need negotiation. The first time a packet has >> to be exchanged between A and B, a Map-Request has to be sent. For >> the example, we will consider 1 packet from A to B and then a packet >> from B to A. Consider A runs version 42 of the LISP protocol and B >> runs version 666. >> >> 1. A sends a Map-Request. >> 2. A receives a Map-Reply for B's EIDs: in the mapping, the LISP >> protocol version is 666 > > When A receives a Map-Reply from B, it gets the latest version. > ok >> 3. A sees that version is 666 but she only supports up to 42 >> 4. A sends a data packet to B with protocol version 42 and a field >> indicates this protocol version number. >> 5. When B want to send a packet to A. Two solutions: >> >> 6a. B sends a Map-Request for A. > > You don't have to do this. When A sent the initial Map-Request, the > mapping was present for A. B can just verify it by sending a > Map-Request back. > what if B itr and B etr are disjoint? >> 7a. The Map-Reply for A's EID is with protocol version number 42 >> >> >> 6b. B has a data gleaning entry for A with protocol version field 42 >> 7b. NOP >> >> 8. B sees that version is 42 then, even if B supports versions up to >> 666, she will decide to use version 42 only. >> 9. B sends a data packet to A with protocol version 42 and a field >> indicates this protocol version number. >> >> That's it! The negotiation is half-implicit ( ;-) ) And no extra >> delay is required. >> >> The previous mails was just to show that protocol version must be in >> the data packets if we want to avoid extra delay due to explicit >> negotiation. > > This is a long description to make this point: > I don't agree, because we are not discussing the same thing. I put an example to answer Sam's mail and to confirm he was right. But I listen for your remark on map versioning that are interesting, even if it is another context. > o Putting a mapping version number in a data packet is useful to tell > an ETR when an ITR has an > old mapping. > > o This is useful because PTRs encapsulate packets to ETRs. But ETRs > never return traffic to them so > ETRs don't and can't have mappings for the PTRs (because PTRs don't > have database-mapping entries > since they are only encapsulators). So ETRs cannot send SMR-based > Map-Requests to them. > > o So the PTR can only tell the ETR to update it when the ETR finds out > it has an old mapping. > > That is the only and best use for version numbers in a data packet. > And as Noel said, you only want to use versions when you want to > support multiple variants of the mapping at one time. That's not > necessary so a checksum is sufficient so the PTR can tell the ETR it > has something different than the ETR does. And of course, the ETR > always has the most current information because it owns it and is > authoritative for it. > > So if mapping updates don't happen often, why do mapping version > numbers or checksums have to go in every data packet? That is the crux > of the argument. Yes, but when they happen, how to know the change ASAP? > > If you say that the mapping version number can go in some packets > versus others. That means the PTR is asking at its own defined > frequency for updates. > > So if it can do that, it can do it in the control plane. It can do > that with Map-Requests, and if it sends Map-Requests, it gets path > liveness detection at the same time. That is why I suggest using > RLOC-Probes. > > So if you are sensitive to RLOC-Probes and say putting the request in > a data-packet would be cheaper, then you have to deal with idle > sources, and you still have the overhead of a Map-Reply returning. > > Having said all this, my conclusion is that doing this in the > control-plane gives you more flexibility and is not dependent on data > frequency or behavior. > agree, it only depends the overhead you are ready to accept. But let me turn the argument back to you and ask: "so, why do not move the status bits in the control plane and remove them of the dataplane?" Thanks, Damien Saucez > Dino > >> >> Regards, >> >> Damien Saucez >> >>> I'd encourage those interested in seeing forward progress on this >>> issue to get together and see if they can form a concrete proposal. >>> It may turn out that we don't know enough to turn this into something >>> concrete. >>> _______________________________________________ >>> 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 dino@cisco.com Fri Sep 18 02:18: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 E85423A698A for ; Fri, 18 Sep 2009 02:18:51 -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 JTdlyStBfpS5 for ; Fri, 18 Sep 2009 02:18:50 -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 1C78D3A69C9 for ; Fri, 18 Sep 2009 02:18:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ7tskqrR7O6/2dsb2JhbAC7A4hQAZAoBYI8gWCBXQ X-IronPort-AV: E=Sophos;i="4.44,408,1249257600"; d="scan'208";a="190647032" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 18 Sep 2009 09:19:42 +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 n8I9JgTW019256; Fri, 18 Sep 2009 02:19: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 n8I9Jgnr004440; Fri, 18 Sep 2009 09:19:42 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); Fri, 18 Sep 2009 02:19:42 -0700 Received: from [192.168.1.2] ([10.21.75.139]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 02:19:42 -0700 Message-Id: <3D7528B4-3586-4531-8A34-65DD9929C4B2@cisco.com> From: Dino Farinacci To: Damien Saucez In-Reply-To: <4AB34B27.9050306@uclouvain.be> 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, 18 Sep 2009 02:19:41 -0700 References: <4AB33485.5050000@uclouvain.be> <4AB34B27.9050306@uclouvain.be> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Sep 2009 09:19:42.0222 (UTC) FILETIME=[279EAAE0:01CA3841] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8499; t=1253265582; x=1254129582; 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]=20#5=3A=20LISP=20protocol=20vers ion=20is=20alive=20and=20kicking |Sender:=20; bh=08ZUSJp4Yf9JwPnhXil3BiAUeZ61PB1baVFfnrdx1g8=; b=jhEj4uOu4IE+qMSIyCmPfSUcoPUvUj9e+mCHV2u+ZiV5yj5v35M9WsJ0KS Es6UHuGc7RGRpErNnxWBHi6keiKP48zFPUU3L6bZ4lWvJoram6g6EDUQaWw8 DsDboCuD5g; 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] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 09:18:52 -0000 > Dino, > > I am talking about protocol version (e.g., the build release of the > protocol), not the version of the mappping. > > Dino Farinacci wrote: >> Are we talking about mapping versions or protocol versions. This is >> very confusing. My comment about negotiation was about protocol >> versions. > mine too. >> I object to protocol versions because they can be implemented with >> a new UDP port number of a new LISP control packet type in port >> number 4342. >> > I don't like the idea that the port give the version if you support > several version, you consume several ports. If every body does like > this, will face the port exhaustion rapidly and have the same > problem that we have today with IPv4 address exhaustion. I am > convinced that the cost of reserving 8 bits for a protocol version > field is a cost that we can afford. But a version number is no different than a new type value for a control packet. If you encoded Map-Request, you just allocate a new type value. >> The statement below "A runs version 42 of the LISP protocol ..." is >> misleading. >> >> So let me comment below as if you are talking about mapping updates. >> > sure, but I was not discussing mapping versions ;-) Okay. So save my response for Luigi. ;-) >>> Sam Hartman wrote: >>>> Folks, we've had some discussion on issue #5 regarding LISP >>>> protocol >>>> versioning. It's quite clear that we don't have consensus behind >>>> any >>>> specific proposal at the moment. >>>> >>>> However I've starting to see vague support behind doing something >>>> in >>>> this space. In particular, we have Margaret's LISP format >>>> proposal, >>>> which was discussed under #16. Damien made a different proposal-- >>>> to >>>> actually have an ordered set of versions. noel seems to support >>>> something especially in terms of control plane negotiation. >>>> >>>> Dino raised an objection against Damien's proposal that you don't >>>> want >>>> to have multiple round trips of negotiation. As far as I can tell, >>>> Damien's proposal doesn't suffer from the issue Dino is concerned >>>> about. In particular, the only form of negotiation he had is >>>> that the >>>> sender let you know what version he supported, often before you >>>> sent a >>>> packet to the sender. >>>> >>>> >>> Yes, we do not really need negotiation. The first time a packet >>> has to be exchanged between A and B, a Map-Request has to be sent. >>> For the example, we will consider 1 packet from A to B and then a >>> packet from B to A. Consider A runs version 42 of the LISP >>> protocol and B runs version 666. >>> >>> 1. A sends a Map-Request. >>> 2. A receives a Map-Reply for B's EIDs: in the mapping, the LISP >>> protocol version is 666 >> >> When A receives a Map-Reply from B, it gets the latest version. >> > ok >>> 3. A sees that version is 666 but she only supports up to 42 >>> 4. A sends a data packet to B with protocol version 42 and a field >>> indicates this protocol version number. >>> 5. When B want to send a packet to A. Two solutions: >>> >>> 6a. B sends a Map-Request for A. >> >> You don't have to do this. When A sent the initial Map-Request, the >> mapping was present for A. B can just verify it by sending a Map- >> Request back. >> > what if B itr and B etr are disjoint? If ITR-only A sends a Map-Request with its own mapping data to ETR- only B, B can send a verifying Map-Request back. There is no reason why an *ETR* can't send a Map-Request. >>> 7a. The Map-Reply for A's EID is with protocol version number 42 >>> >>> >>> 6b. B has a data gleaning entry for A with protocol version field 42 >>> 7b. NOP >>> >>> 8. B sees that version is 42 then, even if B supports versions up >>> to 666, she will decide to use version 42 only. >>> 9. B sends a data packet to A with protocol version 42 and a field >>> indicates this protocol version number. >>> >>> That's it! The negotiation is half-implicit ( ;-) ) And no extra >>> delay is required. >>> >>> The previous mails was just to show that protocol version must be >>> in the data packets if we want to avoid extra delay due to >>> explicit negotiation. >> >> This is a long description to make this point: >> > I don't agree, because we are not discussing the same thing. I put > an example to answer Sam's mail and to confirm he was right. But I > listen for your remark on map versioning that are interesting, even > if it is another context. Sure, but for protocol versioning, you are exchanging the protocol version for every mapping transaction. That is redundant and not necessary. If A is running version 42 and B is running version 666, why does it need to ask this for every Map-Request exchange. It might lead one to believe the protocol versions *could be* different per EID being requested. Don't think that was your intent. So the point is, the versioning exchange is too granular. >> o Putting a mapping version number in a data packet is useful to >> tell an ETR when an ITR has an >> old mapping. >> >> o This is useful because PTRs encapsulate packets to ETRs. But ETRs >> never return traffic to them so >> ETRs don't and can't have mappings for the PTRs (because PTRs >> don't have database-mapping entries >> since they are only encapsulators). So ETRs cannot send SMR-based >> Map-Requests to them. >> >> o So the PTR can only tell the ETR to update it when the ETR finds >> out it has an old mapping. >> >> That is the only and best use for version numbers in a data packet. >> And as Noel said, you only want to use versions when you want to >> support multiple variants of the mapping at one time. That's not >> necessary so a checksum is sufficient so the PTR can tell the ETR >> it has something different than the ETR does. And of course, the >> ETR always has the most current information because it owns it and >> is authoritative for it. >> >> So if mapping updates don't happen often, why do mapping version >> numbers or checksums have to go in every data packet? That is the >> crux of the argument. > Yes, but when they happen, how to know the change ASAP? It you are RLOC-probing once a minute for liveness, I think getting one-minute granularity for a mapping update is pretty darn good/fast. For going faster, you use the techniques in draft-meyer-lisp-mn-00.txt. But stationary LISP sites don't need the LISP-MN techniques. >> If you say that the mapping version number can go in some packets >> versus others. That means the PTR is asking at its own defined >> frequency for updates. >> >> So if it can do that, it can do it in the control plane. It can do >> that with Map-Requests, and if it sends Map-Requests, it gets path >> liveness detection at the same time. That is why I suggest using >> RLOC-Probes. >> >> So if you are sensitive to RLOC-Probes and say putting the request >> in a data-packet would be cheaper, then you have to deal with idle >> sources, and you still have the overhead of a Map-Reply returning. >> >> Having said all this, my conclusion is that doing this in the >> control-plane gives you more flexibility and is not dependent on >> data frequency or behavior. >> > agree, it only depends the overhead you are ready to accept. But let > me turn the argument back to you and ask: "so, why do not move the > status bits in the control plane and remove them of the dataplane?" Because status bit changes you might want to reflect faster than mapping update changes. Up/down transitions happen more often than mapping updates. Plus with the L-bit, you can turn them off now. Dino > > Thanks, > > Damien Saucez >> Dino >> >>> >>> Regards, >>> >>> Damien Saucez >>> >>>> I'd encourage those interested in seeing forward progress on this >>>> issue to get together and see if they can form a concrete proposal. >>>> It may turn out that we don't know enough to turn this into >>>> something >>>> concrete. >>>> _______________________________________________ >>>> 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 dino@cisco.com Fri Sep 18 02:22: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 F34FD3A6922 for ; Fri, 18 Sep 2009 02:22:15 -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 wd4ddZ1ULY-J for ; Fri, 18 Sep 2009 02:22:15 -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 1AD0A3A68EC for ; Fri, 18 Sep 2009 02:22:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFPuskqrR7PE/2dsb2JhbAC6fIhQAZAoBYQc X-IronPort-AV: E=Sophos;i="4.44,408,1249257600"; d="scan'208";a="391297125" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 18 Sep 2009 09:23:09 +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 n8I9N8CJ011756; Fri, 18 Sep 2009 02:23:08 -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 n8I9N8SG017974; Fri, 18 Sep 2009 09:23:08 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, 18 Sep 2009 02:23:08 -0700 Received: from [192.168.1.2] ([10.21.75.139]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 02:23:08 -0700 Message-Id: <60C488C6-2681-43E7-B656-6D16FDF83FF7@cisco.com> From: Dino Farinacci To: Dino Farinacci In-Reply-To: <3D7528B4-3586-4531-8A34-65DD9929C4B2@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: Fri, 18 Sep 2009 02:23:07 -0700 References: <4AB33485.5050000@uclouvain.be> <4AB34B27.9050306@uclouvain.be> <3D7528B4-3586-4531-8A34-65DD9929C4B2@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Sep 2009 09:23:08.0068 (UTC) FILETIME=[A2504640:01CA3841] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=340; t=1253265788; x=1254129788; 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#5=3A=20LISP=20protocol=20vers ion=20is=20alive=20and=20kicking |Sender:=20; bh=VDENC/IudV2diW9VN0+jNLXEMo4cWBA9tLe/vwnmZgc=; b=bQ4glOszN+j3NjgI9WjcUUhyu3UxwWd+VQMxk7g4Fw98JIrUOJJaW5UFnj A3BtvrlwAq+LKm7pVkm2e+3RV1VigDJ7CJ0AxEgNoDponMab/0d1SQlb3cnT o/INewWKiD; 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] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 09:22:16 -0000 > But a version number is no different than a new type value for a > control packet. If you encoded Map-Request, you just allocate a new > type value. This wasn't clear. I meant if you wanted to encode a newly format Map- Request, you just allocate a new Type value for packets that get encoded in UDP 4342 messages. Dino From jmh@joelhalpern.com Fri Sep 18 05:53: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 2C0CC3A69BA for ; Fri, 18 Sep 2009 05:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 qCixsFJumZwd for ; Fri, 18 Sep 2009 05:53: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 522DE3A67A8 for ; Fri, 18 Sep 2009 05:53:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9F10F43035C; Fri, 18 Sep 2009 05:54:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id C841643035E; Fri, 18 Sep 2009 05:54:47 -0700 (PDT) Message-ID: <4AB38315.2000305@joelhalpern.com> Date: Fri, 18 Sep 2009 08:54:45 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Damien Saucez References: <4AB33485.5050000@uclouvain.be> In-Reply-To: <4AB33485.5050000@uclouvain.be> 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 is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 12:53:55 -0000 (Just in case it gets lost again, the topic is protocol versioning, not map versioning.) There are at least two loosely related issues when it comes to protocol versioning. Below, Damien is discussing, I believe, versioning of the data plane encapsulation. He argues that you need the version number in the data packet to avoid a round trip. I am not so sure. My comments follow his note. I believe what is needed is a data plane version number in the control protocol. The other question is whether we need to have versioning in the control plane protocol. This in turn has two pieces. There is the exchange between neighbors (ITR<->Map Server, ...) and the end-to-end map request itself. I think we are best to assume here that there is a single version of the protocol. There can be extensions (TLVs), but the basic structure better get fixed by the first time we release a PS. Otherwise, the mapping exchange itself starts to pick up extra round trips, and that is just a nightmare. Yours, Joel Damien Saucez wrote: ... > Yes, we do not really need negotiation. The first time a packet has to > be exchanged between A and B, a Map-Request has to be sent. For the > example, we will consider 1 packet from A to B and then a packet from B > to A. Consider A runs version 42 of the LISP protocol and B runs version > 666. > > 1. A sends a Map-Request. > 2. A receives a Map-Reply for B's EIDs: in the mapping, the LISP > protocol version is 666 > 3. A sees that version is 666 but she only supports up to 42 > 4. A sends a data packet to B with protocol version 42 and a field > indicates this protocol version number. > 5. When B want to send a packet to A. Two solutions: > > 6a. B sends a Map-Request for A. > 7a. The Map-Reply for A's EID is with protocol version number 42 > > > 6b. B has a data gleaning entry for A with protocol version field 42 > 7b. NOP > > 8. B sees that version is 42 then, even if B supports versions up to > 666, she will decide to use version 42 only. > 9. B sends a data packet to A with protocol version 42 and a field > indicates this protocol version number. > > That's it! The negotiation is half-implicit ( ;-) ) And no extra delay > is required. > > The previous mails was just to show that protocol version must be in the > data packets if we want to avoid extra delay due to explicit negotiation. ... If the original map request had A's data encapsulation version number, then when it arrived at B, B could then combine that information with A's support, and could compute the correct version number of the data encapsulation protocol to use between A and B. That information could be included in the map-reply. In theory, no indication of the data encapsulation version number is then needed in the protocol between A and B. In practice, if each data encapsulation version uses a different UDP port, this exchange tells the two parties what port and format to use for the data packets. And the exchange has to happen anyway. Hence, I do not see a need for an explicit data encapsulation version in the data encapsulation itself. If we remove the UPD encapsulation (for example on IPv6, depending upon the outcome of that ongoing and tedious discussion), then we have to decide whether, for robustness, we want a data encapsulation version indication in the data packets themselves. Whether the version number for the data plane protocol is a pair or is just a port number with an assumption that if you don't recognize the other guys port number, then yours is older and you should just use the older one, or some other mechanism, is a detail to be resolved. Yours, Joel From damien.saucez@uclouvain.be Fri Sep 18 09:22: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 2B1CF3A67F0 for ; Fri, 18 Sep 2009 09:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=-0.941, 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 obLENZ1LgLvi for ; Fri, 18 Sep 2009 09:22:25 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 6951628C1DE for ; Fri, 18 Sep 2009 09:22:25 -0700 (PDT) Received: from [130.104.228.15] (sleipnier-lite.dhcp.info.ucl.ac.be [130.104.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id B84D5F2443; Fri, 18 Sep 2009 18:23:23 +0200 (CEST) Message-ID: <4AB3B3F3.30303@uclouvain.be> Date: Fri, 18 Sep 2009 18:23:15 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Dino Farinacci References: <4AB33485.5050000@uclouvain.be> <4AB34B27.9050306@uclouvain.be> <3D7528B4-3586-4531-8A34-65DD9929C4B2@cisco.com> In-Reply-To: <3D7528B4-3586-4531-8A34-65DD9929C4B2@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: B84D5F2443.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 16:22:27 -0000 Dino Farinacci wrote: >> Dino, >> >> I am talking about protocol version (e.g., the build release of the >> protocol), not the version of the mappping. >> >> Dino Farinacci wrote: >>> Are we talking about mapping versions or protocol versions. This is >>> very confusing. My comment about negotiation was about protocol >>> versions. >> mine too. >>> I object to protocol versions because they can be implemented with a >>> new UDP port number of a new LISP control packet type in port number >>> 4342. >>> >> I don't like the idea that the port give the version if you support >> several version, you consume several ports. If every body does like >> this, will face the port exhaustion rapidly and have the same problem >> that we have today with IPv4 address exhaustion. I am convinced that >> the cost of reserving 8 bits for a protocol version field is a cost >> that we can afford. > > But a version number is no different than a new type value for a > control packet. If you encoded Map-Request, you just allocate a new > type value. > yes, but to avoid a RTT for negotiation, you also put it in the data packets. >>> The statement below "A runs version 42 of the LISP protocol ..." is >>> misleading. >>> >>> So let me comment below as if you are talking about mapping updates. >>> >> sure, but I was not discussing mapping versions ;-) > > Okay. So save my response for Luigi. ;-) > ;-) >>>> Sam Hartman wrote: >>>>> Folks, we've had some discussion on issue #5 regarding LISP protocol >>>>> versioning. It's quite clear that we don't have consensus behind any >>>>> specific proposal at the moment. >>>>> >>>>> However I've starting to see vague support behind doing something in >>>>> this space. In particular, we have Margaret's LISP format proposal, >>>>> which was discussed under #16. Damien made a different proposal--to >>>>> actually have an ordered set of versions. noel seems to support >>>>> something especially in terms of control plane negotiation. >>>>> >>>>> Dino raised an objection against Damien's proposal that you don't >>>>> want >>>>> to have multiple round trips of negotiation. As far as I can tell, >>>>> Damien's proposal doesn't suffer from the issue Dino is concerned >>>>> about. In particular, the only form of negotiation he had is that >>>>> the >>>>> sender let you know what version he supported, often before you >>>>> sent a >>>>> packet to the sender. >>>>> >>>>> >>>> Yes, we do not really need negotiation. The first time a packet has >>>> to be exchanged between A and B, a Map-Request has to be sent. For >>>> the example, we will consider 1 packet from A to B and then a >>>> packet from B to A. Consider A runs version 42 of the LISP protocol >>>> and B runs version 666. >>>> >>>> 1. A sends a Map-Request. >>>> 2. A receives a Map-Reply for B's EIDs: in the mapping, the LISP >>>> protocol version is 666 >>> >>> When A receives a Map-Reply from B, it gets the latest version. >>> >> ok >>>> 3. A sees that version is 666 but she only supports up to 42 >>>> 4. A sends a data packet to B with protocol version 42 and a field >>>> indicates this protocol version number. >>>> 5. When B want to send a packet to A. Two solutions: >>>> >>>> 6a. B sends a Map-Request for A. >>> >>> You don't have to do this. When A sent the initial Map-Request, the >>> mapping was present for A. B can just verify it by sending a >>> Map-Request back. >>> >> what if B itr and B etr are disjoint? > > If ITR-only A sends a Map-Request with its own mapping data to > ETR-only B, B can send a verifying Map-Request back. There is no > reason why an *ETR* can't send a Map-Request. > yes, you can optimize and then send a map-request in prevention of future traffic if you know that you will be the iTR for the packets back to A, so why not using the data gleaning? >>>> 7a. The Map-Reply for A's EID is with protocol version number 42 >>>> >>>> >>>> 6b. B has a data gleaning entry for A with protocol version field 42 >>>> 7b. NOP >>>> >>>> 8. B sees that version is 42 then, even if B supports versions up >>>> to 666, she will decide to use version 42 only. >>>> 9. B sends a data packet to A with protocol version 42 and a field >>>> indicates this protocol version number. >>>> >>>> That's it! The negotiation is half-implicit ( ;-) ) And no extra >>>> delay is required. >>>> >>>> The previous mails was just to show that protocol version must be >>>> in the data packets if we want to avoid extra delay due to explicit >>>> negotiation. >>> >>> This is a long description to make this point: >>> >> I don't agree, because we are not discussing the same thing. I put an >> example to answer Sam's mail and to confirm he was right. But I >> listen for your remark on map versioning that are interesting, even >> if it is another context. > > Sure, but for protocol versioning, you are exchanging the protocol > version for every mapping transaction. That is redundant and not > necessary. If A is running version 42 and B is running version 666, > why does it need to ask this for every Map-Request exchange. > > It might lead one to believe the protocol versions *could be* > different per EID being requested. Don't think that was your intent. > So the point is, the versioning exchange is too granular. > no I don't want this. That's true that you only this info in the map-request and in the first packet that arrives the ETR. But, how can you detect (from the iTR place) when the first packet is arrived the ETR as the first packet at the ETR may be only the second or the third from the ITR due to loss. >>> o Putting a mapping version number in a data packet is useful to >>> tell an ETR when an ITR has an >>> old mapping. >>> >>> o This is useful because PTRs encapsulate packets to ETRs. But ETRs >>> never return traffic to them so >>> ETRs don't and can't have mappings for the PTRs (because PTRs don't >>> have database-mapping entries >>> since they are only encapsulators). So ETRs cannot send SMR-based >>> Map-Requests to them. >>> >>> o So the PTR can only tell the ETR to update it when the ETR finds >>> out it has an old mapping. >>> >>> That is the only and best use for version numbers in a data packet. >>> And as Noel said, you only want to use versions when you want to >>> support multiple variants of the mapping at one time. That's not >>> necessary so a checksum is sufficient so the PTR can tell the ETR it >>> has something different than the ETR does. And of course, the ETR >>> always has the most current information because it owns it and is >>> authoritative for it. >>> >>> So if mapping updates don't happen often, why do mapping version >>> numbers or checksums have to go in every data packet? That is the >>> crux of the argument. >> Yes, but when they happen, how to know the change ASAP? > > It you are RLOC-probing once a minute for liveness, I think getting > one-minute granularity for a mapping update is pretty darn good/fast. > For going faster, you use the techniques in draft-meyer-lisp-mn-00.txt. I think that we will never answer this question perfectly. You suggest that mapping can be wrong for a while (let say 1 minute). With Luigi and the mapping versioning, we suggest to reduce the inconsistency time down to the minimum. The choice will be a tradeoff: what is the requirements of the operators? > > But stationary LISP sites don't need the LISP-MN techniques. > >>> If you say that the mapping version number can go in some packets >>> versus others. That means the PTR is asking at its own defined >>> frequency for updates. >>> >>> So if it can do that, it can do it in the control plane. It can do >>> that with Map-Requests, and if it sends Map-Requests, it gets path >>> liveness detection at the same time. That is why I suggest using >>> RLOC-Probes. >>> >>> So if you are sensitive to RLOC-Probes and say putting the request >>> in a data-packet would be cheaper, then you have to deal with idle >>> sources, and you still have the overhead of a Map-Reply returning. >>> >>> Having said all this, my conclusion is that doing this in the >>> control-plane gives you more flexibility and is not dependent on >>> data frequency or behavior. >>> >> agree, it only depends the overhead you are ready to accept. But let >> me turn the argument back to you and ask: "so, why do not move the >> status bits in the control plane and remove them of the dataplane?" > > Because status bit changes you might want to reflect faster than > mapping update changes. Up/down transitions happen more often than > mapping updates. Plus with the L-bit, you can turn them off now. but status bit is just a hint, you still have to check if it is true, otherwise you have a very simple DoS attack with a single packet. Damien Saucez > > Dino > >> >> Thanks, >> >> Damien Saucez >>> Dino >>> >>>> >>>> Regards, >>>> >>>> Damien Saucez >>>> >>>>> I'd encourage those interested in seeing forward progress on this >>>>> issue to get together and see if they can form a concrete proposal. >>>>> It may turn out that we don't know enough to turn this into something >>>>> concrete. >>>>> _______________________________________________ >>>>> 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 damien.saucez@uclouvain.be Fri Sep 18 09:38: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 E723A3A6452 for ; Fri, 18 Sep 2009 09:38:27 -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.847, 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 L5SD7c-bsVwm for ; Fri, 18 Sep 2009 09:38:27 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id AB7DA3A6873 for ; Fri, 18 Sep 2009 09:38:26 -0700 (PDT) Received: from [130.104.228.15] (sleipnier-lite.dhcp.info.ucl.ac.be [130.104.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id BC6361C5CCE; Fri, 18 Sep 2009 18:39:13 +0200 (CEST) Message-ID: <4AB3B7B3.6080206@uclouvain.be> Date: Fri, 18 Sep 2009 18:39:15 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4AB33485.5050000@uclouvain.be> <4AB38315.2000305@joelhalpern.com> In-Reply-To: <4AB38315.2000305@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: BC6361C5CCE.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 16:38:28 -0000 Joel M. Halpern wrote: > (Just in case it gets lost again, the topic is protocol versioning, > not map versioning.) > There are at least two loosely related issues when it comes to > protocol versioning. > Below, Damien is discussing, I believe, versioning of the data plane > encapsulation. He argues that you need the version number in the data > packet to avoid a round trip. I am not so sure. My comments follow > his note. I believe what is needed is a data plane version number in > the control protocol. yes, but then you need an extra rtt for the negotiation. Do not forget that the place where the Map-Request is processed and the place where the packet will effectively arrive may not be the same. > > The other question is whether we need to have versioning in the > control plane protocol. This in turn has two pieces. There is the > exchange between neighbors (ITR<->Map Server, ...) and the end-to-end > map request itself. I think we are best to assume here that there is > a single version of the protocol. There can be extensions (TLVs), but > the basic structure better get fixed by the first time we release a > PS. Otherwise, the mapping exchange itself starts to pick up extra > round trips, and that is just a nightmare. I agree for the nightmare. Please, don't forget that the WG is focused on experimentation of different solutions. With a protocol version number, we can thus tests different solutions to see which are the best. When the best protocol will be found, then we'll remove this extra field. Do we really need to care about legacy in this WG? > > Yours, > Joel > > Damien Saucez wrote: > ... >> Yes, we do not really need negotiation. The first time a packet has >> to be exchanged between A and B, a Map-Request has to be sent. For >> the example, we will consider 1 packet from A to B and then a packet >> from B to A. Consider A runs version 42 of the LISP protocol and B >> runs version 666. >> >> 1. A sends a Map-Request. >> 2. A receives a Map-Reply for B's EIDs: in the mapping, the LISP >> protocol version is 666 >> 3. A sees that version is 666 but she only supports up to 42 >> 4. A sends a data packet to B with protocol version 42 and a field >> indicates this protocol version number. >> 5. When B want to send a packet to A. Two solutions: >> >> 6a. B sends a Map-Request for A. >> 7a. The Map-Reply for A's EID is with protocol version number 42 >> >> >> 6b. B has a data gleaning entry for A with protocol version field 42 >> 7b. NOP >> >> 8. B sees that version is 42 then, even if B supports versions up to >> 666, she will decide to use version 42 only. >> 9. B sends a data packet to A with protocol version 42 and a field >> indicates this protocol version number. >> >> That's it! The negotiation is half-implicit ( ;-) ) And no extra >> delay is required. >> >> The previous mails was just to show that protocol version must be in >> the data packets if we want to avoid extra delay due to explicit >> negotiation. > ... > > If the original map request had A's data encapsulation version number, > then when it arrived at B, B could then combine that information with > A's support, and could compute the correct version number of the data > encapsulation protocol to use between A and B. That information could > be included in the map-reply. > In theory, no indication of the data encapsulation version number is > then needed in the protocol between A and B. > In practice, if each data encapsulation version uses a different UDP > port, this exchange tells the two parties what port and format to use > for the data packets. And the exchange has to happen anyway. > Hence, I do not see a need for an explicit data encapsulation version > in the data encapsulation itself. If we remove the UPD encapsulation > (for example on IPv6, depending upon the outcome of that ongoing and > tedious discussion), then we have to decide whether, for robustness, > we want a data encapsulation version indication in the data packets > themselves. > I believe that we are going in a wrong direction with the trend of adding more and more state. I do prefer having redundant information (the same info that may not be used if a packet has already been received) than having to keep state and then build a complex control protocol to maintain all this state coherent. Do we really need to make the LISP header as smaller as possible for the sacrosanct MTU? > Whether the version number for the data plane protocol is a pair number to use, relative version> or is just a port number with an > assumption that if you don't recognize the other guys port number, > then yours is older and you should just use the older one, or some > other mechanism, is a detail to be resolved. > I personally don't like the idea of having one port number per version. Again, if every protocol does that, the port space will be exhausted rapidly. I understand that from an implementation point of view a port number is easier, the check is implicitly done on the port number by a UDP classifier and you do not need to change the old implementations, just add the new one that will listen the new port. Damien Saucez > Yours, > Joel > > > From dino@cisco.com Fri Sep 18 10:14: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 465EA3A6965 for ; Fri, 18 Sep 2009 10:14: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 NYVQIDFqLkgT for ; Fri, 18 Sep 2009 10:14:41 -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 14CDD3A6A14 for ; Fri, 18 Sep 2009 10:14:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGtds0qrR7PD/2dsb2JhbAC2aIhQAZAaBYQbgV0 X-IronPort-AV: E=Sophos;i="4.44,410,1249257600"; d="scan'208";a="243863507" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 18 Sep 2009 17:15:35 +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 n8IHFZPk025130; Fri, 18 Sep 2009 10:15:35 -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 n8IHFZx6007686; Fri, 18 Sep 2009 17:15:35 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 10:15:35 -0700 Received: from [192.168.1.2] ([10.21.86.177]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 10:15:34 -0700 Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AB38315.2000305@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: Fri, 18 Sep 2009 10:11:19 -0700 References: <4AB33485.5050000@uclouvain.be> <4AB38315.2000305@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Sep 2009 17:15:34.0961 (UTC) FILETIME=[A260E210:01CA3883] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4182; t=1253294135; x=1254158135; 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#5=3A=20LISP=20protocol=20vers ion=20is=20alive=20and=20kicking |Sender:=20; bh=jdfKw6YohUGoCIU+U/DpUTtHxub0ttPq5bA+xHXTM48=; b=Cvq4oT7GdCl/xFIhMJrL6TmFxrMpmsJVma9PaxAYuEng+7nffe90M2LIZM 7TA3XM0e9SEn8zgA56HFhCvjj+I8J7oQ1psJ9ysC5Z8Z2SZMrJfgTxFBj3E+ 0f/EaZglNu; 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] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 17:14:42 -0000 Good post IMO. Agree on all counts. Dino On Sep 18, 2009, at 5:54 AM, Joel M. Halpern wrote: > (Just in case it gets lost again, the topic is protocol versioning, > not map versioning.) > There are at least two loosely related issues when it comes to > protocol versioning. > Below, Damien is discussing, I believe, versioning of the data plane > encapsulation. He argues that you need the version number in the > data packet to avoid a round trip. I am not so sure. My comments > follow his note. I believe what is needed is a data plane version > number in the control protocol. > > The other question is whether we need to have versioning in the > control plane protocol. This in turn has two pieces. There is the > exchange between neighbors (ITR<->Map Server, ...) and the end-to- > end map request itself. I think we are best to assume here that > there is a single version of the protocol. There can be extensions > (TLVs), but the basic structure better get fixed by the first time > we release a PS. Otherwise, the mapping exchange itself starts to > pick up extra round trips, and that is just a nightmare. > > Yours, > Joel > > Damien Saucez wrote: > ... >> Yes, we do not really need negotiation. The first time a packet has >> to be exchanged between A and B, a Map-Request has to be sent. For >> the example, we will consider 1 packet from A to B and then a >> packet from B to A. Consider A runs version 42 of the LISP protocol >> and B runs version 666. >> 1. A sends a Map-Request. >> 2. A receives a Map-Reply for B's EIDs: in the mapping, the LISP >> protocol version is 666 >> 3. A sees that version is 666 but she only supports up to 42 >> 4. A sends a data packet to B with protocol version 42 and a field >> indicates this protocol version number. >> 5. When B want to send a packet to A. Two solutions: >> 6a. B sends a Map-Request for A. >> 7a. The Map-Reply for A's EID is with protocol version number 42 >> 6b. B has a data gleaning entry for A with protocol version field 42 >> 7b. NOP >> 8. B sees that version is 42 then, even if B supports versions up >> to 666, she will decide to use version 42 only. >> 9. B sends a data packet to A with protocol version 42 and a field >> indicates this protocol version number. >> That's it! The negotiation is half-implicit ( ;-) ) And no extra >> delay is required. >> The previous mails was just to show that protocol version must be >> in the data packets if we want to avoid extra delay due to explicit >> negotiation. > ... > > If the original map request had A's data encapsulation version > number, then when it arrived at B, B could then combine that > information with A's support, and could compute the correct version > number of the data encapsulation protocol to use between A and B. > That information could be included in the map-reply. > In theory, no indication of the data encapsulation version number is > then needed in the protocol between A and B. > In practice, if each data encapsulation version uses a different > UDP port, this exchange tells the two parties what port and format > to use for the data packets. And the exchange has to happen anyway. > Hence, I do not see a need for an explicit data encapsulation > version in the data encapsulation itself. If we remove the UPD > encapsulation (for example on IPv6, depending upon the outcome of > that ongoing and tedious discussion), then we have to decide > whether, for robustness, we want a data encapsulation version > indication in the data packets themselves. > > Whether the version number for the data plane protocol is a pair > or is just a port number with > an assumption that if you don't recognize the other guys port > number, then yours is older and you should just use the older one, > or some other mechanism, is a detail to be resolved. > > Yours, > Joel > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Fri Sep 18 10:36: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 4829E3A68A4 for ; Fri, 18 Sep 2009 10:36:12 -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=[AWL=0.001, 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 xmVcfpCIEjjN for ; Fri, 18 Sep 2009 10:36:11 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 26F343A68C8 for ; Fri, 18 Sep 2009 10:36:10 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D479B6BE56E; Fri, 18 Sep 2009 13:37:04 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090918173704.D479B6BE56E@mercury.lcs.mit.edu> Date: Fri, 18 Sep 2009 13:37:04 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 17:36:12 -0000 > From: Damien Saucez >> I believe what is needed is a data plane version number in the >> control protocol. > but then you need an extra rtt for the negotiation. No; if the map entry has a bit that says 'this ETR supports version 2', and the ITR understands that bit and has support for version 2, it can send version 2 packets right away. There's no delay - at least, any more than you need to get the mapping itself (and clearly you can't send anything anywhere without the mapping). A bigger issue with versions, _no matter how you support them_ (field in the header, port, mapping, whatever), is compatability. Either all nodes have keep support for old versions essentially forever, or you might get pairwise non-communication. I do not have time to analyze this fully at the moment, though. > With a protocol version number, we can thus tests different > solutions to see which are the best. If it's really just a limited experiment, you can use a different port number, or set a header bit (we have several spares), or use a currently-illegal combination of header flag bits (if you need a whole different header format, on the same port), or something. The protocol police aren't going to come arrest you for sending packets with unauthorized bits set. > Do we really need to care about legacy in this WG? For right now, no. But for the future, yes, and some decisions we are making now will have an impact for a long time. (Been there, done that...) > I believe that we are going in a wrong direction with the trend of > adding more and more state. See http://mercury.lcs.mit.edu/~jnc/tech/end_end.html, in particular the section at the end headed "Network State". I am reminded of Abraham Lincoln's astute answer to the question 'How long should a person's legs be?' His answer: 'Long enough to reach the ground.' Yes, state _is_ 'bad' architecturally, in that if you don't have it, things stop working. So then you have to deal with that. But if we have to have state to reach some goal, we have to have it - and pay the cost of getting it, maintaining it, etc, etc. > I do prefer having redundant information ... than having to keep > state and then build a complex control protocol to maintain all this > state coherent. I think we have to look at each case on its merits, and look at the details. In this particular case, we already _have_ to have the mappings, and the whole system to distribute them, etc, etc so adding more data field(s) to the mapping is a 'so what' to me. > Do we really need to make the LISP header as smaller as possible for > the sacrosanct MTU? It's not just the sheer size. A bigger header is a more complicated header, which means it's slower to construct, and to process, and we pay that price on _every user data packet_. > if every protocol does that, the port space will be exhausted > rapidly. Yes, but I think basic data carriage (like IPvN, LISP, etc) is a whole different 'kettle of fish', in terms of design philosophy, from applications, for a number of reasons which I assume are fairly obvious. Noel From darlewis@cisco.com Fri Sep 18 11:11: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 A3EDC3A6B75 for ; Fri, 18 Sep 2009 11:11:59 -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 Axzpof+VbRbB for ; Fri, 18 Sep 2009 11:11:58 -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 9F8113A684A for ; Fri, 18 Sep 2009 11:11:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE9qs0qrR7PD/2dsb2JhbAC2dIhQAZAcBYQb X-IronPort-AV: E=Sophos;i="4.44,410,1249257600"; d="scan'208";a="206171679" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 18 Sep 2009 18:12:53 +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 n8IICrDU014338 for ; Fri, 18 Sep 2009 11:12:53 -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 n8IICr4p002144 for ; Fri, 18 Sep 2009 18:12:53 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); Fri, 18 Sep 2009 11:12:52 -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, 18 Sep 2009 11:12:51 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LISP Interworking: Proxy Egress Tunnel Routers Thread-Index: Aco4i6L3UIL7OZ7XTF6XDcR475rRdg== From: "Darrel Lewis (darlewis)" To: X-OriginalArrivalTime: 18 Sep 2009 18:12:52.0977 (UTC) FILETIME=[A3987E10:01CA388B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3008; t=1253297573; x=1254161573; 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:=20LISP=20Interworking=3A=20=20Proxy=20Egress=20Tu nnel=20Routers |Sender:=20; bh=GV4+yPGxAvhvWqJL3bgQBrHxaUJp0Sf+h++tkxtFxIo=; b=gA4j8bVzdLXGisZMJeM6oK+qMtwqm/gGhv68qVEqXSHp76Y5O8wEwUrLnn zuWwJj0rHosXwiyvrBvLVoMoIgDmyJugyb3YBrqFIMRfoByIAwAY7ADzOhY9 opTELa7GD1; Authentication-Results: sj-dkim-3; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 18:11:59 -0000 Way back in San Francisco, at the LISP meeting/BoF, I presented my thoughts about the status of the Interworking draft. One of the items was about a concept that had been talked about in the hallways called Proxy Egress Tunnel Routers (or PETRs for short). To be clear, in this email I'm speaking as an editor of the Interworking draft, rather than as WG co-chair. To review, today a LISP ITR does not encapsulate packets when the destination is a non-LISP site. This is because the destination is a routable address and in theory the destination field of the packet is the only field required to be routable. However, in the case of an xTR being on a customer premise router, this requires that the IP protocol version of the hosts be supported by the access network, and that the access network not be implicitly filtering the EID source via uRPF or some similar mechanism. What I'd like to propose is a Proxy ETR that LISP sites would use to when encapsulating packets which are destined to non-LISP sites. ITRs could be statically configured with a 'default' map-cache entry that would encapsulate to the Proxy ETR. The PETR could/should be configured to only decapsulate and forward packets for EID prefixes that the PETR owner/operator agrees to. Proxy ETRs would remain independent of Proxy ITRs, while technically they could be implemented in the same device, they serve different purposes. In order to minimize stretch on communications between LISP and non-LISP sites, its very likely that they should be located in separate places in the topology. Below is a very short blurb of some text to foster some discussion about Proxy Egress Tunnel Routers: Proxy Egress Tunnel Routers (PETRs) allow for LISP-NR sites to communicate with non-LISP sites in the case where the access network does not allow for the LISP-NR site send packets with the source address of the site's EID(s). A PETR is a new network element that conceptually acts as an ETR for traffic destined to non-LISP sites. This also has the effect of allowing an ITR avoid having to decide whether to encapsulate packets or not - it will always encapsulate packets. Packets destined to LISP sites will travel directly to that site's ETR, all other packets will be sent to the site's PETR. There are two primary reasons why sites would want to utilize a PETR: Avoiding strict uRPF failures: Some provider's access networks require the source of the packets emitted to be within the addressing scope of the access networks. (see section 9) Traversing a different IP Protocol: A LISP site may want to transmit packets to a non-LISP site where the some of the intermediate network does not support an IP protocol (v4 or v6). PETRs can allow this LISP site's data to 'hop over' this by utilizing LISP's support for mixed protocol encapsulation. Comments appreciated! Regards, -Darrel From darlewis@cisco.com Fri Sep 18 12:20: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 8E8B53A6890 for ; Fri, 18 Sep 2009 12:20:47 -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 VaUFRYcN2-FE for ; Fri, 18 Sep 2009 12:20: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 CD27E3A6851 for ; Fri, 18 Sep 2009 12:20:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPh6s0qrR7PE/2dsb2JhbAC2cIhQAZAOBYQb X-IronPort-AV: E=Sophos;i="4.44,411,1249257600"; d="scan'208";a="391611498" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 18 Sep 2009 19:21:41 +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 n8IJLfXk006828 for ; Fri, 18 Sep 2009 12:21:41 -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 n8IJLfTg014779 for ; Fri, 18 Sep 2009 19:21:41 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); Fri, 18 Sep 2009 12:21:41 -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, 18 Sep 2009 12:21:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Jumpstarting discussion on draft-ietf-lisp-05 Thread-Index: Aco4lT9SiXwoIqfyQcyontMWSTZE9w== From: "Darrel Lewis (darlewis)" To: X-OriginalArrivalTime: 18 Sep 2009 19:21:41.0518 (UTC) FILETIME=[4065DAE0:01CA3895] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=947; t=1253301701; x=1254165701; c=relaxed/simple; s=sjdkim4002; 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:=20Jumpstarting=20discussion=20on=20draft-ietf-lis p-05 |Sender:=20; bh=k4drGWE9Iu2LOieGh0m1mb49Si3iaTopCLWjy6RE5Bg=; b=NSMq+JqMLvitihMi4l07SlKsrBNcXb/Bh+cvqODQbXZCC6XWmjWGe5ghfQ cJrh9GX7BEFReeKKSndD2/CcPKGJIMdSpeiWWMGZu7sUZeMeCu9Z35Vy8PYH 670TLJ8uo4; Authentication-Results: sj-dkim-4; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [lisp] Jumpstarting discussion on draft-ietf-lisp-05 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 19:20:47 -0000 The WG chairs would like to encourage people to voice ideas for changes to this draft on the WG list. Sam and I believe that we can be more efficient in guiding the development of the next version of this draft, and would like to ask the working group to help us. We ask that when discussing issues that you try to find consensus in principle prior to word-smithing the grammar of a particular proposal. Once the chairs determine that this basic technical consensus is reached we can guide the draft editors on which particular revision of the draft that the issue(s) could be best integrated within. =20 So by all means, if you have suggestions, ideas, or concerns about LISP, please voice these on the list! We'd like to encourage, in general, more smaller releases of revisions targeted in the weeks/month time frame rather than single large sets of changes every three to six months. -Darrel Lewis LISP WG co-chair From hartmans@mit.edu Fri Sep 18 13:50: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 652FC3A6986 for ; Fri, 18 Sep 2009 13:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 i0mw5pg73wQr for ; Fri, 18 Sep 2009 13:50: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 93B4B3A6965 for ; Fri, 18 Sep 2009 13:50:43 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3971C51BB; Fri, 18 Sep 2009 16:51:29 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Fri, 18 Sep 2009 16:51: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 Subject: [lisp] A number of issues I'm not bringing up X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 18 Sep 2009 20:50:44 -0000 Speaking as an individual. So, there are a number of issues I'm holding onto and explicitly not bringing to the list. That's generally a fairly bad sign in terms of confidence in the process so I thought I'd share my reasons. 1) Many issues depend on understanding deployment. It's my belief that we have made and are making decisions that seem internally inconsistent--for example decisions that only make sense if all LISP devices are placed near the core of the network while making other decisions that only make sense if some LISP devices are placed very near the edge. I'm trying to identify these inconsistencies, but it doesn't make sense to bring them forward until we have a discussion about deployment. Darrel has an action item that will hopefully bootstrap that process. 2) Understanding security. Many decisions we're making seem to open us up to a number of attacks that other parts of the IETF have considered serious when evaluating similar technologies. We need to begin to have a discussion of our security model--particularly on the data plane and the parts of the mapping system close to the XTRs before it makes sense to discuss these. IN particular, the LISP WG needs to become informed about what the rest of the IETF has done in this space and why, both to have common terminology about attacks as well as to intelligently agree or disagree with the conclusions of the IETF. 3) The WG is not yet large enough for serious consideration of significantly divergent opinion. We have a fairly small WG at this point. We don't have a fairly good representation from the internet area, transport area, or IETF at large here. A lot of issues I might want to bring up would wedge us fairly fast into a situation where a minority thought one thing, and a majority thought another. In my judgment there would not be much chance of building an informed consensus one way or another. We need to pull in more people from all around the IETF if we're going to be successful. If we don't, I suspect that I and others will be bringing up large architectural issues during IETF-wide last call. That won't be fun for anyone. However I'm going to introduce an issue at the point where I think it has the highest chance of being seriously considered; doing otherwise involves way too much tilting at windmills. From rw@firstpr.com.au Fri Sep 18 22:10: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 015BC3A6950 for ; Fri, 18 Sep 2009 22:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKwnev7IEkzt for ; Fri, 18 Sep 2009 22:10:27 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 4E28A3A68E7 for ; Fri, 18 Sep 2009 22:10:26 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 7DA08175A4D; Sat, 19 Sep 2009 15:11:20 +1000 (EST) Message-ID: <4AB467FC.5070606@firstpr.com.au> Date: Sat, 19 Sep 2009 15:11:24 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers (PETRs) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 19 Sep 2009 05:10:29 -0000 Short version: Similarities and differences between LISP PETRs and the Translating Tunnel Router in the TTR Mobility model. What are the scenarios for a LISP node needing a PETR? What sort of network and last mile link are these nodes on? How will the node and PETR cope with Path MTU Discovery and lost packets? Hi Darrel, The first function you list for Proxy ETRs: > Avoiding strict uRPF failures: Some provider's access networks > require the source of the packets emitted to be within the > addressing scope of the access networks. (see section 9) is a function performed by the TTR (Translating Tunnel Router) in the TTR Mobility model: http://www.firstpr.com.au/ip/ivip/#mobile The MN (Mobile Node) could be on a global unicast address in some network which, quite correctly, won't allow egress of packets with a source address not matching this network. Also, the MN may be behind one or more layers of NAT. As with PETR, the TTR is located in a network which allows it to emit packets with any source address. Unlike the PETR, the TTR also acts as an ETR for the MN. The MN may have multiple such TTRs and therefore multiple such ETRs. I understand that this concept of LISP nodes in access networks which therefore need a PETR outside that network (or at least a PETR in the network which is authorised to emit packets with any source address) resembles the LISP Mobile arrangement. AFAIK, you haven't specified the commercial relationship between the operator of the LISP node and the operator of the PETR which it uses. Do you plan to have provision for two or more PETRs, for redundancy? I understand that the concept of a PETR is quite separate from that of the one or more ETRs a LISP node may be using. For LISP nodes which need a PETR, does the LISP node perform its own ETR function? If so, how does this differ from the LISP Mobile arrangement? In the TTR model - a TTR always performs the ETR function for a MN. Whether or not any packets for that MN arrive at that TTR depends on the mapping. In the PETR model, I understand the LISP node simply encapsulates packets to send to the PETR, and that it only does this for packets which are being sent to non-LISP destinations. This differs from the TTR model in that MNs send all outgoing packets to the TTR. The PETR only receives packets from LISP nodes which are addressed to non-LISP addresses. So there is no need for the PETR to contain or be close to an ITR. In the TTR model (whether applied to Ivip or LISP), the MN has no involvement mapping. It never tunnels packets to anywhere but its one or more TTRs and it has no concept of some destination addresses being "normal" and others being on addresses which are mapped by the core-edge separation system (LISP, Ivip or whatever). The MN sends all outgoing packets to its TTR, or to one of its one or more TTRs. For this reason, the TTR is ideally "close" to the MN, such as 1000 km or less. The system will still work if the TTR and MN are on opposite sides of the Earth, but generally, for efficiency and lower latency, the MN will choose a TTR which is nearby. I understand that you are proposing the PETR approach for non-mobile LISP nodes. I guess this is similar to the PETR proposal which is part of LISP Mobile. With non-mobile LISP nodes, you could configure each node to use a nearby PETR. The TTR would typically contain, or be close to, an ITR function, but this is not absolutely required. If it emitted packets which were addressed to hosts which were on mapped addresses (RLOC addresses for LISP, "mapped addresses" for Ivip) then if the TTR had no ITR and was not near one, then the packets would traverse the DFZ until they were encapsulated by a PTR (Proxy Tunnel Router, for LISP) or OITRD (Open ITR in the DFZ, for Ivip). In LISP, I understand you will be specifying an encapsulation format, or using one which already exists for these traffic packets being sent to the PETRs. In the TTR model, at least for Ivip, I haven't specified exactly how the MN communicates with the TTR. Since the MN will only be communicating with a TTR which accepts this communication, typically on some authorised commercial basis, there is no absolute need to standardise exactly how the communication occurs. One TTR company might have one way of doing it and another might have a different approach. This would require different software in the MN, but that's OK. There's plenty of scope for innovation and optimising the protocols to cope with various types of traffic, types of MN and types of access network. Since the MN <--> TTR communication is a private matter between the two parties, there isn't an absolute need for the IETF to standardise a single approach. I propose that the MN establish a two-way encrypted tunnel to the TTR, which it can do from any address, including behind NAT. Then, it is up to the the company which runs the TTRs and defines the protocols how to handle Path MTU Discovery problems, encryption, compression, resending lost packets etc. There could be a single IETF defined set of protocols for all this, but it is not needed, at least initially, since the MN to TTR arrangement is a private one. The TTR behaves to the rest of the core-edge separation network as firstly an ordinary ETR and secondly as a source of outgoing traffic packets. The TTR can include a ITR function, but the TTR simply behaves as an ETR and perhaps an ITR - so the TTR itself doesn't require any special provisions in the technical standards for the core-edge separation system (Ivip, LISP or whatever). Your second function: > Traversing a different IP Protocol: A LISP site may want to > transmit packets to a non-LISP site where the some of the > intermediate network does not support an IP protocol (v4 or > v6). PETRs can allow this LISP site's data to 'hop over' > this by utilizing LISP's support for mixed protocol > encapsulation. is not part of the current TTR model. Adding a mixed protocol capability to a core-edge separation scheme may well be a good idea. I am concentrating on defining a good scheme for each protocol in isolation, but mixed protocol operations should definitely be contemplated well before the systems are finalised. Can you list the sorts of scenarios in which the LISP node would be using a PETR? Must the LISP node be on a global unicast address, or can it be behind one or more layers of NAT? Do you expect the LISP node to be connected to the Net via a slow, expensive and unreliable last mile link such as a wireless mobile network? Even if the link is not expensive, high packet loss rates may require special provisions which were not anticipated in the original concept of LISP: ITRs and ETRs being at ISP sites with permanent, fibre-based connections, with ISP networks being conventionally multihomed with BGP. How do you plan to cope with PMTUD and packet loss problems between the LISP node and the PETR? How does the LISP node ensure that the PETR is still alive? As far as I can see, any solution to these two problems would involve two-way communication between the LISP node and its PETR, rather than a simple send and forget approach. These problems may be easier to solve in the TTR model because the MN creates its own encrypted tunnel, which includes its own packet acknowledgement retry arrangements and could presumably handle PMTUD methods by chopping packets down to the PMTU limit discovered for the tunnel, and reassembling them at the other end of the tunnel, with the tunnel protocol already supporting resending of lost packets which contain those fragments. - Robin From jnc@mercury.lcs.mit.edu Sat Sep 19 10:17: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 8F2E73A69E7 for ; Sat, 19 Sep 2009 10:17:25 -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=[AWL=0.001, 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 vbAP1hupOc6d for ; Sat, 19 Sep 2009 10:17: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 722A73A6896 for ; Sat, 19 Sep 2009 10:17:24 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 746426BE628; Sat, 19 Sep 2009 13:18:20 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090919171820.746426BE628@mercury.lcs.mit.edu> Date: Sat, 19 Sep 2009 13:18:20 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 19 Sep 2009 17:17:25 -0000 > From: Robin Whittle > AFAIK, you haven't specified the commercial relationship between the > operator of the LISP node and the operator of the PETR which it uses. Right, but obvious commercial arrangements are outside the IETF scope. If your point was that you can't see that there will be any economically workable arrangement, that I think would be something that should concern us. As to that, I have no idea... > Do you plan to have provision for two or more PETRs, for redundancy? You mean, 'would each non-LISP destination site be served by two or more PETRs'? Or did you mean 'would each LISP source site be served by two or more PETRs'? Because I think the original post said something about wanting PETRs scattered around the system, to minimize extra hops. If a PETR is close to either the source, or the destination, it will minimize the path length. Which model you pick probably depends on the economic relationship; i.e. whether a PETR is associated with a source, or a destination. For the former, you'd want it close to the source so it can serve multiple destinations without increased path length, and vice versa for the other relationship. Anyway, getting back to your original point, the system should _allow_ either, but I'm not sure it should _mandate_ anything. > I understand that the concept of a PETR is quite separate from that of > the one or more ETRs a LISP node may be using. For LISP nodes which > need a PETR, does the LISP node perform its own ETR function? The terminology may be a little confusing. PETRs serve non-LISP destinations, i.e. they only handle traffic flowing from a LISP site, to a non-LISP site. The ETR of a LISP site would, instead, be associated with traffic coming to the LISP site. How the ETR service for the LISP node is handled is not something this proposal needs to cover. > In the PETR model, I understand the LISP node simply encapsulates > packets to send to the PETR The 'LISP node' might be either i) a LISP site, in which unmodified hosts are sending packet to an ITR which is doing the LISP encapsulation, or ii) some other source of LISP-encapsulated packets. Again, the detail there, of where the LISP-encapsulated packets are coming from, is not something this proposal needs to cover. > The PETR only receives packets from LISP nodes which are addressed to > non-LISP addresses. Right. > So there is no need for the PETR to contain or be close to an ITR. That would likely depend on the economic model/relationship between the PETR, the non-LISP hosts being served, and the source of the LISP-encapsulated traffic - see the comment above about PETR placement. > Can you list the sorts of scenarios in which the LISP node would be > using a PETR? I'm not sure an exhaustive list is possible. It's just a pretty basic, generic building block, and those kind of things tend to get used in many ways that were not forseen. As to a list of possible/plausible ones, Darrel's original message gave two, perhaps others can come up with more? > Must the LISP node be on a global unicast address, or can it be behind > one or more layers of NAT? Again, the term "LISP node" confuses me a little - are you talking of the original source of the packets, or the ITR, or what? The ITR will have to have a global unicast address, but that does not prevent it being behind a NAT - it just has to figure out what the _NAT_'s global unicast address is, and register that as the RLOC associated with the EIDs which which that ITR is responsible. > Do you expect the LISP node to be connected to the Net via a slow, > expensive and unreliable last mile link such as a wireless mobile > network? I don't think we're making any assumptions about the kind of link it will have. Like I said, it's a pretty generic building block, and will likely be used in many different ways. > How do you plan to cope with PMTUD and packet loss problems between the > LISP node and the PETR? The same way we would between the ITR and any other ETR, I would assume. > How does the LISP node ensure that the PETR is still alive? That's an interesting point. Some of the techniques used to detect reachability/liveness of the ETR won't necessarily work with PETRs. E.g. unless a PETR is co-located in the same box as a PITR, there won't be any reverse user-data traffic to piggyback nonces on. However, reachability/liveness testing does fall back to explicit probing, when none of the other mechanisms are giving a positive signal, so there will be a backstop. And some of the other ones might work (e.g. PITR/PETR colocation), there's no way to know about a particular configuration until it's examined. Noel From rw@firstpr.com.au Sat Sep 19 21:05: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 742D13A68CF for ; Sat, 19 Sep 2009 21:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fyp0t2ktlq+2 for ; Sat, 19 Sep 2009 21:05:18 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id D28253A6921 for ; Sat, 19 Sep 2009 21:05:17 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id EBA00175D27; Sun, 20 Sep 2009 14:06:14 +1000 (EST) Message-ID: <4AB5AA3C.5090805@firstpr.com.au> Date: Sun, 20 Sep 2009 14:06:20 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: lisp@ietf.org References: <20090919171820.746426BE628@mercury.lcs.mit.edu> In-Reply-To: <20090919171820.746426BE628@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Noel Chiappa Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 20 Sep 2009 04:05:20 -0000 Short version: What are the business models for PETRs? When would PETRs be used? Darrel's text mentions "LISP-NR" sites, but these are sites with EID addresses not covered by a PTR advertisement. I can't imagine why any end-user site would want to be a LISP-NR site, since this means that their hosts would unreachable from all non-LISP networks. PETRs have nothing much in common with ETRs. How can the ITR, or whatever it is which sends packets to the PETR, make sure the PETR is alive, getting most or all its packets and is able to handle them? Hi Noel, Thanks for your reply, in which you wrote: > > AFAIK, you haven't specified the commercial relationship between the > > operator of the LISP node and the operator of the PETR which it uses. > > Right, but obvious commercial arrangements are outside the IETF scope. If > your point was that you can't see that there will be any economically > workable arrangement, that I think would be something that should concern us. > As to that, I have no idea... I understand that specific business arrangements are not a matter for the IETF, but in developing a scalable routing proposal, we definitely need to plan the types of business relationships which we anticipate will develop to support the technical arrangements we are devising. I am not saying there isn't a viable business model for PETRs. I am just saying that I don't know what the business model is for PETRs and that I think that at least one seemingly viable model should be proposed before the whole PETR concept is accepted. > > Do you plan to have provision for two or more PETRs, for redundancy? > > You mean, 'would each non-LISP destination site be served by two or more > PETRs'? Or did you mean 'would each LISP source site be served by two or more > PETRs'? The latter, since any PETR can send packets to all non-LISP sites. > Because I think the original post said something about wanting PETRs > scattered around the system, to minimize extra hops. If a PETR is close to > either the source, or the destination, it will minimize the path length. Darrel wrote: In order to minimize stretch on communications between LISP and non-LISP sites, its very likely that they should be located in separate places in the topology. but there is no reference to the location of PETRs in the text he proposed for discussion. Since the typical situation is for a given source to be sending packets to destinations all around the Net, the only way to minimise stretch (longer total packet paths than would be required without the PETR) is to locate the PETR close to the source. So my question was whether a given LISP site using PETRs would have two or more of them. Implicitly, it would be best if they were close to the site. This raises questions about business models. Since the purpose of LISP or any other core-edge separation solution to the routing scaling problem is to allow each end-user network to keep its address range and use any ISP in the world, if the PETR is outside its current ISP and needs to be "close", then we need to think about business arrangements by which the site chooses one or more PETRs. Part of this involves the possibility of two or more PETRs, both ideally nearby (but not absolutely necessarily nearby) which are operated by different companies and therefore are likely to be different networks - to provide some network-level and business-level redundancy. The network-level redundancy is obvious. The business-level redundancy is to do with what happens if there is an administrative glitch, or the operator of the PETR decides the site hasn't paid its bill. The business arrangements for the TTR model are discussed in: http://www.firstpr.com.au/ip/ivip/#mobile TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem Robin Whittle, Steven Russert 2008-08-25 > Which model you pick probably depends on the economic relationship; i.e. > whether a PETR is associated with a source, or a destination. For the former, > you'd want it close to the source so it can serve multiple destinations > without increased path length, and vice versa for the other relationship. Yes - I can't see any sense in having multiple PETRs distant from the LISP site, with the LISP site's router having to choose between them for packets depending on the physical location of the destination of those packets. > Anyway, getting back to your original point, the system should _allow_ > either, but I'm not sure it should _mandate_ anything. I imagine the LISP PETR specification will allow all sorts of things, but the key thing is to show the desired arrangements are attractive from both technical and business perspectives. > > I understand that the concept of a PETR is quite separate from that of > > the one or more ETRs a LISP node may be using. For LISP nodes which > > need a PETR, does the LISP node perform its own ETR function? > > The terminology may be a little confusing. PETRs serve non-LISP destinations, > i.e. they only handle traffic flowing from a LISP site, to a non-LISP site. > The ETR of a LISP site would, instead, be associated with traffic coming to > the LISP site. How the ETR service for the LISP node is handled is not > something this proposal needs to cover. OK. > > In the PETR model, I understand the LISP node simply encapsulates > > packets to send to the PETR > > The 'LISP node' might be either i) a LISP site, in which unmodified hosts are > sending packet to an ITR which is doing the LISP encapsulation, or ii) some > other source of LISP-encapsulated packets. Again, the detail there, of where > the LISP-encapsulated packets are coming from, is not something this proposal > needs to cover. I don't understand either i) or ii). I think the PETR specification needs to identify when PETRs would be needed and when not. As part of this it should give some principles and ideally examples of the sorts of "LISP-node", "LISP-site" or whatever which will be sending packets to the PETR. > > The PETR only receives packets from LISP nodes which are addressed to > > non-LISP addresses. > > Right. OK. > > So there is no need for the PETR to contain or be close to an ITR. > > That would likely depend on the economic model/relationship between the PETR, > the non-LISP hosts being served, and the source of the LISP-encapsulated > traffic - see the comment above about PETR placement. OK. > > Can you list the sorts of scenarios in which the LISP node would be > > using a PETR? > > I'm not sure an exhaustive list is possible. It's just a pretty basic, > generic building block, and those kind of things tend to get used in many > ways that were not forseen. As to a list of possible/plausible ones, Darrel's > original message gave two, perhaps others can come up with more? Darrel's messages gave two purposes, or functions to be performed. I think it would help me and other people if there were some specific examples of when PETRs would be needed. If there are multiple types of scenario when they are needed, it would be good to have two or more examples of each kind of scenario, together with a more formal definition of the scenario. Without this, the discussion inevitably becomes messy since I and others are trying to imagine why the main LISP developers want PETRs - but are probably getting it wrong because the developers have not yet clearly explained, with examples, when they would be needed. > > Must the LISP node be on a global unicast address, or can it be behind > > one or more layers of NAT? > > Again, the term "LISP node" confuses me a little - are you talking of > the original source of the packets, or the ITR, or what? A am asking about whatever it is which is sending packets to the PETR. I see the term "LISP-NR" is used - but I didn't know what this meant. http://tools.ietf.org/html/draft-ietf-lisp-interworking-00 LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are EIDs only, these EIDs are not found in the legacy Internet routing table. So to me, this means addresses used by an end-user network where the addresses are LISP-mapped, and will be handled by ITRs in the sending network, and tunneled to the ETR of the end-user network, wherever it is - *and* that this address range is not covered by an advertisement by an Proxy Tunnel Router. (If it was in a PTR advertisement, then these EID addresses used by the end-user network would be encompassed by one of the BGP-advertised prefixes.) This makes no sense to me. Why would anyone adopt LISP-mapped addresses without them being covered by PTRs? To do so would mean that these addresses are only reachable from hosts in networks with ITRs. This contrasts with another definition: LISP Routable (LISP-R) Site: A LISP site whose addresses are used as both globally routable IP addresses and LISP EIDs. To me, this means a LISP site with EID addresses which are covered by PTR advertisements. This is the only way I imagine anyone might want to adopt LISP-mapped addresses, since the PTRs are the only way their hosts would be reachable from hosts in networks without ITRs. (In Ivip, all Ivip-mapped addresses are covered by OITRDs, which do the same job as PTRs.) So are PETRs really only needed for this subset of end-user networks which don't have their addresses covered by PTRs? If so, I would like to understand why - and why anyone thinks LISP would be adopted on this basis by any end-user networks. > The ITR will have to have a global unicast address, but that does not prevent > it being behind a NAT - it just has to figure out what the _NAT_'s global > unicast address is, and register that as the RLOC associated with the EIDs > which which that ITR is responsible. Is this formally specified anywhere yet? It seems unworkable to me that an ITR would have to figure out the address of its NAT box. What if it is behind multiple layers of NAT? I think there really needs to be a full description of why anyone expects a LISP ITR to be behind NAT - with all the business and technical reasons why this is the case. Having the ITR behind NAT violates one of the original principles of LISP, which is there in the very first I-D, I am sure, about ETRs and ITRs always being on "RLOC" global unicast addresses, not on "EID" addresses and implicitly not behind NAT, since behind NAT means their actual address is not global unicast. > > Do you expect the LISP node to be connected to the Net via a slow, > > expensive and unreliable last mile link such as a wireless mobile > > network? > > I don't think we're making any assumptions about the kind of link it will > have. Like I said, it's a pretty generic building block, and will likely be > used in many different ways. I think you need to make some specific examples. The original LISP concept did not anticipate ITRs being on slow, expensive or unreliable links. If this is being contemplated, it needs to be recognised clearly - and reasons given for this change. Then, this particular class of ITRs may require different arrangements for PMTUD, handling dropped packets etc. > > How do you plan to cope with PMTUD and packet loss problems between the > > LISP node and the PETR? > > The same way we would between the ITR and any other ETR, I would assume. Just because this new network element is called a Proxy ETR doesn't mean it has anything in common with an ordinary LISP ETR. With the original ETR concept, you knew it was either: 1 - In the network of the ISP which was one of the ISPs by which the end-user network is using for Internet access. or 2 - It is a Provider Edge router in the end-user network, right next to the ISP (but presumably at the end-user site, not at the ISP). I think there was ongoing debate about where ETRs were located and I don't recall it being settled either way. These PETRs do not in any way resemble ETRs. They are not at or near the destination end-user network and they are not in a business sense associated with any destination end-user network. They are, I suggest, more likely to be close to and in a business sense associated with the end-user network which is sending packets. With the basic ETR concept, if the ETR is dead, this means (for a multihomed destination end-user site) that each sending ITRs somehow discover this and then decides to tunnel packets to another ETR which is specified in the mapping. So with this basic concept of an ETR, the ITR is not generally concerned about two-way communication to make sure all packets it tunnels to it are received. If a PETR is dead, this has nothing to do with mapping or any particular end-user site. The ITR really needs to be sure all the packets (or almost all of them) it tunnels to the PETR are received there and that the PETR can handle them properly. A PETR failure is not at all like an ETR failure, since there is no mapping involved, no alternative ETR to choose etc. > > How does the LISP node ensure that the PETR is still alive? > > That's an interesting point. Some of the techniques used to detect > reachability/liveness of the ETR won't necessarily work with PETRs. E.g. > unless a PETR is co-located in the same box as a PITR, there won't be any > reverse user-data traffic to piggyback nonces on. OK - as I wrote above. > However, reachability/liveness testing does fall back to explicit probing, > when none of the other mechanisms are giving a positive signal, so there will > be a backstop. And some of the other ones might work (e.g. PITR/PETR > colocation), there's no way to know about a particular configuration until > it's examined. OK. - Robin From jnc@mercury.lcs.mit.edu Sat Sep 19 22:42: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 7B2273A68C6 for ; Sat, 19 Sep 2009 22:42:51 -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=[AWL=0.001, 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 LX4T6A6wDiHP for ; Sat, 19 Sep 2009 22:42:50 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 099E43A690C for ; Sat, 19 Sep 2009 22:42:49 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B23496BE575; Sun, 20 Sep 2009 01:43:46 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090920054346.B23496BE575@mercury.lcs.mit.edu> Date: Sun, 20 Sep 2009 01:43:46 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 20 Sep 2009 05:42:51 -0000 > From: Robin Whittle >> The ITR will have to have a global unicast address, but that does not >> prevent it being behind a NAT - it just has to figure out what the >> _NAT_'s global unicast address is, and register that as the RLOC >> associated with the EIDs which which that ITR is responsible. > Is this formally specified anywhere yet? Don't think so, but I'm not sure. > It seems unworkable to me that an ITR would have to figure out the > address of its NAT box. It's pretty easy, actually; if I'm remembering correctly, when a Map-Register message arrives at a Map-Server, you can tell from the fact that the source address in the outer IPvN header doesn't match the ITR's RLOC inside the packet that it's behind a NAT, and what the NAT's global address is. (Or something like that...) Noel From hartmans@mit.edu Sun Sep 20 08: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 314FC3A67E5 for ; Sun, 20 Sep 2009 08:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 vZPhDA0fjuIg for ; Sun, 20 Sep 2009 08:32:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 6D7B63A67B2 for ; Sun, 20 Sep 2009 08:32:23 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9D76251B0; Sun, 20 Sep 2009 11:33:09 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090919171820.746426BE628@mercury.lcs.mit.edu> From: Sam Hartman Date: Sun, 20 Sep 2009 11:33:09 -0400 In-Reply-To: <20090919171820.746426BE628@mercury.lcs.mit.edu> (Noel Chiappa's message of "Sat\, 19 Sep 2009 13\:18\:20 -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] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 20 Sep 2009 15:32:24 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Robin Whittle AFAIK, you haven't >> specified the commercial relationship between the operator of >> the LISP node and the operator of the PETR which it uses. Noel> Right, but obvious commercial arrangements are outside the Noel> IETF scope. If your point was that you can't see that there Noel> will be any economically workable arrangement, that I think Noel> would be something that should concern us. As to that, I Noel> have no idea... Noel, Dan and I have both commented on why many business model aspects are in scope here in terms of management, operability, and security. I understand there is a claim generally held to be true that business models are out of scope for the IETF. There are certainly aspects of that claim that are very true. However, deployment, management, operations and security are all very much in scope for this working group. As such, a large number of business relationship discussions are in scope, especially initially. It's possibl things may get out of hand, but let us start by being inclusive rather than trying to shut people down in the first couple messages of a thread. Sam Hartman LISP co-chair. From hartmans@mit.edu Mon Sep 21 04:09: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 78B343A6A20 for ; Mon, 21 Sep 2009 04:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_20=-0.74, 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 Km5rn1Ql+jLP for ; Mon, 21 Sep 2009 04:09: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 A88AF3A69AC for ; Mon, 21 Sep 2009 04:09:34 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 95336413B; Mon, 21 Sep 2009 07:10:34 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Mon, 21 Sep 2009 07:10:34 -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] Call for interest in working on security X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 11:09:35 -0000 Speaking as an individual. There's a bit with my chair hat on at the end clearly labeled. So, I'd like to see some progress on discussing security here. I've started an outline of what I think we need to cover at http://tools.ietf.org/wg/lisp/trac/wiki/Security01 . The idea is that people who agree with the direction I'm taking can join and we can work together putting together something in the open that we'll bring to the WG for review when it's ready. I want to do everything in the open so people know what I'm up to, and so people who have other ideas are encouraged to actually go write up their ideas. However at this point I'm not trying to build a WG-wide consensus. I've started with a broad outline and a set of reading material. If the outline and my posited goals for LISP security sounds interesting to you, then perhaps you want to become involved. If so, then I'd recommend starting by reading some or all of the recommended reading. Hopefully some people around here have already read several of the things there. There's probably not enough detail for you to agree with the direction enough to join the proposal at this point. However I'm definitely interested in comments even at this stage, especially about things to add to the reading list, or headings I missed. I hope we can get things kick-started. Speaking as a chair, If anyone wants wiki space for this sort of thing, by all means take it. If you run into authorization problems or anything else, let the chairs know. I ask that you make your page clearly labeled as an individual/group proposal but not as a WG effort. Also, it looks tricky to rename pages. So, please don't take a page name we're likely to want to use. If people think using the WG wiki for this sort of pre-WG effort is a bad idea, then let me know; I can find hosting elsewhere. I was just trying to be open. From hartmans@mit.edu Mon Sep 21 05:28: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 6747128C146 for ; Mon, 21 Sep 2009 05:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 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 FBvdMKEuynyw for ; Mon, 21 Sep 2009 05:28: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 AC92928C128 for ; Mon, 21 Sep 2009 05:28:04 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D3D8B413B; Mon, 21 Sep 2009 08:29:04 -0400 (EDT) To: Dino Farinacci References: <4AB33485.5050000@uclouvain.be> <4AB38315.2000305@joelhalpern.com> From: Sam Hartman Date: Mon, 21 Sep 2009 08:29:04 -0400 In-Reply-To: (Dino Farinacci's message of "Fri\, 18 Sep 2009 10\:11\:19 -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] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 12:28:05 -0000 I think people are still talking past each other. damien, can I see if I'm explaining you correctly? You are trying to communicate with a LISP site. You receive a mapping reply for that site. In that map reply we can include information on what versions of LISP that site sends. You send a packet to that site. If no version information is included in the packet, then the site may not know what version to use in its responses. It can just wait until it gets a map reply from you. However in the case where the site is going to use gleaned map cache information, it may not have anything other than that first packet to find out what version to use. You might argue that the map request could have carried your version information. However, because of square routing and other concerns, the map request and data packet may go to different places. Have I got it right? From damien.saucez@uclouvain.be Mon Sep 21 06: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 CDB1E3A67AF for ; Mon, 21 Sep 2009 06:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-1.515, BAYES_05=-1.11] Received: 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+BWuYTC24a7 for ; Mon, 21 Sep 2009 06:44:42 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 8EEBE3A6900 for ; Mon, 21 Sep 2009 06:44:42 -0700 (PDT) Received: from [130.104.228.15] (sleipnier-lite.dhcp.info.ucl.ac.be [130.104.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 4FB66E9328; Mon, 21 Sep 2009 15:44:56 +0200 (CEST) Message-ID: <4AB78356.4080109@uclouvain.be> Date: Mon, 21 Sep 2009 15:44:54 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Sam Hartman References: <4AB33485.5050000@uclouvain.be> <4AB38315.2000305@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 4FB66E9328.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 13:44:44 -0000 Sam, Sam Hartman wrote: > I think people are still talking past each other. > > damien, can I see if I'm explaining you correctly? > > You are trying to communicate with a LISP site. You receive a mapping > reply for that site. In that map reply we can include information on > what versions of LISP that site sends. > > more precisely, the version it can receives. > You send a packet to that site. If no version information is included > in the packet, then the site may not know what version to use in its > responses. > > It can just wait until it gets a map reply from you. yes > However in the > case where the site is going to use gleaned map cache information, it > may not have anything other than that first packet to find out what > version to use. > > if you do not use data gleaning then, you do not need the version in the data packet as you will send a request and thus learn the version with the reply. > You might argue that the map request could have carried your version > information. However, because of square routing and other concerns, > the map request and data packet may go to different places. > yes, so putting the version in the map request is useless for our problem (but could help in some simple cases). > Have I got it right? > Yes. Damien Saucez > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From rw@firstpr.com.au Mon Sep 21 07:17: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 767DC3A659B for ; Mon, 21 Sep 2009 07:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWylRLF2CyhS for ; Mon, 21 Sep 2009 07:17:23 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 4B0383A6870 for ; Mon, 21 Sep 2009 07:17:23 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 7F039175C89; Tue, 22 Sep 2009 00:18:23 +1000 (EST) Message-ID: <4AB78B30.1010303@firstpr.com.au> Date: Tue, 22 Sep 2009 00:18:24 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: lisp@ietf.org References: <20090919171820.746426BE628@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Noel Chiappa Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 14:17:24 -0000 Hi Sam, Thanks for this. Can you or anyone else point me to the RFCs or whatever which give guidance on discussing "business models" within an IETF WG? Irrespective of what those restrictions are, I think there's no point in devising a scalable routing solution without a thorough set of possible business models to match everything which needs to be adopted, changed deployed etc. We can't force the solution on anyone. We need to show, in theory, at least one and ideally more plausible reasons why existing and new organisations will want to do all the things which need to be done. I recognise in an experimental WG such as this, we can't necessarily come up with a perfectly satisfactory business model for adoption of every element of the proposed solution, but the earlier we start thinking about these things the better. The business aspects of PETRs have a big impact on the design of the protocols. For instance: 1 - Who is paying to access what PETR - or are all PETRs open for everyone - in which case, who pays for them? 2 - How close are PETRs usually to the LISP sites which send them packets. If they are close, then how does an end-user network move to a completely different network on the other side of the planet, and get access to PETRs there, if the PETRs are independent of the networks they are using for access? They would presumably need to deal with a new company which runs PETRs in the other location. Then there needs to be authentication so all this can happen securely without much administrative fuss. If there are going to be ITRs behind NAT then how is the PETR going to distinguish between multiple ITRs behind a single global unicast address? How is a PETR going to avoid accepting packets sent by other parties than the authorised ITRs? Anyone can send a packet to the PETR with a tunnel protocol identical to LISP, but with a forged ITR address matching that of an ITR which the PETR is authorised to handle packets from. - Robin - Robin From jmh@joelhalpern.com Mon Sep 21 07:26: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 80BAC3A6AA7 for ; Mon, 21 Sep 2009 07:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[AWL=-0.251, 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 iXSKotvcTTFI for ; Mon, 21 Sep 2009 07:26:42 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id C67CE3A694E for ; Mon, 21 Sep 2009 07:26:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 910AC32317A4; Mon, 21 Sep 2009 07:27:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 0260B32316BD; Mon, 21 Sep 2009 07:27:43 -0700 (PDT) Message-ID: <4AB78D5E.3050303@joelhalpern.com> Date: Mon, 21 Sep 2009 10:27:42 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Robin Whittle References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB78B30.1010303@firstpr.com.au> In-Reply-To: <4AB78B30.1010303@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 14:26:43 -0000 I think that there is a distinction that is important to keep in mind. First, some assumptions I make: For LISP to work, it has to be deployable. Deployability includes the presence of suitable incentives for deployment. That clearly includes appropriate balance of financial incentives and disincentives. For many parts of this system, that is straightforward, and does not involve business models. For PTRs and PETRs there does appear to be a question about what the incentives for deployment are going to be. Who will deploy them, and why? It is quite reasonable, and I think necessary, to discuss what possible incentives there are, who needs to deploy the things, and why they might do so. The distinction I draw is between that and "a thorough set of possible business models." We are not trying to explore the space of business models, or determine whether this is compatible with every one. We do not even have to do a full economic analysis confirming that there is a business model that covers everything. Phrased differently, I think we need to convince ourselves that the business model has enough solidity that it may succeed. After that, the experiments should help us tell who is interested, and what the actual costs are, etc... Our initial evaluation needs to look at overall incentives and overall costs, not details of business models. Yours, Joel Robin Whittle wrote: > Hi Sam, > > Thanks for this. Can you or anyone else point me to the RFCs or > whatever which give guidance on discussing "business models" within > an IETF WG? > > Irrespective of what those restrictions are, I think there's no point > in devising a scalable routing solution without a thorough set of > possible business models to match everything which needs to be > adopted, changed deployed etc. ... From hartmans@mit.edu Mon Sep 21 07: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 9FC3E3A67A3 for ; Mon, 21 Sep 2009 07:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 1A8M2aL-+35S for ; Mon, 21 Sep 2009 07:54: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 1C22D3A6AB8 for ; Mon, 21 Sep 2009 07:54:42 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3E343413B; Mon, 21 Sep 2009 10:55:42 -0400 (EDT) To: Robin Whittle References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB78B30.1010303@firstpr.com.au> From: Sam Hartman Date: Mon, 21 Sep 2009 10:55:42 -0400 In-Reply-To: <4AB78B30.1010303@firstpr.com.au> (Robin Whittle's message of "Tue\, 22 Sep 2009 00\:18\:24 +1000") 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, Noel Chiappa Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 14:54:43 -0000 >>>>> "Robin" == Robin Whittle writes: 8 Robin> Hi Sam, Thanks for this. Can you or anyone else point me Robin> to the RFCs or whatever which give guidance on discussing Robin> "business models" within an IETF WG? Most of the restrictions would come from US anti-trust law. I am not qualified to give legal advice. I do not know of specific IETF policies that cover what is and is not acceptable in detail; if I need help I'll consult Jari and the IESG. I do think Joel's comments are quite helpful on this. There's an additional factor Joel didn't cover that is important for security. Whith whom am I likely to have relationships? For example if I'm likely to have some sort of relationship with my EID provider, it is probably reasonable that I'm going to need to set up a secret used for map registers with that provider. However if I'm going to be communicating with parties with whom I have no prior relationship, then assuming a shared secret or shared trust anchor may be a very dubious assumption. From jnc@mercury.lcs.mit.edu Mon Sep 21 10: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 F30E328C20E for ; Mon, 21 Sep 2009 10:13:08 -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=[AWL=0.001, 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 0wHAbzcdhupI for ; Mon, 21 Sep 2009 10:13: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 4134C28C1C9 for ; Mon, 21 Sep 2009 10:13:08 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D1D296BE54F; Mon, 21 Sep 2009 13:14:08 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090921171408.D1D296BE54F@mercury.lcs.mit.edu> Date: Mon, 21 Sep 2009 13:14:08 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 17:13:09 -0000 > From: "Joel M. Halpern" > First, some assumptions I make: Good set. > For PTRs and PETRs Minor terminology nit: I've been suggesting that we call these things PITRs and PETRs, so the terms have symmetry. > The distinction I draw is between that and "a thorough set of > possible business models." We are not trying to explore the space of > business models ... I think we need to convince ourselves that the > business model has enough solidity that it may succeed. After that, > the experiments should help us tell who is interested, and what the > actual costs are, etc... Our initial evaluation needs to look at > overall incentives and overall costs, not details of business models. Exactly. Noel From darlewis@cisco.com Mon Sep 21 10:24: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 80F7E3A691D for ; Mon, 21 Sep 2009 10:24:21 -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 YYUAAY2gYnF1 for ; Mon, 21 Sep 2009 10:24:20 -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 AAB973A68A1 for ; Mon, 21 Sep 2009 10:24:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAH9Ut0qrR7O6/2dsb2JhbAC7PohQAY5LBYIzgWiBXQ X-IronPort-AV: E=Sophos;i="4.44,425,1249257600"; d="scan'208";a="206607402" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 21 Sep 2009 17:25:10 +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 n8LHP97l001426; Mon, 21 Sep 2009 10:25:09 -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 n8LHP9r5018318; Mon, 21 Sep 2009 17:25:09 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); Mon, 21 Sep 2009 10:25: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: Mon, 21 Sep 2009 10:25:08 -0700 Message-ID: In-Reply-To: <4AB5AA3C.5090805@firstpr.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP Interworking: Proxy Egress Tunnel Routers Thread-Index: Aco5p8aiGmxoqLhZQte8R2cIXbSX/wBN/K6Q References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> From: "Darrel Lewis (darlewis)" To: "Robin Whittle" , X-OriginalArrivalTime: 21 Sep 2009 17:25:08.0992 (UTC) FILETIME=[77C45000:01CA3AE0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=877; t=1253553910; x=1254417910; 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]=20LISP=20Interworking=3A=20=20Pr oxy=20Egress=20Tunnel=20Routers |Sender:=20; bh=srI6CPgxiF6HT48JIv8w4vvkQNm0NeOKkI+lYGvxYu8=; b=o5O/9VOp5eFsFND7W5zwTL0TRreij+FbJeVEgwgYZH23wrCSAwBSF4WPk+ BUxYcjk+id6ELDT1UeWAkl5CAjfYzwEt4cvuodi6Jp25wjUVi+CPTjOtXAvt D9E0WIkPv2; Authentication-Results: sj-dkim-2; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Noel Chiappa Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 17:24:21 -0000 =20 >=20 > I am not saying there isn't a viable business model for PETRs. I am > just saying that I don't know what the business model is for PETRs > and that I think that at least one seemingly viable model should be > proposed before the whole PETR concept is accepted. >=20 >=20 >=20 Here is a simple one. A provider wants to advertise that it allows for IPv6 connectivity, but it does not have equipment in the access network that supports v6 natively. So it offers a v6 service that includes a CPE device that runs LISP, and some PETRs for those CPE's to use when accessing non-LISP sites. IPv6 packets sent from the hosts at the site are encapsulated in v4 and sent over the access network that does not support v6. There are a myriad of other possibilities here, including over-the-top service providers who offer PETR services. =20 -Darrel From jnc@mercury.lcs.mit.edu Mon Sep 21 10:48: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 D0F0B3A6947 for ; Mon, 21 Sep 2009 10:48:23 -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=[AWL=0.001, 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 xstzN3hs+jsu for ; Mon, 21 Sep 2009 10:48:23 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id CAD0528C160 for ; Mon, 21 Sep 2009 10:48:22 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CC40B6BE54F; Mon, 21 Sep 2009 13:49:23 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090921174923.CC40B6BE54F@mercury.lcs.mit.edu> Date: Mon, 21 Sep 2009 13:49:23 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 17:48:23 -0000 > From: Sam Hartman > If no version information is included in the packet, then the site > may not know what version to use in its responses. ... > in the case where the site is going to use gleaned map cache > information, it may not have anything other than that first packet > to find out what version to use. Light dawns over famous Massachussetts fishing harbour... :-) Sorry I was a bit slow to catch on. Yeah, that's a problem. (Puts on thinking cap, goes away to ponder for a few days...) > You might argue that the map request could have carried your version > information. However, because of square routing and other concerns, > the map request and data packet may go to different places. That's a general problem with square routing (i.e. packets from site A to B flow from ITR a1 to ETR b1, packets back from B to A flow via ITR b2 and ETR a2), and not just with the version information - the b2 ITR doesn't have the mapping, either. I've had it kicking around the back of my brain for a while now, but no great hack has appeared. I suspect the only answers are painful (e.g. better co-ordination between all the xTRs at a site - which we might need anyway, for other reasons). Noel From hartmans@mit.edu Mon Sep 21 11:10: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 10C933A68F6 for ; Mon, 21 Sep 2009 11:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 oHWTaauoOnMO for ; Mon, 21 Sep 2009 11:10: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 329343A6825 for ; Mon, 21 Sep 2009 11:10:19 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B4A4D413B; Mon, 21 Sep 2009 14:11:18 -0400 (EDT) To: "Darrel Lewis \(darlewis\)" References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> From: Sam Hartman Date: Mon, 21 Sep 2009 14:11:18 -0400 In-Reply-To: (Darrel Lewis's message of "Mon\, 21 Sep 2009 10\:25\:08 -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 , Robin Whittle , lisp@ietf.org Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 18:10:20 -0000 >>>>> "Darrel" == Darrel Lewis (darlewis) writes: >> >> I am not saying there isn't a viable business model for PETRs. >> I am just saying that I don't know what the business model is >> for PETRs and that I think that at least one seemingly viable >> model should be proposed before the whole PETR concept is >> accepted. >> >> >> Here is a simple one. A provider wants to advertise that it allows for Darrel> IPv6 connectivity, but it does not have equipment in the Darrel> access network that supports v6 natively. So it offers a Darrel> v6 service that includes a CPE device that runs LISP, and Darrel> some PETRs for those CPE's to use when accessing non-LISP Darrel> sites. IPv6 packets sent from the hosts at the site are Darrel> encapsulated in v4 and sent over the access network that Darrel> does not support v6. Speaking as an individual, I'd like to find deployment models f Speaking as an individual, this deployment model has two problems: 1) The IETF already has other solutinos in that space with a lot more successful deployment than LISP (6to4, Teredo, probably even 6rd). 2) This deployment model does not actually get to the deployment we need. As I understand it, for interworking to be useful, we need to get to a point where everyone using LISP either A) Is on a link that can loosen URPF or B) has a PETR they can use. So, you need to show that there are sufficient insentives to make PETRs available to all lisp sites on access networks that are going to enforce URPF. Combining with v6 deployment doesn't really seem to help this much. I can see insentives for whomever is selling you your EID to make a PETR available to you, but unless you are going to end up tied to a single ISP, I don't see why they will be in a position to make a PETR available close to you. From darlewis@cisco.com Mon Sep 21 11:38: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 A3B163A6959 for ; Mon, 21 Sep 2009 11:38:28 -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 YgHRPEX7B4WB for ; Mon, 21 Sep 2009 11:38:27 -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 C88663A6825 for ; Mon, 21 Sep 2009 11:38:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF9lt0qrR7PE/2dsb2JhbAC7BIhQAY5TBYIzgWiBXYkj X-IronPort-AV: E=Sophos;i="4.44,425,1249257600"; d="scan'208";a="95668372" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 21 Sep 2009 18:39:29 +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 n8LIdTkN027293; Mon, 21 Sep 2009 11:39:29 -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 n8LIdTpx004507; Mon, 21 Sep 2009 18:39:29 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); Mon, 21 Sep 2009 11:39: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: Mon, 21 Sep 2009 11:39:28 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP Interworking: Proxy Egress Tunnel Routers Thread-Index: Aco65v+YMCKszBRkQ/6brywlipcxWgAAcKMQ References: <20090919171820.746426BE628@mercury.lcs.mit.edu><4AB5AA3C.5090805@firstpr.com.au> From: "Darrel Lewis (darlewis)" To: "Sam Hartman" X-OriginalArrivalTime: 21 Sep 2009 18:39:29.0448 (UTC) FILETIME=[DA67E280:01CA3AEA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2276; t=1253558369; x=1254422369; c=relaxed/simple; s=sjdkim4002; 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]=20LISP=20Interworking=3A=20=20Pr oxy=20Egress=20Tunnel=20Routers |Sender:=20; bh=IBIc+T3h13fWcd6vJi3KhtwA46Ah9u25Ggkw5DBFk38=; b=T2yM0XbeCeuG/SwQEZNGMQqUq/VVpTJGM/y456OKCbjnvTQP8AO4zk53Y1 oGTXwLBxEzBfX/OditWX4g2VoGLTqDvPHRuzYYYYL+mEIJCxYRzHLKP6JVIm cMnjGF4twJ; Authentication-Results: sj-dkim-4; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Noel Chiappa , Robin Whittle , lisp@ietf.org Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 18:38:28 -0000 > Speaking as an individual, this deployment model has two problems: >=20 To be clear, I also am speaking as an individual. > 1) The IETF already has other solutinos in that space with a lot more > successful deployment than LISP (6to4, Teredo, probably even 6rd). >=20 > 2) This deployment model does not actually get to the deployment we > need. It is one of many possible ones, and since it is one we have existence proof for (there are many over the top providers offering v6 via GRE today), I used it as an example. I don't think that we're required to exhaustively discuss the deployment and business models for an experimental protocol. But if you like I can provide another example of a virtual over the top provider offering LISP, VPN, and other services. >=20 > As I understand it, for interworking to be useful, we need to get to a > point where everyone using LISP either >=20 > A) Is on a link that can loosen URPF >=20 To be specific, the provider has to work around strict uRPF. The draft provides a few examples of how to do this, including using a less strict version, or (preferably) adding a static route to the EID space on the PE router. > or > B) has a PETR they can use. >=20 Or=20 C) they use LISP-NAT > So, you need to show that there are sufficient incentives to make > PETRs available to all lisp sites on access networks that are going to > enforce URPF. Combining with v6 deployment doesn't really seem to > help this much. This is not correct, NAT is always an option. For v6, we have a difference of opinion here it seems. I believe that using this to hop over my provider's v4 only access network is interesting. I don't see why the existence of alternatives should preclude LISP experimenting with this problem - certainly there are other alternatives to the routing problem (like shim6) that have not precluded experimentation with LISP. >=20 > I can see incentives for whomever is selling you your EID to make a > PETR available to you, but unless you are going to end up tied to a > single ISP, I don't see why they will be in a position to make a PETR > available close to you. If we can see the incentives, that should be enough correct?=20 -Darrel From jnc@mercury.lcs.mit.edu Mon Sep 21 12:41: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 5C5613A6AFF for ; Mon, 21 Sep 2009 12:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_BIZOP=0.7] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfCnffZZBu7i for ; Mon, 21 Sep 2009 12:41:04 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id AA5C33A6AF8 for ; Mon, 21 Sep 2009 12:41:04 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B23C96BE5F2; Mon, 21 Sep 2009 15:42:05 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090921194205.B23C96BE5F2@mercury.lcs.mit.edu> Date: Mon, 21 Sep 2009 15:42:05 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 19:41:07 -0000 > From: Sam Hartman > The IETF already has other solutinos in that space with a lot more > successful deployment than LISP (6to4, Teredo, probably even 6rd). If you're connected to a v4-only provider, and all you want is v6 connectivity, yeah, that's probably true. However, if you are connected like that, and either i) have LISP already, or ii) want LISP for some of the _other_ things LISP does (e.g. multihoming, etc), then it's a nice side-benefit. > As I understand it, for interworking to be useful, we need to get to a > point where everyone using LISP either > A) Is on a link that can loosen URPF[,] or > B) has a PETR they can use. Well, the term "everyone using LISP" might not be accurate, there... If a site can't originate packets from its ITR to non-LISP destinations (i.e. which will have to be non-wrapped, and therefore would have to have an EID source address, which uRPF will block), and also don't have access to an ETR, they _can't_ run LISP. So merely the existence of ISPs which enforce uRPF is enough to 'prove' that we needs PETRs, at least as far as the pure engineering assessment goes. Whether there is a viable _business model_ to support them, well, we'll see. However, to me, looking at the above, 'ISPs which enforce uRPF' + 'people who want to run LISP (for whatever) reason' -> 'business opportunity for those who can provide PETR service'. > I can see insentives for whomever is selling you your EID to make a > PETR available to you, but unless you are going to end up tied to a > single ISP I don't know whether bundling will make the most sense or not. The market will decide... > I don't see why they will be in a position to make a PETR available > close to you. Your ISP, or your EID source, might not. But in that case, bearing in mind that to run LISP you will need either i) a non-uRPF ISP, or ii) a PETR, then if you're on an uRPF ISP, then _if you want to run LISP at all_, either i) you provide your own PETR, or ii) you have to contract with someone else to provide the functionality. To me, it's quite simple: ISPs with uRPF (and I gather there are such) guarantee that PETR functionality will need to exist. So I don't think we can avoid specifying the functionality. Time to turn to the engineering? Noel From darlewis@cisco.com Mon Sep 21 13:44: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 9D91E3A681B for ; Mon, 21 Sep 2009 13:44:42 -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 PNOyu1+Ay2n4 for ; Mon, 21 Sep 2009 13:44:41 -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 BBCEE3A6916 for ; Mon, 21 Sep 2009 13:44:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOeCt0qrR7O6/2dsb2JhbAC7GIhQAY5fBYQbiwI X-IronPort-AV: E=Sophos;i="4.44,426,1249257600"; d="scan'208";a="191085900" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 21 Sep 2009 20:45:44 +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 n8LKjhcC013811; Mon, 21 Sep 2009 13:45:43 -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 n8LKjhrt027187; Mon, 21 Sep 2009 20:45:43 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); Mon, 21 Sep 2009 13:45:42 -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: Mon, 21 Sep 2009 13:45:41 -0700 Message-ID: In-Reply-To: <20090921174923.CC40B6BE54F@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] #5: LISP protocol version is alive and kicking Thread-Index: Aco64+XONVrpMv9ETGqbkBd9Hnnr1QAGHSeQ References: <20090921174923.CC40B6BE54F@mercury.lcs.mit.edu> From: "Darrel Lewis (darlewis)" To: "Noel Chiappa" , X-OriginalArrivalTime: 21 Sep 2009 20:45:42.0516 (UTC) FILETIME=[7C4E5B40:01CA3AFC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=509; t=1253565943; x=1254429943; 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#5=3A=20LISP=20protocol=20vers ion=20is=20alive=20and=20kicking |Sender:=20; bh=QTLOhy3mHSQFFbmtb4+ceMRZ4teJRBh9Pjdnbq3ZA6M=; b=WCG0vgd2WmOOlGUIrI6gosXRt8j8omdFRyQwo2JsLrIV5kQbVAULQztVKm fDotcjLzTTMFYZu5IsFc4D0VDm0ytzfGO6ljLktC6zYpuieyK9Z9B9jhzi7h epm2TXZz6l; Authentication-Results: sj-dkim-2; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 20:44:42 -0000 =20 >=20 > I've had it kicking around the back of my brain for a while=20 > now, but no > great hack has appeared. I suspect the only answers are painful (e.g. > better co-ordination between all the xTRs at a site - which=20 > we might need > anyway, for other reasons). >=20 > Noel To me, all of this discussion makes TTL (called clock sweep in the draft if I remember correctly) based versioning better and better. It works, and keeps all of this complexity out of the protocol. -Darrel From dmm@1-4-5.net Mon Sep 21 13:47: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 1D95C3A69D5 for ; Mon, 21 Sep 2009 13:47:59 -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 Xfmmjq3P8suz for ; Mon, 21 Sep 2009 13:47:58 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 389DC3A69E7 for ; Mon, 21 Sep 2009 13:47:58 -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 n8LKmufI007480; Mon, 21 Sep 2009 13:48:56 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n8LKmt8o007479; Mon, 21 Sep 2009 13:48:55 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 21 Sep 2009 13:48:55 -0700 From: David Meyer To: Sam Hartman Message-ID: <20090921204855.GA7205@1-4-5.net> References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" 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, Noel Chiappa , Robin Whittle Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 20:47:59 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 21, 2009 at 02:11:18PM -0400, Sam Hartman wrote: > >>>>> "Darrel" =3D=3D Darrel Lewis (darlewis) writes: >=20 > >>=20 > >> I am not saying there isn't a viable business model for PETRs. > >> I am just saying that I don't know what the business model is > >> for PETRs and that I think that at least one seemingly viable > >> model should be proposed before the whole PETR concept is > >> accepted. > >>=20 > >>=20 > >>=20 >=20 > Here is a simple one. A provider wants to advertise that it allows for > Darrel> IPv6 connectivity, but it does not have equipment in the > Darrel> access network that supports v6 natively. So it offers a > Darrel> v6 service that includes a CPE device that runs LISP, and > Darrel> some PETRs for those CPE's to use when accessing non-LISP > Darrel> sites. IPv6 packets sent from the hosts at the site are > Darrel> encapsulated in v4 and sent over the access network that > Darrel> does not support v6. >=20 > Speaking as an individual, I'd like to find deployment models f > Speaking as an individual, this deployment model has two problems: >=20 > 1) The IETF already has other solutinos in that space with a lot more > successful deployment than LISP (6to4, Teredo, probably even 6rd). > >=20 > 2) This deployment model does not actually get to the deployment we > need. Understand that you are speaking as an individual; however, are you stating your points above are reqired either by the IETF and/or by the WG? That is, are you Experimental RFCs should not be developed when there are other solutions in the same general space? 2) is a little harder to deal with (being subjective); see below. If so, can you point at any document that states that work designed to lead to an Experimental RFC should *not* be undertaken if another solution exists (your 1) above)? If not, why do you raise the issue? With respect to assertion 2): I understand that this is your (and perhaps others) opinion. However, there are many other folks with opinions that differ from yours, so I'm not sure what the significance of your statement is in the context of WG's milestones.=20 Please clarify what you are trying to say here (in both cases). Appreciated, Dave --oyUTqETQ0mS9luUI 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) iEYEARECAAYFAkq35rcACgkQORgD1qCZ2KedLwCfcCNDKezJA8riX2HmoIreBHiC LUwAnjoOrIMBpc91tzoA225e8XHWf7At =JOl+ -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From hartmans@mit.edu Mon Sep 21 14:24: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 0356D3A6832 for ; Mon, 21 Sep 2009 14:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 e1rj3q29Z2gE for ; Mon, 21 Sep 2009 14:24: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 2798528C0D9 for ; Mon, 21 Sep 2009 14:24:25 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1A5BA413B; Mon, 21 Sep 2009 17:25:25 -0400 (EDT) To: David Meyer References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> <20090921204855.GA7205@1-4-5.net> From: Sam Hartman Date: Mon, 21 Sep 2009 17:25:24 -0400 In-Reply-To: <20090921204855.GA7205@1-4-5.net> (David Meyer's message of "Mon\, 21 Sep 2009 13\:48\:55 -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, Noel Chiappa , Robin Whittle Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 21:24:26 -0000 >>>>> "David" == David Meyer writes: David> Understand that you are speaking as an individual; David> however, are you stating your points above are reqired David> either by the IETF and/or by the WG? That is, are you David> Experimental RFCs should not be developed when there are David> other solutions in the same general space? We have a fairly specific charter for why we're developing LISP. I don't think easing IPv6 transition is part of it. As an individual, I prefer that the WG not spend its energy working on problems where that's the motivation. I prefer that when we do work on a problem that we try and think about v6 transition. So, if we do PETRs, we should make them friendly to transition. However, since we're not in the transition business, we shouldn't do PETRs simply for transition. Also, yes, I definitely believe it's the case that the IETF should not do work that is not needed. I'd hope I don't need to find an RFC to back that up. It's my opinion that we have a lot of operational experience with Teredo and 6to4, and that suggests we're not really looking for additional mechanisms to tunnel v6 over v4 to get around NATs and access network issues. There is some work within the charter of softwires focused around providing that sort of transition as a service. I agree that is needed, although I think even they concluded they didn't need new encapsulations. David> With respect to assertion 2): I understand that this David> is your (and perhaps others) opinion. However, there are David> many other folks with opinions that differ from yours, so David> I'm not sure what the significance of your statement is in David> the context of WG's milestones. Well, these people with different opinions need to write to the list for their opinions to be considered. So far, the people who have opinions as far as the WG are concerned are Darrel, Noel, Robbin and myself. Presumably since you're writing you have a different opinion. My assertion #2 roughly boiled down to two parts: A) If PETRs are going to solve the interworking problem for people who have URPF blockage, then those people need a PETR they can use. B) It seems fairly clear to me that if people deploy PETRs as a v6 transition service, they won't be available to the right people to solve the interworking problem. I'm hoping to get Darrel to focus on the deployment incentives for PETRs as a part of the interworking problem between LISP sites and non-LISP sites, not other deployment incentives that might also increase the global number of PETRs. From hartmans@mit.edu Mon Sep 21 14:26: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 9FAA528C0CF for ; Mon, 21 Sep 2009 14:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 ERGVhcy6VyrT for ; Mon, 21 Sep 2009 14:26: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 EBF123A6AD7 for ; Mon, 21 Sep 2009 14:26:26 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 333A0413B; Mon, 21 Sep 2009 17:27:27 -0400 (EDT) To: "Darrel Lewis \(darlewis\)" References: <20090921174923.CC40B6BE54F@mercury.lcs.mit.edu> From: Sam Hartman Date: Mon, 21 Sep 2009 17:27:27 -0400 In-Reply-To: (Darrel Lewis's message of "Mon\, 21 Sep 2009 13\:45\:41 -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] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 21:26:27 -0000 >>>>> "Darrel" == Darrel Lewis (darlewis) writes: >> >> I've had it kicking around the back of my brain for a while >> now, but no great hack has appeared. I suspect the only answers >> are painful (e.g. better co-ordination between all the xTRs at >> a site - which we might need anyway, for other reasons). >> >> Noel Darrel> To me, all of this discussion makes TTL (called clock Darrel> sweep in the draft if I remember correctly) based Darrel> versioning better and better. It works, and keeps all of Darrel> this complexity out of the protocol. I'm sorry I don't follow you at all. I guess mostly I don't follow how clock sweep is related to the discussion, which probably means I'm just missing a logical jump. I'm certainly not disagreeing with setting your ttl correctly From hartmans@mit.edu Mon Sep 21 14: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 879883A6ABA for ; Mon, 21 Sep 2009 14:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 aIg0G4cfNUJK for ; Mon, 21 Sep 2009 14:40:08 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id A05013A68FB for ; Mon, 21 Sep 2009 14:40:08 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0244D413B; Mon, 21 Sep 2009 17:41:08 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090921194205.B23C96BE5F2@mercury.lcs.mit.edu> From: Sam Hartman Date: Mon, 21 Sep 2009 17:41:08 -0400 In-Reply-To: <20090921194205.B23C96BE5F2@mercury.lcs.mit.edu> (Noel Chiappa's message of "Mon\, 21 Sep 2009 15\:42\:05 -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] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 21:40:09 -0000 >>>>> "Noel" == Noel Chiappa writes: Noel> If a site can't originate packets from its ITR to non-LISP Noel> destinations (i.e. which will have to be non-wrapped, and Noel> therefore would have to have an EID source address, which Noel> uRPF will block), Depending on where LISP is going to be deployed, URPF may or may not be an issue. Since I still don't understand where we think LISP will be used, I can't evaluate whether this is something we need to solve. Obviously, based on what I'm doing with my implementation, I would not at all be surprised if LISP is deployed in situations where URPF is an issue. Noel> and also don't have access to an ETR, they Noel> _can't_ run LISP. Noel> So merely the existence of ISPs which enforce uRPF is enough Noel> to 'prove' that we needs PETRs, at least as far as the pure Noel> engineering assessment goes. No, I don't think that follows. I think it follows either that 1) You don't get end-to-end addressing talking to non-LISP sites (we probably all think that's not good as an only option) 2) Some box needs to source packets somewhere with your EID. A PETR is more than just some boxes sourcing packets with your EID. It has several properties: * It uses the LISP data encapsulation * It may not be connected with the person providing your EIDs * It's topologically close to you * It uses IP access lists for security Also, I think that showing the engineering requirement for something isn't good enough. We've said that we want LISP to be deployable. If we can't identify deployment incentives for critical parts, that raises a significant red flag in my mind. I actually suspect that once we have a broader idea about LISP deployment, coming up with incentives for PETRs won't be that difficult. However I agree with Robbin that it's a critical question that I'd rather have answered before going down this path. so, I'm finding that for me at least, PETRs are yet another thing that blocks behind understanding security and deployment. (I have not gone into the reasons why I'm concerned about PETRs and security. Basically I want to understand what our DOS prevention model is to understand how much work we need to do to make sure PETRs are not used in mounting DOS attacks.) From dmm@1-4-5.net Mon Sep 21 14:42: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 364AC3A6953 for ; Mon, 21 Sep 2009 14:42:18 -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 kGOtvitAK5CV for ; Mon, 21 Sep 2009 14:42:13 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 9AEAC3A683F for ; Mon, 21 Sep 2009 14:42:13 -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 n8LLhCXF009332; Mon, 21 Sep 2009 14:43:12 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n8LLhCh3009331; Mon, 21 Sep 2009 14:43:12 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 21 Sep 2009 14:43:12 -0700 From: David Meyer To: Sam Hartman Message-ID: <20090921214312.GA8975@1-4-5.net> References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> <20090921204855.GA7205@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" 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, Noel Chiappa , Robin Whittle Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 21:42:18 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 21, 2009 at 05:25:24PM -0400, Sam Hartman wrote: > >>>>> "David" =3D=3D David Meyer writes: >=20 > David> Understand that you are speaking as an individual; > David> however, are you stating your points above are reqired > David> either by the IETF and/or by the WG? That is, are you > David> Experimental RFCs should not be developed when there are > David> other solutions in the same general space?=20 >=20 > We have a fairly specific charter for why we're developing LISP. > I don't think easing IPv6 transition is part of it. Ok, fair enough. However easing v6 transition was just used as an example. The topic was (as you know) on interworking, which is part of the charter. Please see http://www.ietf.org/dyn/wg/charter/lisp-charter.html. That stipulated, note that the title of the Interworking Draft is "Interworking LISP with IPv4 and IPv6". Since that draft is clearly within the current scope of the WG, are you calling for recharting the WG? If so, please provide a formal request to both the WG and ADs. > As an individual, I prefer that the WG not spend its energy > working on problems where that's the motivation.=20 That's fine.=20 > I prefer that when we do work on a problem that we try and > think about v6 transition.=20 Please clarify. I couldn't parse that in the context of the rest of your note. > So, if we do PETRs, we should make them friendly to transition. Of course, I think everyone wants that. > However, since we're not in the transition business, we > shouldn't do PETRs simply for transition.=20 Again, you've just asserted something that is neither supported by the charter or any consensus call that I know of. > Also, yes, I definitely believe it's the case that the IETF should not > do work that is not needed. I'd hope I don't need to find an RFC to > back that up. I'm sorry, here "what's needed" is an arbitrary call on your part. Can you support your definition of "what's needed" with anything other than that assertion?=20 > It's my opinion that we have a lot of operational > experience with Teredo and 6to4, and that suggests we're not really > looking for additional mechanisms to tunnel v6 over v4 to get around > NATs and access network issues. There is some work within the charter > of softwires focused around providing that sort of transition as a > service. I agree that is needed, although I think even they concluded > they didn't need new encapsulations. Again, these are arbitrary assertions. Please provide a proceedural artifact to support this. If you can not to this, then the above statement is not relevant to the operation of the WG. > David> With respect to assertion 2): I understand that this > David> is your (and perhaps others) opinion. However, there are > David> many other folks with opinions that differ from yours, so > David> I'm not sure what the significance of your statement is in > David> the context of WG's milestones. >=20 > Well, these people with different opinions need to write to the list > for their opinions to be considered. So far, the people who have > opinions as far as the WG are concerned are Darrel, Noel, Robbin and > myself. > Presumably since you're writing you have a different opinion. Different than what? > My assertion #2 roughly boiled down to two parts: >=20 > A) If PETRs are going to solve the interworking problem for people who > have URPF blockage, then those people need a PETR they can use. >=20 > B) It seems fairly clear to me that if people deploy PETRs as a v6 > transition service, they won't be available to the right people to > solve the interworking problem. You've just restated your opinion, which to be blunt doesn't help. You might also explictly state what you would like the WG to accomplish (and provide process artififacts other than just restating your opinion). =09 Dave --fdj2RfSjLxBAspz7 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) iEYEARECAAYFAkq383AACgkQORgD1qCZ2KcFeACghzxQ5Ds8iZBa8g+EZXPpPmBi yQ4AnA4F2eBMDAS0Hf7sE9y31wvYB+ra =wmwd -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From hartmans@mit.edu Mon Sep 21 14:55: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 43B323A680F for ; Mon, 21 Sep 2009 14:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 oeqtZjsRnZ0b for ; Mon, 21 Sep 2009 14:55:46 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 5F8193A6875 for ; Mon, 21 Sep 2009 14:55:45 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 770B4413B; Mon, 21 Sep 2009 17:56:45 -0400 (EDT) To: David Meyer References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> <20090921204855.GA7205@1-4-5.net> <20090921214312.GA8975@1-4-5.net> From: Sam Hartman Date: Mon, 21 Sep 2009 17:56:45 -0400 In-Reply-To: <20090921214312.GA8975@1-4-5.net> (David Meyer's message of "Mon\, 21 Sep 2009 14\:43\:12 -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, Robin Whittle , Noel Chiappa Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 21:55:48 -0000 >>>>> "David" == David Meyer writes: Dave, I somehow managed to leave out the entire point of my message--or at least the point that was worthwhile enough to cause me to hit the send key. Please see below and see if you can help me out. >> Presumably since you're writing you have a different opinion. David> Different than what? mine I was hoping that I could restate my opinion and get you to explain what part of it you disagreed with. So far you've been grumpy that I stated an opinion, but not actually stated one of your own. However all I did was restate my opinion without actually asking you to comment on it. >> My assertion #2 roughly boiled down to two parts: >> >> A) If PETRs are going to solve the interworking problem for >> people who have URPF blockage, then those people need a PETR >> they can use. >> >> B) It seems fairly clear to me that if people deploy PETRs as a >> v6 transition service, they won't be available to the right >> people to solve the interworking problem. From dmm@1-4-5.net Mon Sep 21 15: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 DF39B3A67AE for ; Mon, 21 Sep 2009 15:12:38 -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 o6dBEivaBKh8 for ; Mon, 21 Sep 2009 15:12:36 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 4C5933A6879 for ; Mon, 21 Sep 2009 15:12:36 -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 n8LMDUCS009952; Mon, 21 Sep 2009 15:13:30 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n8LMDTkG009951; Mon, 21 Sep 2009 15:13:29 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 21 Sep 2009 15:13:29 -0700 From: David Meyer To: Sam Hartman Message-ID: <20090921221329.GA9627@1-4-5.net> References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> <20090921204855.GA7205@1-4-5.net> <20090921214312.GA8975@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" 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, Robin Whittle , Noel Chiappa Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:12:39 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 21, 2009 at 05:56:45PM -0400, Sam Hartman wrote: > >>>>> "David" =3D=3D David Meyer writes: > Dave, I somehow managed to leave out the entire point of my > message--or at least the point that was worthwhile enough to cause me > to hit the send key. > Please see below and see if you can help me out. >=20 >=20 > >> Presumably since you're writing you have a different opinion. >=20 > David> Different than what? > mine I was hoping that I could restate my opinion and get you to > explain what part of it you disagreed with. So far you've been grumpy > that I stated an opinion, but not actually stated one of your own. >=20 > However all I did was restate my opinion without actually asking you to c= omment on it. Well, a PETR is a general tool with multiple applications. More specifically, the point of PETR/PTRs is not specifically to aid in v6 transition (though that is a use case), but rather to fully utilize LISP's IP protocol independence, and to bring the benefits of LISP to sites that run LISP day one (i.e., without waiting for the entire network to transition to LISP). There are also advantages that accrue from the use of PTRs that may not be immediately obvious (such as helping ingress TE for LISP sites). =20 Dave --VbJkn9YxBvnuCH5J 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) iEYEARECAAYFAkq3+okACgkQORgD1qCZ2KcwoQCfdZAsDHeluQ5DKrN1H/dkCFJY 1wIAnA/1HesrgHA6TaF9oAuRg12vLFY7 =KbNU -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From hartmans@mit.edu Mon Sep 21 15:12: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 3D8FD3A6978 for ; Mon, 21 Sep 2009 15:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 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 0bINJuxICZth for ; Mon, 21 Sep 2009 15:12:54 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4392C3A6879 for ; Mon, 21 Sep 2009 15:12:54 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A09D9413B; Mon, 21 Sep 2009 18:13:54 -0400 (EDT) To: David Meyer References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> <20090921204855.GA7205@1-4-5.net> <20090921214312.GA8975@1-4-5.net> From: Sam Hartman Date: Mon, 21 Sep 2009 18:13:54 -0400 In-Reply-To: <20090921214312.GA8975@1-4-5.net> (David Meyer's message of "Mon\, 21 Sep 2009 14\:43\:12 -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, Robin Whittle , Noel Chiappa Subject: [lisp] Mostly pointless argument about V6 transition X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:12:55 -0000 >>>>> "David" == David Meyer writes: David> On Mon, Sep 21, 2009 at 05:25:24PM -0400, Sam Hartman wrote: >> >>>>> "David" == David Meyer writes: >> David> Understand that you are speaking as an individual; however, David> are you stating your points above are reqired either by the David> IETF and/or by the WG? That is, are you Experimental RFCs David> should not be developed when there are other solutions in David> the same general space? >> >> We have a fairly specific charter for why we're developing >> LISP. I don't think easing IPv6 transition is part of it. David> Ok, fair enough. However easing v6 transition was just David> used as an example. Right. And I was basically saying I didn't think it was a good example for why PETRs would be deployed in the right places. I was not in that message commenting on whether I think PETRs are a good idea for interworking. In a later message I commented that I don't know if they are a good idea because I don't understand the security or deployment issues. [We both agree interworking is in the charter.] David> That stipulated, note that the title of the David> Interworking Draft is "Interworking LISP with IPv4 and David> IPv6". Hmm, I've always read that draft to be about how LISP works with non-lisp sites on both V4 and V6 networks. I have not read that draft to be about how LISP is used as a cross-protocol transition mechanism. I agree that some of the mechanisms described in the interworking draft do make it easier for LISP to be used as a cross-protocol mechanism. I just re-read the abstract of that draft and as far as I can tell it supports my reading of the purpose of the draft. So, I'm quite happy with the scope of the draft and the charter. >> I prefer that when we do work on a problem that we try and >> think about v6 transition. David> Please clarify. I couldn't parse that in the context David> of the rest of your note. I do below; here's an example where I think thinking about V6 transition is good: >> So, if we do PETRs, we should make them friendly to transition. David> Of course, I think everyone wants that. OK, so we're on the same page here. That's the sort of issue I'm talking about when I say when we do our work we should think about transition. >> However, since we're not in the transition business, we >> shouldn't do PETRs simply for transition. Restating: If the only reason to create PETRs were that we needed to do so in order to make LISP a better mechanism for v6 transition, then I don't think we should do so. Note that no one is claiming PETRs are only for transition. More to the point, I think if your example about why PETRs will be deployed is only about transition, then I personally believe that we should work on better deployment examples. David> Again, you've just asserted something that is neither David> supported by the charter or any consensus call that I know David> of. Yes. It's true. Remember that I said I was stating my own individual opinion--as an individual contributor *not* as a chair. The IETF is kind of frustrating, but so far, it has not yet driven me to a point where I have enough internal disunity that I need to make consensus calls inside my own head before deciding what I think.:-) In all seriousness, I think in some of the cases where you claim I made assertions, I did provide enough support that I think I contributed to the discussion. I did not provide enough support to make any comment as a chair; nor did I intend to. This has all been blown way out of proportion though: I was trying to say that I wish Darrel would focus on giving deployment examples related to interworking. Sorry it turned into such a mess. From darlewis@cisco.com Mon Sep 21 15:24: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 C94B53A68CD for ; Mon, 21 Sep 2009 15:24:05 -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 Utoasd0yhSZc for ; Mon, 21 Sep 2009 15:24:04 -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 A6A273A67B0 for ; Mon, 21 Sep 2009 15:24:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFeat0qrR7PE/2dsb2JhbAC7OIhQAY5xBYQbgV2JJQ X-IronPort-AV: E=Sophos;i="4.44,426,1249257600"; d="scan'208";a="43745819" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 21 Sep 2009 22:25:07 +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 n8LMP6iu023810; Mon, 21 Sep 2009 15:25:06 -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 n8LMP6cC016333; Mon, 21 Sep 2009 22:25:06 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); Mon, 21 Sep 2009 15:25:06 -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: Mon, 21 Sep 2009 15:25:06 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] #5: LISP protocol version is alive and kicking Thread-Index: Aco7AlQBVc2gEo6yQW6hvgkYRKGCgAABeLFA References: <20090921174923.CC40B6BE54F@mercury.lcs.mit.edu> From: "Darrel Lewis (darlewis)" To: "Sam Hartman" X-OriginalArrivalTime: 21 Sep 2009 22:25:06.0031 (UTC) FILETIME=[5ED687F0:01CA3B0A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1753; t=1253571906; x=1254435906; c=relaxed/simple; s=sjdkim4002; 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#5=3A=20LISP=20protocol=20vers ion=20is=20alive=20and=20kicking |Sender:=20; bh=n84SmkG8uI+R/8K1Arsc5aGRGVIhAyWWfBzZpLpSKTQ=; b=HKsZnm/cBBA1xd6AqqlJN863JHeprzW+xL8UvhtRfnyCRRefatEooi3ysT fLUDyz9Mrm5QdsWuaTOmvMbAVbaOaXaz0geDg0RjD267YSNLV4messh3bjZY +RraOGf//Y; Authentication-Results: sj-dkim-4; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:24:05 -0000 > >>=20 > >> I've had it kicking around the back of my brain for a while > >> now, but no great hack has appeared. I suspect the only answers > >> are painful (e.g. better co-ordination between all the xTRs at > >> a site - which we might need anyway, for other reasons). > >>=20 > >> Noel >=20 > Darrel> To me, all of this discussion makes TTL (called clock > Darrel> sweep in the draft if I remember correctly) based > Darrel> versioning better and better. It works, and keeps all of > Darrel> this complexity out of the protocol. >=20 > I'm sorry I don't follow you at all. =20 Sorry, I'll try to rephrase and provide an example below. > I guess mostly I don't follow > how clock sweep is related to the discussion, which probably means I'm > just missing a logical jump. > I'm certainly not disagreeing with setting your ttl correctly >=20 TTL versioning (called clock sweep) is a mechanism that uses operational techniques to update remote site's cache state. Say a site has this mapping: EID Foo, RLOC Bar1 - priority 1, weight 100 EID Foo, RLOC Bar2 - priority 2, weight 100 And wants to change it to: EID Foo, RLOC Bar1 - priority 1, weight 50 EID Foo, RLOC Bar2 - priority 1, weight 50 They can inform other sites via SMR bit map-requests (with the caveats we've been discussing), or they can set the TTL so that prior to the change the remote ITRs will have a short TTL and will request a new mapping (which will reflect the new settings) soon after the change is made. So Protocol mechanisms (of the various proposals we've been discussing) for versioning have the same result as the TTL method.=20 Hope that clears things up. -Darrel From hartmans@mit.edu Mon Sep 21 15:25: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 51C333A6AC4 for ; Mon, 21 Sep 2009 15:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 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 Bc3ucfWhs6CN for ; Mon, 21 Sep 2009 15:25: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 9127E3A6915 for ; Mon, 21 Sep 2009 15:25:28 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 969C3413B; Mon, 21 Sep 2009 18:26:28 -0400 (EDT) To: "Darrel Lewis \(darlewis\)" References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> From: Sam Hartman Date: Mon, 21 Sep 2009 18:26:28 -0400 In-Reply-To: (Darrel Lewis's message of "Mon\, 21 Sep 2009 11\:39\:28 -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, Noel Chiappa , Robin Whittle Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:25:29 -0000 >>>>> "Darrel" == Darrel Lewis (darlewis) writes: Darrel> For v6, we have a difference of opinion here it seems. I Darrel> believe that using this to hop over my provider's v4 only Darrel> access network is interesting. I do too. I think my message was read as a broader statement than I intended. Robbin asked you roughly "Why will someone deploy the PETR I need?" You responded, as I understand it, "They might deploy a PETR so they could help you with v6." I intended to say "Really the main point here is interworking, so I'd rather focus on deployment incentives for that use case." I'll admit that if you're already using LISP, using it as a v6 transition mechanism seems like a great idea. From jnc@mercury.lcs.mit.edu Mon Sep 21 15: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 78D0C3A6B29 for ; Mon, 21 Sep 2009 15:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 wpSDainP9a3Q for ; Mon, 21 Sep 2009 15:29: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 C03873A680A for ; Mon, 21 Sep 2009 15:29:53 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id E981C6BE62F; Mon, 21 Sep 2009 18:30:54 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090921223054.E981C6BE62F@mercury.lcs.mit.edu> Date: Mon, 21 Sep 2009 18:30:54 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:29:54 -0000 > From: "Darrel Lewis (darlewis)" > C) they use LISP-NAT > ... > This is not correct, NAT is always an option. Well, don't I feel like a total idiot. So much for my proof we need PETRs. Oh well! Noel From darlewis@cisco.com Mon Sep 21 15:32: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 986D53A67AE for ; Mon, 21 Sep 2009 15:32:19 -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 xAgDcuAm1njA for ; Mon, 21 Sep 2009 15:32: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 923153A68B8 for ; Mon, 21 Sep 2009 15:32:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAL+bt0qrR7PD/2dsb2JhbAC7NIhQAY5xBYQbiwI X-IronPort-AV: E=Sophos;i="4.44,426,1249257600"; d="scan'208";a="244823706" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 21 Sep 2009 22:33:21 +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 n8LMXLpb022750; Mon, 21 Sep 2009 15:33:21 -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 n8LMXLQq023045; Mon, 21 Sep 2009 22:33:21 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); Mon, 21 Sep 2009 15:33:20 -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: Mon, 21 Sep 2009 15:33:21 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP Interworking: Proxy Egress Tunnel Routers Thread-Index: Aco7CpKHM9vP9QBSSWWBGSPr6qMU1AAADV6w References: <20090919171820.746426BE628@mercury.lcs.mit.edu><4AB5AA3C.5090805@firstpr.com.au> From: "Darrel Lewis (darlewis)" To: "Sam Hartman" X-OriginalArrivalTime: 21 Sep 2009 22:33:20.0846 (UTC) FILETIME=[85C54EE0:01CA3B0B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1513; t=1253572401; x=1254436401; 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]=20LISP=20Interworking=3A=20=20Pr oxy=20Egress=20Tunnel=20Routers |Sender:=20; bh=ZMNEKJVEkUx5xpDg+Nli9mOO2kqHrIzZVs6IV01xEL4=; b=QpniEjuep9dKkepXFeRf204cNnJFtI/C7yVDi2VyyiwMFtMnWYzKQOdNOl OmAPnZmPB8apRWHKNzaaCt0rIyBavOLJB5Ggelgl/q+XJU1X4Om/HNIzPg+a sJcdJPQ8kK; Authentication-Results: sj-dkim-3; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org, Noel Chiappa , Robin Whittle Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:32:20 -0000 =20 >=20 > >>>>> "Darrel" =3D=3D Darrel Lewis (darlewis) = writes: >=20 >=20 > Darrel> For v6, we have a difference of opinion here it seems. I > Darrel> believe that using this to hop over my provider's v4 only > Darrel> access network is interesting. =20 >=20 > I do too. >=20 > I think my message was read as a broader statement than I intended. >=20 > Robbin asked you roughly "Why will someone deploy the PETR I need?" >=20 > You responded, as I understand it, "They might deploy a PETR=20 > so they could help you with v6." >=20 > I intended to say "Really the main point here is Interworking, so I'd > rather focus on deployment incentives for that use case." >=20 > I'll admit that if you're already using LISP, using it as a v6 > transition mechanism seems like a great idea. >=20 So personally, if I was multihoming with, I'd pay for a site that would let me hop over my access provider's v4 limitations. I'd also use it because that same access provider does not allow me to bypass uRPF even on their business class service. If I could not get a PETR service 'close enough', I would use LISP-NAT for this (URPF avoidance) purpose. As Dave pointed out in his email, a very interesting (to me) side effect of both Proxy ITRs and Proxy ETRs are that LISP sites see the benefits (ingress TE and protocol independent data plane) of LISP day one. Both I consider optional however, since LISP-NAT is an alternative. =20 -Darrel From darlewis@cisco.com Mon Sep 21 15:33: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 0B7FB3A67AE for ; Mon, 21 Sep 2009 15:33:25 -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 D3C06Tb1zstO for ; Mon, 21 Sep 2009 15:33: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 3E8F53A6AD7 for ; Mon, 21 Sep 2009 15:33:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADect0qrR7PD/2dsb2JhbAC7OohQAY5xBYQbiwI X-IronPort-AV: E=Sophos;i="4.44,426,1249257600"; d="scan'208";a="393173557" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Sep 2009 22:34:26 +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 n8LMYQIA024453; Mon, 21 Sep 2009 15:34:26 -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 n8LMYQkx005149; Mon, 21 Sep 2009 22:34:26 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); Mon, 21 Sep 2009 15:34:26 -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: Mon, 21 Sep 2009 15:34:27 -0700 Message-ID: In-Reply-To: <20090921223054.E981C6BE62F@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP Interworking: Proxy Egress Tunnel Routers Thread-Index: Aco7Cy/WTyiE8Aq0QHS6X5UfPfL3TAAAGNsQ References: <20090921223054.E981C6BE62F@mercury.lcs.mit.edu> From: "Darrel Lewis (darlewis)" To: "Noel Chiappa" , X-OriginalArrivalTime: 21 Sep 2009 22:34:26.0407 (UTC) FILETIME=[ACD91F70:01CA3B0B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=393; t=1253572466; x=1254436466; 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]=20LISP=20Interworking=3A=20=20Pr oxy=20Egress=20Tunnel=20Routers |Sender:=20; bh=SW238Wz/UJAUmSLHLSwqPe80EkKzXDM+tqD7aV6rl80=; b=YkRn+g+tYyQcmL95Yg3XEPVi1gn6STfpcGtoYmiFQhSzQoAAgRnBmnsxXH U5XekQfceDOwzweOkn+u1zh9xtZX2O4EsnOQvA1TfoAM6tBx6hLbXodE6e6d XDcs0gCYyQ; Authentication-Results: sj-dkim-3; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:33:25 -0000 >=20 > > From: "Darrel Lewis (darlewis)" >=20 > > C) they use LISP-NAT > > ... > > This is not correct, NAT is always an option. >=20 > Well, don't I feel like a total idiot. So much for my proof=20 > we need PETRs. > Oh well! >=20 Well, I personally prefer both Proxy ITRs and Proxy ETRs to NAT, but your mileage may vary! :-) -Darrel From hartmans@mit.edu Mon Sep 21 15:33: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 B217728C107 for ; Mon, 21 Sep 2009 15:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 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 G8uai9nLEU1B for ; Mon, 21 Sep 2009 15:33: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 0ED2A3A6B2A for ; Mon, 21 Sep 2009 15:33:31 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2F3B7413B; Mon, 21 Sep 2009 18:34:31 -0400 (EDT) To: "Darrel Lewis \(darlewis\)" References: <20090921174923.CC40B6BE54F@mercury.lcs.mit.edu> From: Sam Hartman Date: Mon, 21 Sep 2009 18:34:31 -0400 In-Reply-To: (Darrel Lewis's message of "Mon\, 21 Sep 2009 15\:25\:06 -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] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:33:31 -0000 >>>>> "Darrel" == Darrel Lewis (darlewis) writes: Darrel> So Protocol mechanisms (of the various proposals we've Darrel> been discussing) for versioning have the same result as Darrel> the TTL method. Darrel> Hope that clears things up. Not really. I'm still very confused how this has to do with versioning of what data encapsulation I use between two XTRs, which is what we were discussing here. From darlewis@cisco.com Mon Sep 21 15:37: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 6EAF428C111 for ; Mon, 21 Sep 2009 15:37:30 -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 AOVGKVrf6kJY for ; Mon, 21 Sep 2009 15:37:29 -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 86F9C3A67B0 for ; Mon, 21 Sep 2009 15:37:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGOdt0qrR7PD/2dsb2JhbAC7IYhQAY5zBYQbiwI X-IronPort-AV: E=Sophos;i="4.44,426,1249257600"; d="scan'208";a="393174987" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Sep 2009 22:38:32 +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 n8LMcVvw030826; Mon, 21 Sep 2009 15:38:31 -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 n8LMcVL5008895; Mon, 21 Sep 2009 22:38:31 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); Mon, 21 Sep 2009 15:38:31 -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: Mon, 21 Sep 2009 15:38:32 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] #5: LISP protocol version is alive and kicking Thread-Index: Aco7C73pVYTa2dIuTZedvORWwNi8yAAADecQ References: <20090921174923.CC40B6BE54F@mercury.lcs.mit.edu> From: "Darrel Lewis (darlewis)" To: "Sam Hartman" X-OriginalArrivalTime: 21 Sep 2009 22:38:31.0791 (UTC) FILETIME=[3F1BBFF0:01CA3B0C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=735; t=1253572711; x=1254436711; 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]=20#5=3A=20LISP=20protocol=20vers ion=20is=20alive=20and=20kicking |Sender:=20; bh=ILRXaNh9va4+moRI6A0WKY5CxKUMIN5MojmlhH8cCH4=; b=vHFyZHmlaaGAy4+sbxrtdOPDXa5ukC8lIkdfFOAyWPhv4rxJphUbYgVDbm Boxbi9JQr/ElxeW+aByrAQ+YqNNAxZCYucME+tNpIRPCQtqvA6FcvymJ6IHq qhkC/FrgmP; Authentication-Results: sj-dkim-3; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:37:30 -0000 >=20 > >>>>> "Darrel" =3D=3D Darrel Lewis (darlewis) = writes: >=20 >=20 > Darrel> So Protocol mechanisms (of the various proposals we've > Darrel> been discussing) for versioning have the same result as > Darrel> the TTL method. >=20 > Darrel> Hope that clears things up. >=20 > Not really. I'm still very confused how this has to do with > versioning of what data encapsulation I use between two XTRs, which is > what we were discussing here. >=20 If the data plane version (the example I used was the mapping version) changes, and its indicated in the map-request/map-reply, then instigating that message exchange will update the ITR side of the conversation. -Darrel From jnc@mercury.lcs.mit.edu Mon Sep 21 15:39: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 321153A6851 for ; Mon, 21 Sep 2009 15:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 eLmJGRS2Paci for ; Mon, 21 Sep 2009 15:39: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 5CC893A680A for ; Mon, 21 Sep 2009 15:39:56 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4C2CA6BE62F; Mon, 21 Sep 2009 18:40:58 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090921224058.4C2CA6BE62F@mercury.lcs.mit.edu> Date: Mon, 21 Sep 2009 18:40:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:39:57 -0000 > From: "Darrel Lewis (darlewis)" >> a general problem with square routing (i.e. packets from site A to B >> flow from ITR a1 to ETR b1, packets back from B to A flow via ITR b2 >> and ETR a2) ... the b2 ITR doesn't have the mapping, either. >> ... >> I suspect the only answers are painful (e.g. better co-ordination >> between all the xTRs at a site - which we might need anyway, for other >> reasons). > To me, all of this discussion makes TTL ... based versioning better and > better. It works, and keeps all of this complexity out of the protocol. My brain clearly isn't working well today, but I'm missing something here. I guess I don't see how having the ability to detect stale mappings helps you with the problem I mentioned above? (And we _have_ to pick some different terminology - header 'versioning' and mapping 'versioning' are just _too_ similar.) If b2 never got a mapping for A (because it got neither user-traffic which it could glean a mapping for A from, nor a Map-Request with piggybacked information for A), how is it going to get a mapping for A unless either i) it talks to its fellow ETR b1, or ii) it goes through a mapping-resolution cycle on A? Noel From darlewis@cisco.com Mon Sep 21 15:42: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 E144728C0F4 for ; Mon, 21 Sep 2009 15:42:26 -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 nSwu53SgV64e for ; Mon, 21 Sep 2009 15:42:25 -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 86A7828C12D for ; Mon, 21 Sep 2009 15:42:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANqdt0qrR7O6/2dsb2JhbAC7K4hQAY5zBYQbiwI X-IronPort-AV: E=Sophos;i="4.44,426,1249257600"; d="scan'208";a="43751374" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 21 Sep 2009 22:43:27 +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 n8LMhRSY001543; Mon, 21 Sep 2009 15:43:27 -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 n8LMhR9k001645; Mon, 21 Sep 2009 22:43:27 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); Mon, 21 Sep 2009 15:43:27 -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: Mon, 21 Sep 2009 15:43:28 -0700 Message-ID: In-Reply-To: <20090921224058.4C2CA6BE62F@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] #5: LISP protocol version is alive and kicking Thread-Index: Aco7DJeO34t+gKiURL+8c6jkmGtzwAAACdgQ References: <20090921224058.4C2CA6BE62F@mercury.lcs.mit.edu> From: "Darrel Lewis (darlewis)" To: "Noel Chiappa" , X-OriginalArrivalTime: 21 Sep 2009 22:43:27.0581 (UTC) FILETIME=[EF69B8D0:01CA3B0C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=575; t=1253573007; x=1254437007; 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#5=3A=20LISP=20protocol=20vers ion=20is=20alive=20and=20kicking |Sender:=20; bh=qjvq8nlLJEBPYD1B1W0EqJCidQpjbnfbIuuadlK8pt8=; b=CStUQyIbELwpxGqxpjcuqKNyzvfmKPr4KQHEDBwf3fpOHRAxUl7RXuKa2L fwPGlzipKbzHef/reKafYnKqdfFVRYqGreaImdUj7MmtjRU4MxwxWzYusDYJ vwqJY9bp1E; Authentication-Results: sj-dkim-2; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:42:27 -0000 =20 >=20 > If b2 never got a mapping for A (because it got neither=20 > user-traffic which it > could glean a mapping for A from, nor a Map-Request with piggybacked > information for A), how is it going to get a mapping for A=20 > unless either i) > it talks to its fellow ETR b1, or ii) it goes through a=20 > mapping-resolution > cycle on A? >=20 Right it goes through a mapping resolution cycle. This is a feature. The ETR can then use clock sweep if the "header version" changes and it wants to have ITRs re-learn and see the new information. -Darrel From jnc@mercury.lcs.mit.edu Mon Sep 21 15:51: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 ADE1F28C132 for ; Mon, 21 Sep 2009 15:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 sg9L4L4zbbRM for ; Mon, 21 Sep 2009 15:51: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 282083A6890 for ; Mon, 21 Sep 2009 15:51:17 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C3BA46BE62F; Mon, 21 Sep 2009 18:52:18 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090921225218.C3BA46BE62F@mercury.lcs.mit.edu> Date: Mon, 21 Sep 2009 18:52:18 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:51:18 -0000 > From: "Darrel Lewis (darlewis)" > I personally prefer both Proxy ITRs and Proxy ETRs to NAT, but your > mileage may vary! :-) Well, funny you should say that, because I was thinking, after I sent the previous message, that it is of course always better to avoid NAT if you can; because NAT mangles packets (which breaks some things, including some kinds of IPSec, for instance), and won't always work (e.g. for protocols which won't work through NATs, e.g. if they have embedded addresses, etc). So LISP-NAT is not actually a 100% replacement for a PETR if you're on a uRPF ISP. (Did I just set some sort of jargon record in that sentence? :-) Noel From jmh@joelhalpern.com Mon Sep 21 15:59: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 1622E3A6873 for ; Mon, 21 Sep 2009 15:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 d5o9kdEXCkA6 for ; Mon, 21 Sep 2009 15:59:52 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 617903A67F7 for ; Mon, 21 Sep 2009 15:59:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id EDDCC32317F6 for ; Mon, 21 Sep 2009 16:00:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 79D9932317FB for ; Mon, 21 Sep 2009 16:00:54 -0700 (PDT) Message-ID: <4AB805A4.6000806@joelhalpern.com> Date: Mon, 21 Sep 2009 19:00:52 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: lisp@ietf.org References: <20090921225218.C3BA46BE62F@mercury.lcs.mit.edu> In-Reply-To: <20090921225218.C3BA46BE62F@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 21 Sep 2009 22:59:53 -0000 (Using Noel's response as a hook for a related point. I don't disagree with him.) A further complication is that in order for a site to have the option of avoiding LISP-NAT, someone else has to have sufficient deploy RITRs and PETRs that the sites outbound traffic has PETRs to use, and that inbound legacy traffic has PITRs to use. So, unless there is a deployment model in which PITR and PETR deployments make economic sense, LISP will be dependent upon LISP-NAT. I for one do not consider NAT a solution worth offering the world. (That sentence assumes all sorts of aspects of LISP goals, deployment and usage. Your mileage may differ.) Yours, Joel Noel Chiappa wrote: > > From: "Darrel Lewis (darlewis)" > > > I personally prefer both Proxy ITRs and Proxy ETRs to NAT, but your > > mileage may vary! :-) > > Well, funny you should say that, because I was thinking, after I sent the > previous message, that it is of course always better to avoid NAT if you can; > because NAT mangles packets (which breaks some things, including some kinds of > IPSec, for instance), and won't always work (e.g. for protocols which won't > work through NATs, e.g. if they have embedded addresses, etc). > > So LISP-NAT is not actually a 100% replacement for a PETR if you're on a uRPF > ISP. (Did I just set some sort of jargon record in that sentence? :-) > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From bew@cisco.com Mon Sep 21 17:18: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 A06763A6966 for ; Mon, 21 Sep 2009 17:18: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 ZgbS844lYvsd for ; Mon, 21 Sep 2009 17:18:12 -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 B54EA3A6911 for ; Mon, 21 Sep 2009 17:18:12 -0700 (PDT) X-Files: smime.p7s : 2409 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEq1t0qrR7O6/2dsb2JhbAC7KYhQATIJjkMFgkeBVA X-IronPort-AV: E=Sophos;i="4.44,427,1249257600"; d="p7s'?scan'208";a="95718292" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 22 Sep 2009 00:19:15 +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 n8M0JEQA014309 for ; Mon, 21 Sep 2009 17:19:14 -0700 Received: from [192.168.19.43] (sjc-vpn6-1662.cisco.com [10.21.126.126]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n8M0JEUR020694 for ; Tue, 22 Sep 2009 00:19:14 GMT Message-Id: <98A247EE-8362-4FB9-B0BE-8A7DAC77F087@cisco.com> From: Brian Weis To: lisp@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-6-393647359; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 21 Sep 2009 17:19:14 -0700 X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5039; t=1253578754; x=1254442754; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20To=20IPsec=20or=20not=20IPsec=20(Issue=20#2)? |Sender:=20; bh=8TG61USzCXNQYPFCumeWgJwYw84XJxQ3sU4AMtkRw+c=; b=FIwePN09d65ms7Z9TaOykp21K4bRrmynOvE5DHxT3SAfeQBFaWy4TC5Yap 2gsrRwe6nJCAmRKQCRdcctaSv8M3um2kQY6PQZEqwxWd7LPf4Cx1+dtp4vIw lBDtSuOMC0; Authentication-Results: sj-dkim-2; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [lisp] To IPsec or not IPsec (Issue #2)? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 00:18:13 -0000 --Apple-Mail-6-393647359 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Folks, Issue #2 for lisp-ms makes the statement "IPSec is not a good fit for this application.", and I tend to agree. All that seems wanted for the Map-Server is a packet integrity method, and while AH or ESP can provide just that there are some issues: - AH or ESP can complicate getting through firewalls located between the Map Server and ETR. Rules allowing LISP and AH both are needed, and since it's doubtful that an administrator will want to allow all AH in/out, those firewall rules may need to be fairly specific. - The amount of IPsec specificity needed seems more than such a simple mechanism really needs. This is a common complaint for protecting routing protocols. Would there be support for replacing the use of AH with a simple Authentication Data field in the Map-Register packet? Defining one or more MACs and their usage for this protocol can be straightforward. Key management would most certainly be restricted to manually shared keys for now (which does not address the other part of issue #2), but it can be automated if and when a generalized automated key management method for routing is defined. It's possible that KMART will become a WG and do such a thing, although that isn't guarenteed. Comments? Brian -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --Apple-Mail-6-393647359 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGGzCCAtQw ggI9oAMCAQICED3kRzyTlgHwpIFY9dGobk0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDEyMzIyMzE1MloXDTEwMDEyMzIyMzE1 MlowPzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEcMBoGCSqGSIb3DQEJARYNYmV3 QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKnQU19mWEIXyWWjCbxX qiBqjSNebZKdJA4Xp7wfo2BcoK8PpRLMtszRB2fel47AFuVBo+l9ORhxzSHuBPnaNpYFFyf4Nh+m qD4pTq3i8YWSnV31JZEeUaSIH07rr5HIoQ3m/8d/hYYmoN/7RdLMShfxqlvVCoawmhOs33KRjvbm tKCVVPFNvIvu/dISZJFEWW/0+ICwxBx9+8vhbXKtUSyGMoIEQQGqNggnCKKEvCvzlTX6Xko9pqsb ULYv18nrycyVJ5/6/jrORMN21x3GymKqbIgop78z+ZlcBrAiViAiUXtXaOTB9KLP66uynvBhdH7h fzpsCxykVIKy5zs57J8CAwEAAaMqMCgwGAYDVR0RBBEwD4ENYmV3QGNpc2NvLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAAqShEZQ/wJ4vQwsY979MGV53fz06u2IHmU1Zgf6DbiL wBTPWK7v/P9fQpnQvea+R0DaPUTSXoecheYcwTSh/sEgLtcuDaj2JIzTxEGKBNoem8WGk5lOQ+gm PhbM8PKHNBRyESUlS1UqvJP9itZjXk8Xh3eqDaPWILBkxR/RcdHhMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoe aMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwL B+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3 +wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDov L2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEG MCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUF AAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD 2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj ViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhA95Ec8k5YB8KSBWPXRqG5NMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDkyMjAwMTkxNFowIwYJKoZI hvcNAQkEMRYEFJaxVG8RJeXfxo3lG+NyhSdJg+T2MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPeRHPJOWAfCkgVj10ahuTTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQPeRHPJOWAfCkgVj10ahuTTANBgkqhkiG9w0BAQEFAASCAQClvEXBJgHSv2djIk4iBuCxHgH7 KHD/M0WMGlOE/3TfXPyuGVQgkFNPUaKl00EDb5qeGrfAmRWBrNl9idAan7JAgSSFR+jwLtygFkQm tmiYSGl5uT8LI32Xb/TcGDtPphPIrF35BLoySzEWmbkjPG80rdASi2hLBYDY+l/Z3cMeeIOfUbct kE/QCU8DIfR4X7lQAbRoTPSHAhU3KmpXCE4H1Zkd1aGYwEceoEmX75X1qjCxYlCaLGGNvss9J1RZ liOMLobld6vq+YRUOxqzpwEgZ+C2Yz6qvxZ5vzer+++p9eQkJPiocnLpsbcNIft5NCa8geA4GYGU J3w8vmBtDeqwAAAAAAAA --Apple-Mail-6-393647359-- From dino@cisco.com Mon Sep 21 17:23: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 8EF893A68C8 for ; Mon, 21 Sep 2009 17:23:38 -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 L5ilFT2WVdNT for ; Mon, 21 Sep 2009 17:23:37 -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 D312A3A6900 for ; Mon, 21 Sep 2009 17:23:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHe2t0qrR7PE/2dsb2JhbAC7HIhQAY5+BYQb X-IronPort-AV: E=Sophos;i="4.44,427,1249257600"; d="scan'208";a="95720929" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 22 Sep 2009 00:24: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 n8M0OdCN005806 for ; Mon, 21 Sep 2009 17:24:39 -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 n8M0Odqo008024 for ; Tue, 22 Sep 2009 00:24:39 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, 21 Sep 2009 17:24:39 -0700 Received: from [192.168.1.2] ([10.21.126.50]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 17:24:39 -0700 Message-Id: From: Dino Farinacci To: Brian Weis In-Reply-To: <98A247EE-8362-4FB9-B0BE-8A7DAC77F087@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: Mon, 21 Sep 2009 17:24:38 -0700 References: <98A247EE-8362-4FB9-B0BE-8A7DAC77F087@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 00:24:39.0227 (UTC) FILETIME=[126560B0:01CA3B1B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=659; t=1253579079; x=1254443079; 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]=20To=20IPsec=20or=20not=20IPsec= 20(Issue=20#2)? |Sender:=20; bh=YloGTJGHcyNdlY1Dy4sOB9VH95VSepIB0mJo2vLvR30=; b=bqVzqSdx6lvAzHK+2Ht5T8h/2mchjpjmXkZYhPZtGgNXREm8uhj33Cs59o gRccHzGa9Ej795HSduB6afbORdSj1aB4h/7/9W+tC7vvvWVzWf1lqEoSdzLk der87pgeHu; 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] To IPsec or not IPsec (Issue #2)? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 00:23:38 -0000 > Would there be support for replacing the use of AH with a simple > Authentication Data field in the Map-Register packet? Defining one > or more MACs and their usage for this protocol can be > straightforward. Key management would most certainly be restricted > to manually shared keys for now (which does not address the other > part of issue #2), but it can be automated if and when a generalized > automated key management method for routing is defined. It's > possible that KMART will become a WG and do such a thing, although > that isn't guarenteed. I support the idea of LISP removing the dependency on AH headers. Dino From jzwiebel@cisco.com Mon Sep 21 17:31: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 4C64A3A69C9 for ; Mon, 21 Sep 2009 17:31:01 -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=[AWL=-0.000, 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 8HxteyMfiein for ; Mon, 21 Sep 2009 17:31:00 -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 4EA8C3A68C8 for ; Mon, 21 Sep 2009 17:31:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKO3t0qrR7PE/2dsb2JhbACCKiy4S4hQAY58BYQb X-IronPort-AV: E=Sophos;i="4.44,427,1249257600"; d="scan'208,217";a="95724493" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 22 Sep 2009 00:32:03 +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 n8M0W217013355 for ; Mon, 21 Sep 2009 17:32:02 -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 n8M0W2wL017082 for ; Tue, 22 Sep 2009 00:32:02 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); Mon, 21 Sep 2009 17:32:02 -0700 Received: from [10.0.1.3] ([10.21.83.192]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 17:32:02 -0700 In-Reply-To: <98A247EE-8362-4FB9-B0BE-8A7DAC77F087@cisco.com> References: <98A247EE-8362-4FB9-B0BE-8A7DAC77F087@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-72-394410282 Message-Id: <26D8D831-6CDE-4948-9ECE-7744A1562172@cisco.com> From: John Zwiebel Date: Mon, 21 Sep 2009 14:31:57 -1000 To: Brian Weis X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 22 Sep 2009 00:32:02.0474 (UTC) FILETIME=[1A9780A0:01CA3B1C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1033; t=1253579522; x=1254443522; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[lisp]=20To=20IPsec=20or=20not=20IPsec= 20(Issue=20#2)? |Sender:=20; bh=4DnuGTDIzJ4IyH/8nFktcGGWmGUtfv3Zesz9JjI2aUs=; b=JKSW/f9RlsNmbo4xkakjqUVvbXMsCIXfkC3Lh5cYF4kxcQt7+2PZtgC46q v7SvcfHro27r8sLK76+HQZ7DZfebxlJzzD0C7EP/2DVuJuQN+ZseJ3/jWYb5 sohHxOPTi9; 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] To IPsec or not IPsec (Issue #2)? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 00:31:01 -0000 --Apple-Mail-72-394410282 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 21, 2009, at 2:19 PM, Brian Weis wrote: > > Would there be support for replacing the use of AH with a simple > Authentication Data field in the Map-Register packet? +1 --Apple-Mail-72-394410282 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
On Sep 21, 2009, at 2:19 PM, Brian Weis wrote:


Would there be support for replacing the use of AH with a simple Authentication Data field in the Map-Register packet?


+1
--Apple-Mail-72-394410282-- From jnc@mercury.lcs.mit.edu Mon Sep 21 18:22: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 C95443A69D7 for ; Mon, 21 Sep 2009 18:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 bR4sWMmbel-r for ; Mon, 21 Sep 2009 18:22:59 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0BD393A696C for ; Mon, 21 Sep 2009 18:22:58 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 8C8286BE631; Mon, 21 Sep 2009 21:24:00 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090922012400.8C8286BE631@mercury.lcs.mit.edu> Date: Mon, 21 Sep 2009 21:24:00 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 01:22:59 -0000 > From: "Joel M. Halpern" > in order for a site to have the option of avoiding LISP-NAT, someone > else has to have sufficient deploy RITRs and PETRs that the sites > outbound traffic has PETRs to use, and that inbound legacy traffic has > PITRs to use. Yes, but just like PETRs (in fact, moreso), PITRs are 'bound' to specific LISP sites. If PITR P is the PITR for EID's E0-En at LISP site L, P has to advertize those EIDs into the routing, so that packets for E0-En get sent to P, so it can encapsulate them and send them to L. Presumably P will not do this unless it has some relationship (involving money) with L. (Either that, or P belongs to the owner of L.) Yes, yes, I know there are issues with the location of PITRs and PETRs. But that's second-order... > So, unless there is a deployment model in which PITR and PETR > deployments make economic sense, LISP will be dependent upon LISP-NAT. Do you not believe that demand will drive provision of these services? That's the way the network grew, let's not forget (i.e. driven by demand). Noel From hartmans@mit.edu Mon Sep 21 18:57: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 88CFD3A679F for ; Mon, 21 Sep 2009 18:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 OSIYfiVlzQNt for ; Mon, 21 Sep 2009 18:57: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 74BA23A659B for ; Mon, 21 Sep 2009 18:57:07 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A0307413B; Mon, 21 Sep 2009 21:58:07 -0400 (EDT) To: Brian Weis References: <98A247EE-8362-4FB9-B0BE-8A7DAC77F087@cisco.com> From: Sam Hartman Date: Mon, 21 Sep 2009 21:58:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] To IPsec or not IPsec (Issue #2)? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 01:57:08 -0000 Brian, I'd like to respond to one part of your proposal. I'm very concerned about the idea of publishing a LISP spec without a mechanism for mandatory-to-implement automated key management. I understand you are familiar with the issues here, but I'd like to educate the rest of the working group. RFC 4107 describes the IETF's consensus requirements on when automated key management is required. First, automated key management does not mean we need to have a PKI or even use public key operations. Generally, we would choose a protocol that had these options available, although we might not make them mandatory to implement. for example we could use a key management protocol that used shared secrets as the basis for automated key management. Vendors whose customers requested the option might implement public key base functionality. For example, if a service provider is keying LISP CPE equipment at some central facility for shipment to customers, they would likely prefer to use certificates rather than shared secrets. We see this a lot in the cable modem space and this is the model behind CAPWAP's security. However we could make the shared secret variant of our key management protocol the mandatory to implement version. Automated key management would give us several advantages. It would provide us replay protection and liveness detection. Section 2.1 of RFC 4107 describes conditions under which automated key management is required. There are some tradeoffs involved there, and we as a community over a number of meetings decided where we'd draw the bar. However the wording is not as clear as it could be. I believe that there is one case that explicitly forces us into requiring automated key management. The likely operational environment is one where personnel (or device) turnover is frequent, causing frequent change of the short-term session key. As I understood it when I was making these sorts of decisions on behalf of the IESG, an environment where systems exist for a long time in different organizations is likely to be such an operational environment. It seems likely that the map server will be in a different organization than the ETR and that over the lifetime of some of the keys involved we might have significant staff turnover. Also, another requirement while it does not directly apply to us hints at a general condition that does apply: A party will have to manage n^2 static keys, where n may become large. (I actually wonder whether that text is misworded; I'm having trouble designing a protocol where one party has to manage n^2 keys). A map server might well need to manage thousands of associations as Dino pointed out. This argues (although perhaps not of itself compels) automated key management. I think there is general agreement in the security community (although perhaps not in the routing community) that if our routing protocols were designed today they would need automated key management. For a variety of reasons we have not placed this requirement. One reason is that routing protocols don't fit the requirements of our existing key management solutions. In the case of OSPF, ISIS and other multicast protocols, the gap is huge. In the case of some other protocols, it's less clear how big the gap is. However, it seems very likely to me that the map server falls within the requirement space of a number of existing key management protocols. These protocols have definitely been implemented in the control planes of high-end routers as well as on low-end CPE equipment. In several cases we have strong evidence that protocols can meet any possible performance requirements for map servers. So, I think that if we choose to specify and implement automated key management we could do so. I don't think we have a good justification to wait for KMART. At the end of the process, the chair submitting the draft (probably me for the core and ms specs) does a technical and process review of the documents. If we choose not to specify and implement automated key management, we must justify our choice in the security considerations section. Obviously, I'll read whatever we write, but at this moment I'm unable to imagine text so compelling that I'd be able to recommend publication of the specifications without automated key management. Another question that is probably on everyone's mind: we're writing experimental documents; do we have to do this for experimental. Darrel, Jari and I had a great conversation on what it meant for us to be writing experimental documents. We want to use the experimental out when there's some reason why we don't have enough information to specify something or why we need to do additional experiments, not simply to get done faster or to avoid coming to consensus on a difficult issue. I cannot imagine anything about automated key management for LISP that would fall into this category. Sam Hartman LISP Co-chair From hartmans@mit.edu Mon Sep 21 19:03: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 0396D3A659B for ; Mon, 21 Sep 2009 19:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 axOQJBy4-ysB for ; Mon, 21 Sep 2009 19:03:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 31F233A6896 for ; Mon, 21 Sep 2009 19:03:30 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BF562413B; Mon, 21 Sep 2009 22:04:30 -0400 (EDT) To: Brian Weis References: <98A247EE-8362-4FB9-B0BE-8A7DAC77F087@cisco.com> From: Sam Hartman Date: Mon, 21 Sep 2009 22:04:30 -0400 In-Reply-To: <98A247EE-8362-4FB9-B0BE-8A7DAC77F087@cisco.com> (Brian Weis's message of "Mon\, 21 Sep 2009 17\:19\: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: lisp@ietf.org Subject: Re: [lisp] To IPsec or not IPsec (Issue #2)? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 02:03:31 -0000 >>>>> "Brian" == Brian Weis writes: Brian> Would there be support for replacing the use of AH with a Brian> simple Authentication Data field in the Map-Register Brian> packet? Defining one or more MACs and their usage for this Brian> protocol can be straightforward. Key management would most Brian> certainly be restricted to manually shared keys for now Brian> (which does not address the other part of issue #2), but it Brian> can be automated if and when a generalized automated key Brian> management method for routing is defined. It's possible Brian> that KMART will become a WG and do such a thing, although Brian> that isn't guarenteed. I now put on my implementation hat. It would be really convenient for me if we made this change even if it were a temporary change. I have two hesitations about this long term: 1) I suspect that replay protection of map register messages is important. If you don't have replay protection, then if I ever see one of your map register messages, I can replay it later and direct your mapping requests back to a previous locator. That seems problematic for ETRs that ever move locators. I can't tell how important this is until I understand the deployment model, however it seems very significant to me. Performing replay prevention with this sort of add-mac-to-packet is a bit tricky. 2) I suspect that transport area requirements will cause us to add some sort of acknowledgement and more transport-like protocol to the map register messages and interactions. Long term I think the simplest thing for us to do in that space will be to go to TCP. I'm not sure that this approach is the best choice there. However I can say some very positive things about your proposal: * I think it is strictly better than the IPsec AH we're using today * I'm happy to implement it now and change to something else if we need to later * I believe that we could build automated key management on top of such a proposal--for example DTLS plus extractor. From dmm@1-4-5.net Mon Sep 21 19:05: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 9EA273A67BE for ; Mon, 21 Sep 2009 19:05: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 xAfR3aA1pgKI for ; Mon, 21 Sep 2009 19:05:44 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id D737D3A67F9 for ; Mon, 21 Sep 2009 19:05:44 -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 n8M26ex4015375; Mon, 21 Sep 2009 19:06:40 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n8M26ehO015374; Mon, 21 Sep 2009 19:06:40 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 21 Sep 2009 19:06:40 -0700 From: David Meyer To: Dino Farinacci Message-ID: <20090922020640.GA15350@1-4-5.net> References: <98A247EE-8362-4FB9-B0BE-8A7DAC77F087@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" 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] To IPsec or not IPsec (Issue #2)? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 02:05:45 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 21, 2009 at 05:24:38PM -0700, Dino Farinacci wrote: >> Would there be support for replacing the use of AH with a simple =20 >> Authentication Data field in the Map-Register packet? Defining one or=20 >> more MACs and their usage for this protocol can be straightforward. Key= =20 >> management would most certainly be restricted to manually shared keys=20 >> for now (which does not address the other part of issue #2), but it can= =20 >> be automated if and when a generalized automated key management method= =20 >> for routing is defined. It's possible that KMART will become a WG and=20 >> do such a thing, although that isn't guarenteed. > > I support the idea of LISP removing the dependency on AH headers. Likewise. Dave --wac7ysb48OaltWcw 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) iEYEARECAAYFAkq4MTAACgkQORgD1qCZ2Kf5kgCfXH/gN2pWNTRQDBl4WCHSoPuE fkgAnRQGCvUj9fFiv8inqJ6JwNOsD/bx =g/1j -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From jnc@mercury.lcs.mit.edu Mon Sep 21 19:12: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 435DC3A67D3 for ; Mon, 21 Sep 2009 19:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 M6tdbMkHs+bJ for ; Mon, 21 Sep 2009 19:12: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 74B783A67BE for ; Mon, 21 Sep 2009 19:12:08 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2676A6BE632; Mon, 21 Sep 2009 22:13:10 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090922021310.2676A6BE632@mercury.lcs.mit.edu> Date: Mon, 21 Sep 2009 22:13:10 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 02:12:09 -0000 > From: "Darrel Lewis (darlewis)" >> If b2 never got a mapping for A (because it got neither user-traffic >> which it could glean a mapping for A from, nor a Map-Request with >> piggybacked information for A), how is it going to get a mapping for A >> unless either i) it talks to its fellow ETR b1, or ii) it goes through >> a mapping-resolution cycle on A? > Right it goes through a mapping resolution cycle. Well, that's what people don't like - the RTT (at least) to get a mapping back. And you've also got the issue of 'what do you do with the return packet in the interim', which we have touched on before - do you queue it, discard it, what? If you discard it, as discussed before, you've got to wait for someone to timeout, and re-transmit. Add to this the notion that most interactions on the network these days are client-server, and in the example above, the server is going to be B. So the server's not going to be able to get the reply back to the user without an RTT. I suspect most content providers will find that unacceptable. And if you _drop_ the return packet, because you don't have a mapping - they will not be happy. There are other ways to solve this particular problem, e.g. make sure that traffic both to and from EIDs E0-EN is sent through xTR bj, so you don't get square/triangle routing. But I'm not sure people will find that acceptable. (And BTW I think we also get this with triangle routing, i.e. with traffic flowing a->b1->server->b2->a.) Noel From jmh@joelhalpern.com Mon Sep 21 19:40: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 9621C3A6970 for ; Mon, 21 Sep 2009 19:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=-0.248, 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 Hw9oVZgBr4ih for ; Mon, 21 Sep 2009 19:40:32 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 120E63A67D3 for ; Mon, 21 Sep 2009 19:40:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id DAA0332317A2; Mon, 21 Sep 2009 19:41:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 4590F32317A1; Mon, 21 Sep 2009 19:41:34 -0700 (PDT) Message-ID: <4AB8395B.5010600@joelhalpern.com> Date: Mon, 21 Sep 2009 22:41:31 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Noel Chiappa References: <20090922012400.8C8286BE631@mercury.lcs.mit.edu> In-Reply-To: <20090922012400.8C8286BE631@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 02:40:33 -0000 Actually, as I understand the PITR proposal, the PITR advertises in BGP a short prefix for a large block of EIDs. If it does not do this, then during transition (half of forever), we get an increase in routing table size instead of a decrease. But if the PITR advertises large blocks of EIDs, then it has to serve the EIDs within those blocks. Whether the actual assignee of that block has paid for them or not. (The assignee can not choose a different PITR advertiser, because the advertisement is already there.) Darrel has suggested that folks would do this because it draws traffic to them. But for the most part, that traffic arrives and then leaves. Increasing traffic load in both directions does not do an ISP any good. It can cost real dollars. (There are cases where being able to draw traffic for your customers is good. But the EID prefixes do not correspond to ISP customer sets.) This kind of analysis (what would be advertised, who would advertise it, what would the impact be, and why would someone do it) needs to be provided at some point. As Sam has said several times, the degree of relevance, and the possible models, depend heavily upon the deployment assumptions. Yours, Joel Noel Chiappa wrote: > > From: "Joel M. Halpern" > > > in order for a site to have the option of avoiding LISP-NAT, someone > > else has to have sufficient deploy RITRs and PETRs that the sites > > outbound traffic has PETRs to use, and that inbound legacy traffic has > > PITRs to use. > > Yes, but just like PETRs (in fact, moreso), PITRs are 'bound' to specific LISP > sites. If PITR P is the PITR for EID's E0-En at LISP site L, P has to > advertize those EIDs into the routing, so that packets for E0-En get sent to > P, so it can encapsulate them and send them to L. Presumably P will not do > this unless it has some relationship (involving money) with L. (Either that, > or P belongs to the owner of L.) > > Yes, yes, I know there are issues with the location of PITRs and PETRs. But > that's second-order... > > > So, unless there is a deployment model in which PITR and PETR > > deployments make economic sense, LISP will be dependent upon LISP-NAT. > > Do you not believe that demand will drive provision of these services? That's > the way the network grew, let's not forget (i.e. driven by demand). > > Noel > From jmh@joelhalpern.com Mon Sep 21 20:10: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 436373A679F for ; Mon, 21 Sep 2009 20:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=-0.247, 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 7xxAuq-OYP7b for ; Mon, 21 Sep 2009 20:10:19 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 9757C3A6800 for ; Mon, 21 Sep 2009 20:10:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id ACC013231776; Mon, 21 Sep 2009 20:11:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 257A332317A2; Mon, 21 Sep 2009 20:11:22 -0700 (PDT) Message-ID: <4AB84057.4000906@joelhalpern.com> Date: Mon, 21 Sep 2009 23:11:19 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Noel Chiappa , "lisp@ietf.org" References: <20090922030534.828906BE631@mercury.lcs.mit.edu> In-Reply-To: <20090922030534.828906BE631@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 03:10:20 -0000 At least in theory, we get to replace several multi-homed sites, each with their own PI address with a single PITR advertisement for their EID block. Obviosuly, there is going to be some period of time when folks won't trust the PITRs, etc... But at least that is a theory which, if I could believe the PITR deployment story, lead towards reduction. Yours, Joel Noel Chiappa wrote: > > the PITR advertises in BGP a short prefix for a large block of EIDs. > > Right, I forgot about that. > > The problem with doing that is that if EIDs in that block are scattered, > topologically, you'll wind up with longer paths. TANSTAAFL... Course, that is > only true for traffic from non-LISP sites.. > > > If it does not do this, then during transition (half of forever), we > > get an increase in routing table size instead of a decrease. > > Routing table size is a whole discussion in itself. > > Even with a certain amount of reduction of splittage, you still wind up > needing to advertize both EIDs _and_ RLOCs, i.e. potentially more stuff. I'd > been hoping to be able to, before long, get to a situation where parts of the > network did not include all of (legacy-addresses, EIDs, RLOCs). > > Noel > From vaf@cisco.com Mon Sep 21 21:33: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 B69E93A68C8 for ; Mon, 21 Sep 2009 21:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=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 v-5rZjmyDOFa for ; Mon, 21 Sep 2009 21:33:01 -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 80A0D3A682E for ; Mon, 21 Sep 2009 21:33:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA7xt0qrR7PE/2dsb2JhbAC8WohQAY8pBYQbiwI X-IronPort-AV: E=Sophos;i="4.44,429,1249257600"; d="scan'208";a="191149544" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 22 Sep 2009 04:34:04 +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 n8M4Y4KK024655; Mon, 21 Sep 2009 21:34:04 -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 n8M4Y4X9002278; Tue, 22 Sep 2009 04:34:04 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 n8M4Qb4f017096; Mon, 21 Sep 2009 21:26:37 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n8M4QbOd017089; Mon, 21 Sep 2009 21:26:37 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Mon, 21 Sep 2009 21:26:37 -0700 From: Vince Fuller To: Sam Hartman Message-ID: <20090922042637.GA14702@vaf-lnx1> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5511; t=1253594044; x=1254458044; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20proposed=20fix=20issue=20#22=20-=20processing=2 0of=20Encapsulated=20Map=20Requests |Sender:=20; bh=3V9pPrMU4eybaaVNuJSMyqIVLKgHJo1VNtcDcqEgJbs=; b=je51ehRWEFJW/RxG9TZ/n1b3D+RIVxcathcgHJOQJyc58o45HxW4Abcd16 8bymQ/10X9AeH+BQuht3BQ8a26I8dPQ837X732YPL7Vl+6b4gA8Nf7i+Acmy 9e8VIkGL1R; Authentication-Results: sj-dkim-4; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 04:33:02 -0000 Hi Sam- Here's how the LISP co-authors want to resolve the open issue around the origination and processing of Encapsulated Map Requests by ITRs, Map-Resolvers, Map-Servers, and ETRs. During implementation, we actually ran this before it was raised on the mailing list and believe we have a simple but effective way to deal with it. We plan to incorporate new text in new revisions of the affected drafts (draft-ietf-lisp-05, draft-ietf-lisp-ms-03, draft-lisp-multicast-02). Thanks, --Vince (for the LISP-main and LISP-MS co-authors) -------------------- Problem summary: LISP implementors and lisp@ietf.org list members have independently found a design and implementation issue with the origination and processing of Encapsulated Map-Requests. The LISP team proposes changes to both the base LISP specification (currently, draft-ietf-lisp-04.txt) and to LISP-MS (draft-ietf-lisp-ms-02.txt) to address this. Since LISP Multicast (draft-ietf-lisp-multicast-01.txt) also uses problematic encapsulation for certain control traffic, it will also need to be modified. Background: The current LISP-MS document (draft-ietf-lisp-ms-02) states that an ITR sending a Map-Request to a Map-Resolver sets the destination IP address of the message to the EID it is requesting and the destination UDP port number to 4342 (LISP-CONTROL). The ITR then adds an additional IP+LISP header using the Map-Resolver RLOC as the destination IP address and UDP destination port 4341 (LISP-DATA). The message is sent to a configured Map-Resolver which decapsulates the Map-Request and forwards it on to the ALT. If the destination LISP site is using a Map-Server, the Map-Server receives the Map-Request on the ALT then re-encapsulates the message with an IP+LISP header using the RLOC of the ETR registered for that EID as the destination IP address and UDP destination port 4341 (LISP-DATA). Why the extra encpaulsation from ITR to MR and from MS to ETR? When an ITR is using a Map-Resolver, the ITR is not connected to the ALT and therefore has no way to route control messages destined to an EID. For this reason, the ITR uses the RLOC of a configured Map-Resolver as the destination IP address for Map-Requests; an RLOC, by definition, is routable on the non-LISP part of the Internet. To be forwarded on to the ALT, though, the target EID is also needed as a destination IP address. Adding an extra encpasulation header allows two-stage routing to the destination addresses used in those different contexts. Similarly, since an ETR using a Map-Server is not connected to the ALT, traffic between between Map-Server and ETR must use RLOC-based native forwarding. An ETR thus sends its Map-Register messages using its RLOC as the IP source address and the Map-Server RLOC as the IP destination. Likewise, a Map-Server forwards Map-Requests to an ETR using its RLOC as the IP source address and the ETR RLOC as the IP destination; to do this, it must encapsulate the original Map-Request since the original destination IP address is an EID that is only routable on the ALT. Problem details: As described above, an Encapsulated Map Request currently uses destination UDP port 4341 (LISP-DATA). This creates two potential problems: 1) A packet received by an ETR on port UDP 4341 cannot be immediately determined to be control or data. This means that an ETR must perform significant processing on such a packet before determining whether it needs to either take some control action or forward the packet to a destination host. This could make it difficult to implement ETR functionality on a router that uses specialized forwarding hardware. 2) It is currently possible for an encapsulated user UDP datagram received by an ETR with outer header UDP port 4341 to be misinterpreted as an Encapsulated Map Request. This is because an end system application can use UDP port 4342 as a source port for traffic. Return traffic to an such an application would be received by an ETR with outer header destination port 4341 (LISP-DATA) and inner header destination UDP port 4342; this could be consumed by an ETR and not forwarded correctly. The assignment by the IANA of well-known LISP "service" port numbers will prevent this problem in the future but there may be difficulties with early trials and deployment prior to such an assignment. Solution: 1) Modify the base LISP specification (draft-ietf-lisp-05) to define a new LISP control message type called Encapsulated Control Message. 2) Modify the LISP-MS document (draft-ietf-lisp-ms-03) to specify that Encapsulated Map Requests use the new message type and that they are sent to UDP port 4342 (LISP-CONTROL) instead of 4341 (LISP-DATA). 3) Modify the LISP Multicast document (draft-ietf-lisp-multicast-02.txt) to similarly replace all use of UDP port 4341 with port 4342 for encapsulated unicast PIM Join/Prune messages. These changes greatly simplify processing of LISP packets by an ETR: all traffic received on UDP port 4341 is decapsulated and forwarded to an end system while all traffic received on port 4342 is processed by the ETR itself. Furthermore, these changes eliminate any user vs. control message ambiguity for traffic received by an ETR on port 4341. From rw@firstpr.com.au Mon Sep 21 21:51: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 322833A682E for ; Mon, 21 Sep 2009 21:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K82owchMxtLA for ; Mon, 21 Sep 2009 21:51:09 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 302713A67F3 for ; Mon, 21 Sep 2009 21:51:08 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id EE55F175731; Tue, 22 Sep 2009 14:52:10 +1000 (EST) Message-ID: <4AB857FC.7090603@firstpr.com.au> Date: Tue, 22 Sep 2009 14:52:12 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] Business models - PITRs, PETRs and EID-rental X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 04:51:11 -0000 Short version: I agree with my understanding of what Joel and Noel wrote about discussion of "business models". I am adopting the use of "PITR" (Proxy ITR) instead of its current term "PTR" (Proxy Tunnel Router), as suggested by Joel. This term is needed now there is a second LISP "proxy" network element - the Proxy ETR. I propose a business model for LISP PITRs, just like for Ivip OITRDs. I propose a business model for LISP PETRs, somewhat like for TTRs - but this can only be made to work, and some other problems of PETRs can only be solved, if the ITR establishes a two-way tunnel to the PETR, as the MN does to the TTR. My desire to discuss "business models" is in accordance with what Joel wrote and Noel agreed with, in "LISP Interworking: Proxy Egress Tunnel Routers": > > The distinction I draw is between that and "a thorough set of > > possible business models." We are not trying to explore the space > > of business models ... I think we need to convince ourselves that > > the business model has enough solidity that it may succeed. After > > that, the experiments should help us tell who is interested, and > > what the actual costs are, etc... Our initial evaluation needs to > > look at overall incentives and overall costs, not details of > > business models. > > Exactly. > > Noel I don't think there needs to be any mention of these models in the RFCs, except perhaps to explain what the WG anticipates regarding the relationships between the organisations which run the various items of networking equipment. The separateness of these organisations, the levels of trust and distrust between them and the need to allow for and support competition will affect what sorts of protocols are required to make the whole system work well. Likewise how to protect against unauthorised use of these network elements. The RFCs wouldn't mandate any particular business arrangement for owning and running particular network elements. Its just that the definition of these network elements, their responsibilities and the protocols they use needs to support at least one business model which we think is attractive enough that sufficient people will actually create and run these things. I think we need to allow for revenue generating business models in some settings, such as for PITRs (Proxy Ingress Tunnel Routers) and for PETRs - Proxy ETRs or whatever they are to be called. In Ivip I envisage a revenue-generating business model for OITRDs (Open ITRs in the DFZ ~= LISP PITRs). [1] In the TTR mobility model [2] (which can be applied to LISP, APT or Ivip), one of the roles of the Translating Tunnel Routers is equivalent to the role proposed for LISP Proxy ETRs. I anticipate - indeed propose - revenue generating business models for both OITRDs and TTRs, but they are different models. Here I propose arrangements for LISP PITRs similar to those for OITRDs and arrangements for PETRs similar to those for TTRs. For both PITRs and PETRs, I am anticipating that these network elements would be either owned and run by the organisations which rent out (in LISP terminology) EID space, and/or that they would be owned and run by some other organisations which rent out capacity to the EID-renting organisations. (Actually, these two could be combined - a global network of PITRs or PETRs could be owned and run by an EID-rental organisation who also rents out their capacity to other EID-rental organisations.) For LISP-PITRs I suggest the same as I anticipate for Ivip OITRDs: The EID-rental organisations run (directly or pay for capacity on someone else's system) a global network of PITRs which advertise in the DFZ routes which encompass all the address space the EID-rental company rents to its customers. Without sufficient capacity in these PITRs - and without these ITRs being widely dispersed, so as to handle packets without excessive path-length stretch - their EID space won't be very attractive for anyone to use. (Because packets sent from networks without ITRs will either not be tunneled to the ETR, or will go via excessively long paths.) There would be no access provisions for PITRs - all packets would be accepted and tunneled to the correct ETR. There would need to be a revenue generation system such as sampling the PITR traffic to see which customers the traffic was going to, and charging those customers accordingly. This is from the point of view of the EID-rental organisation and its typically thousands or millions of customers, each of whom rent one or more EID prefixes. (In message 01560, Joel wrote that "we get an increase in routing table size instead of a decrease." But one such BGP advertised prefix covers the space used by potentially hundreds of thousands of end-user networks which are getting portability, multihoming and inbound traffic engineering. Without LISP, or whatever the core-edge separation solution to the routing scaling problem is, each such end-user network would need to have its own advertisement in the global BGP routing table to have these benefits.) So the EID-renters would pay rent on a yearly or monthly basis for their EID address space and they would pay a separate fee for how much capacity was used on the PITRs for traffic being sent to their EID space. (Maybe, for PITR usage lower than some level, there would be no such second fee - that would be up to the EID-rental company.) There's no way of charging the senders of the packets which the PITRs need to encapsulate - and it can't be paid for by some global pool of money, collected from all LISP users or from all the EID-rental customers of a single EID-rental company. This is because a single such customer, with a single IPv4 EID address (or IPv6 /64) could have massive amounts of traffic coming to that address, much or all of it from networks without ITRs. There is no way the cost of that burden on the PITRs should be paid for by other LISP users. The actual usage of PITRs would vary enormously. Some LISP-users might have a very large amount of traffic coming into their sites, but none, or little of it, may arise from networks without ITRs. One fundamental problem with this business model is that it could be used as an extra economic lever by attackers doing what is now termed a Distributed Denial of Service flooding attack: typically thousands of hacked Windows PCs all firing packets at some IP address. In addition to clogging up the final link which receives all that traffic, or without overloading it at all, the attackers would cause financial costs for the renter of the EID, with them having to pay money to their EID-rental company for all this traffic. I can't think of any solution for this nasty problem. However, I can't think of any way of deploying the PITRs or OITRDs which are absolutely needed without some kind of usage-based revenue-generating business model. "EID-rental" is probably a novel term in the LISP field, though Sam recently mentioned "whomever is selling you your EID" (msg01529). After two and a half years of LISP discussion, I still have no clear idea of what the LISP team thinks will be the business models by which LISP users (end-user networks adopting LISP-mapped EID addresses) obtain their EID address space, or a clear idea of what sorts of networks these will be. For PETRs, as with TTRs, I suggest that they only accept packets from authorised sources. That is easy with the TTR, since they only accept packets via a tunnel - typically encrypted, maybe with compression, definitely with packet resend facilities - which are established, with appropriate authentication, from the Mobile Nodes. I have no idea how this can be done with the current PETR proposal - which involves standard LISP encapsulation for the traffic packets. Without such controls, the PETR can be used by anyone to forward packets as if they came from any EID address, and as if they were sent from any ITR. I suggest that the ITRs do for PETRs as I propose MNs do for TTRs: establish a tunnel from the ITR to the PETR, with appropriate authentication. Then there can be no unauthorised usage of PITRs. A major additional benefit of this is that the tunnel protocol can be specifically designed to handle the PMTUD problems and the resending of packets and packet fragments which do not arrive at the PETR. Another benefit of a suitably designed tunnel is that it could handle IPv6 over an IPv4 tunnel and vice-versa. (This is a LISP-specific suggestion, it it not currently part of the TTR model.) A third benefit is that when the ITR establishes the tunnel, this means the ITR can be behind one or more layers of NAT. (There are many things about having an ITR behind NAT which are at odds with the original conception of LISP. LISP could be redesigned so that the LISP-site communicates with the outside world, in some respects at least, via this two-way tunnel to the thing we are currently referring to as a PETR. PETRs are on stable global unicast addresses and so with appropriate protocols, the ITR which is behind NAT might be able to be publicly accessible via a port at the PETR. I still have no idea what why LISP networks would be behind NAT, except to support a level of portability and connectivity flexibility which resembles that provided by the TTR mobility approach. The TTR model does support MNs behind one or more layers of NAT. PETRs would be owned and run by EID-rental companies, or by some other company for them. The EID-rental companies would charge their EID-renting customers (LISP-adopting end-user networks - AKA "LISP-users") for the traffic each such customer sends to the PETRs. To successfully run an EID rental business, a company would need to ensure the customer could use their EID space equally well in any portion of the Earth. (This is an ideal, maybe there are substantial markets for EIDs for customers who would only need to use them in North America, or in China, or in some other restricted area.) To do this, they will definitely need a widely dispersed set of PITRs. These should be close to whatever ISPs their EID-renting customers may have their sites at. This means they need to be pretty much all over the Net. Likewise, they need a set of PETRs - with similar or identical location requirements. So it would make sense to co-locate the PITR and PETR functions, including putting them in the same box. Both the PITR and PETR functions would record traffic, at least on a sampling basis, for billing purposes. The PITR would accept all packets and encapsulate them. The PETR would only accept packets from tunnels from authorised ITRs. - Robin [1] http://www.ops.ietf.org/lists/rrg/2008/msg01158.html http://www.mail-archive.com/rrg@psg.com/msg02448.html [2] http://www.firstpr.com.au/ip/ivip/#mobile (This site will be back online in the next day or so.) From rw@firstpr.com.au Mon Sep 21 21:52: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 89A013A67F3 for ; Mon, 21 Sep 2009 21:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oMBSR2MMa7Z for ; Mon, 21 Sep 2009 21:52:14 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 8676B3A682E for ; Mon, 21 Sep 2009 21:52:14 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id DAACA1756D4; Tue, 22 Sep 2009 14:53:16 +1000 (EST) Message-ID: <4AB8583E.5010002@firstpr.com.au> Date: Tue, 22 Sep 2009 14:53:18 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] LISP-NAT - explanation and support? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 04:52:15 -0000 Short version: Can anyone explain exactly how LISP-NAT is supposed to work, what it is useful for (especially in terms of what it can do which other approaches can't) and what its limitations are? Does anyone argue that LISP-NAT will actually be useful enough to be adopted? If there isn't sufficient support for LISP-NAT I would welcome at least a tentative consensus that it be relegated to some kind of historic status, unless it someone significantly revises it. This would avoid LISP-NAT turning up in future discussions as if it was practical and desirable when (I think) most people believe it is not. I have never been able to understand how LISP NAT would work, and have written critiques of it in the past. Noel wrote: http://www.ietf.org/mail-archive/web/lisp/current/msg01550.html > . . . it is of course always better to avoid NAT if you can; > because NAT mangles packets (which breaks some things, including > some kinds of IPSec, for instance), and won't always work (e.g. > for protocols which won't work through NATs, e.g. if they have > embedded addresses, etc). > > So LISP-NAT is not actually a 100% replacement for a PETR if you're > on a uRPF ISP. In the next message, Joel wrote: > So, unless there is a deployment model in which PITR and PETR > deployments make economic sense, LISP will be dependent upon > LISP-NAT. I for one do not consider NAT a solution worth offering > the world. So that's three people who are critical of LISP-NAT. Darrel wrote (msg1545): > Well, I personally prefer both Proxy ITRs and Proxy ETRs to NAT, > but your mileage may vary! :-) but in the previous message: > If I could not get a PETR service 'close enough', I would use > LISP-NAT for this (URPF avoidance) purpose. As Dave pointed out > in his email, a very interesting (to me) side effect of both > Proxy ITRs and Proxy ETRs are that LISP sites see the benefits > (ingress TE and protocol independent data plane) of LISP day one. > Both I consider optional however, since LISP-NAT is an alternative. Are there any good explanations, with examples, of how LISP-NAT would work and be useful enough to be deployed and adopted? - Robin From dino@cisco.com Mon Sep 21 22:53: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 B0A0B3A67B5 for ; Mon, 21 Sep 2009 22:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 oOdx1MEA0ZHI for ; Mon, 21 Sep 2009 22:53: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 BA92E3A67F3 for ; Mon, 21 Sep 2009 22:53:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABsDuEqrR7MV/2dsb2JhbAC9K4hQAY8uBYQb X-IronPort-AV: E=Sophos;i="4.44,429,1249257600"; d="scan'208";a="393344971" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Sep 2009 05:54:41 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8M5sgof007263; Mon, 21 Sep 2009 22:54:42 -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 n8M5sgFl003704; Tue, 22 Sep 2009 05:54:42 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, 21 Sep 2009 22:54:42 -0700 Received: from [192.168.1.2] ([10.21.126.66]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 22:54:42 -0700 Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AB84057.4000906@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: Mon, 21 Sep 2009 22:54:41 -0700 References: <20090922030534.828906BE631@mercury.lcs.mit.edu> <4AB84057.4000906@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 05:54:42.0128 (UTC) FILETIME=[2DD84500:01CA3B49] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1618; t=1253598882; x=1254462882; 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]=20LISP=20Interworking=3A=20=20Pr oxy=20Egress=20Tunnel=20Routers |Sender:=20; bh=x9IkMWawmfjxjGmJXG+vUC/+lsBd+MuyfsiYYEKMRxI=; b=AhIpCxfCVTvPgA3ECh+xdoDRTVVfHBbQ/I2RNtyhI007flzGhqDkk2saNq vdk8zub24/c51/DgEFZdJxpXwogAGITN4Yh4PfPog1XIAEIf+HQpekyvYGx3 9iaAAgB6MGLVkNm/n5rxoOH40UcHd5V+yj4y8WoeyMeJjMrNzRsXs=; 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] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 05:53:40 -0000 > At least in theory, we get to replace several multi-homed sites, > each with their own PI address with a single PITR advertisement for > their EID block. > > Obviosuly, there is going to be some period of time when folks won't > trust the PITRs, etc... But at least that is a theory which, if I > could believe the PITR deployment story, lead towards reduction. Trust? I don't have to trust all the routers that are getting this email message to you, but I do have to depend on them. On different for PTRs or PETRs. Dino > > Yours, > Joel > > Noel Chiappa wrote: >> > the PITR advertises in BGP a short prefix for a large block of >> EIDs. >> Right, I forgot about that. >> The problem with doing that is that if EIDs in that block are >> scattered, >> topologically, you'll wind up with longer paths. TANSTAAFL... >> Course, that is >> only true for traffic from non-LISP sites.. >> > If it does not do this, then during transition (half of >> forever), we >> > get an increase in routing table size instead of a decrease. >> Routing table size is a whole discussion in itself. >> Even with a certain amount of reduction of splittage, you still >> wind up >> needing to advertize both EIDs _and_ RLOCs, i.e. potentially more >> stuff. I'd >> been hoping to be able to, before long, get to a situation where >> parts of the >> network did not include all of (legacy-addresses, EIDs, RLOCs). >> Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Tue Sep 22 03:10: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 5BD2E3A6837 for ; Tue, 22 Sep 2009 03:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 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 FcVEgb4gnyuZ for ; Tue, 22 Sep 2009 03:10: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 E8E213A6A0C for ; Tue, 22 Sep 2009 03:10:25 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2DB06413B; Tue, 22 Sep 2009 06:11:26 -0400 (EDT) To: Vince Fuller References: <20090922042637.GA14702@vaf-lnx1> From: Sam Hartman Date: Tue, 22 Sep 2009 06:11:26 -0400 In-Reply-To: <20090922042637.GA14702@vaf-lnx1> (Vince Fuller's message of "Mon\, 21 Sep 2009 21\:26\:37 -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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 10:10:28 -0000 Vince, I appreciate that you're working on this issue. however, Joel and I discussed a solution proposal, and I'm sort of frustrated/disappointed that you did not respond to that or explain why your solution should be preferred by the working group. Here's why I prefer my solution better. Under your solution, I'm still required to consume UDP packets not destined to myself. Consider. I'm an ETR. I receive a control packet on port 4342 with the new encapsulated message type. Inside that packet is another IP header, another UDP header, and the actual map request. That inner IP header is not addressed to me. So, I still cannot pass this packet to my local IP and UDP stack. I have to implement my own IP option handling, my own UDP checksum handling, and all the rest of a UDP receiver. I can do a quick and dirty hack of a UDP receiver rapidly: I've done so in a couple of hours for another project. (I'm using another mechanism for the current LISP; also not appropriate for production code, but for a variety of reasons it made more sense.) However doing it right is fairly involved. In conclusion, I don't think this proposal fully addresses my problem. --Sam From hartmans@mit.edu Tue Sep 22 03:41: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 6BC3F28C0CE for ; Tue, 22 Sep 2009 03:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 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 HJmQHPnL7Lvq for ; Tue, 22 Sep 2009 03:41: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 BABCD28C0EE for ; Tue, 22 Sep 2009 03:41:02 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D445E413C; Tue, 22 Sep 2009 06:42:02 -0400 (EDT) To: Sam Hartman References: <20090922042637.GA14702@vaf-lnx1> From: Sam Hartman Date: Tue, 22 Sep 2009 06:42:02 -0400 In-Reply-To: (Sam Hartman's message of "Tue\, 22 Sep 2009 06\:11\: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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 10:41:03 -0000 Let me propose a compromise here. If the encapsulated control message included the following fields: * message type * Source AFI * Source IP * Dest AFI * Dest EID * inner message length * inner message I'd be totally happy with it. You may need the source port in there; I'm not sure. From trac@tools.ietf.org Tue Sep 22 03:41: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 6E13F28B23E for ; Tue, 22 Sep 2009 03:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, 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 8hb+FMnmhNrP for ; Tue, 22 Sep 2009 03:41: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 DD83328C0EF for ; Tue, 22 Sep 2009 03:41:54 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Mq2pm-0002Ar-8H; Tue, 22 Sep 2009 03:42:58 -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: terry.manderson@icann.org X-Trac-Project: lisp Date: Tue, 22 Sep 2009 10:42:58 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/lisp/trac/ticket/5#comment:1 Message-ID: <069.b133edc6740e193b7d40706e317eec83@tools.ietf.org> References: <060.0b90a9804fbd4caaeedd9cdd9ca4d9f2@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <060.0b90a9804fbd4caaeedd9cdd9ca4d9f2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.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: Re: [lisp] #5: protocol version in lisp 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: Tue, 22 Sep 2009 10:41:58 -0000 #5: protocol version in lisp header ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@mit.edu | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ----------------------------------+----------------------------------------- Comment(by terry.manderson@icann.org): Summary of #5 LISP protocol version, as of 21/09/09 # Participants: 9. * 12/08/09 Margaret recommends that a protocol provide for its own versioning with its own field. (not use new port numbers for new versions) * 12/08/09 Joel is inclined towards port number with the reason that a new version is a new protocol. (but notes IANA issues about consumption of port numbers) * 13/08/09 Lars notes an IANA recommendation to include a version field * 13/08/09 Noel floats that are two areas to consider, control traffic and user-data traffic. For control-traffic suggests to use op-codes for version functionality, but be sure to handle unrecognized op-codes. For user-data protocol changes, modify port numbers. * 13/08/09 Margaret thinks that op-codes in versioning are a reasonable choice with "all ones" to escape to additional types, with appropriate response to unrecognized op-codes. In user-data space She sees that unknown expansion directions suggest that a version field in a LISP data header is needed. * 13/08/09 Noel thinks "all ones" is workable, however would prefer to add more bits to the field as a wish list. Noel further highlights that xTRs will work out which versions of LISP they run via control traffic. Suggests expanding Map-Reply to indicate version. * 13/08/09 Margaret posits that a map-reply mechanism addresses her reasons for a LISP data header version. * 17/08/09 Eliot (as a IANA expert reviewer) suggests in general the review would be harsh on a application for a port, without a version #. Further suggests that LISP is unique, and he (if he were the reviewer) would approve without a version #. * 10/09/09 Damien writes that control-traffic is a good idea to negotiate a version in use, however a version field still helpful. (ie for gleaning and simplification of version negotiation.) * 11/09/09 Dino posts an example of mapping and map-cache and states that version numbers are not needed. * 11/09/09 Damien clarifies that this is not map-version, but LISP version * 11/09/09 Dino suggests that you can't trust the encapsulator in data gleaning (wrt version number). Further highlights that you don't want to negotiate due to packet exchanges (and potential packet drops) * 11/09/09 Damien suggests versions (in data gleaning) is a hint, akin to reach-bit. * 17/09/09 Sam (Chair) posts a request for progress. * 18/09/09 Damien agrees that negotiation isn't really needed with an example. * 18/09/09 Dino responds that he believes a protocol version field isn't needed in the data header as it can be implemented with a new UDP port number. * 18/09/09 Damien replies that he doesn't like the multiple port number consumption for multiple versions (citing number exhaustion), suggesting reserving 8 bits for a version field. * 18/09/09 Dino thinks that a version number is no different than a new type value for a control packet (map-request). Further suggests that it may lead to the belief that protocol versions are different per EID (in mapping transactions) * 18/09/09 Joel Suggests that what is needed is a data-plane version number carried in the control plane (using map-request/map-reply). That multiple versions of the control plane protocol acquire round trips and a single version only exist ( else == nightmare). * 18/09/09 Damien suggests you need an extra RTT for the version in the control protocol and then highlights that the WG is focused on experimentation we can use version numbers for different solutions. Also he suggests that the current trend adds more state and requires a complex control protocol. Iterates the dislike of a port number per version. * 18/09/09 Dino agrees with Joel (18/09/09). * 18/09/09 Noel clarifies that no extra RTT is needed as the ITR can send packets in the right version immediately based on the map-reply. He highlights that the bigger issue with versions is compatibility. Either all-nodes support old versions for ever, or non-communication occurs. In experimentation you can use other items (such as bits/ports/etc). He suggests state is required. He suggests that header processing is a bigger consumption cost. * 21/09/09 Sam posts to clarify Damien's concern regarding the need for version information in the data packet header. * 21/09/09 Damien responds that in a communication with a LISP site a map reply for the site specifies what version it can receive, and if data gleaning is not used an map-request is used to learn the version of the LISP site for the return data. However thinks that it doesn't address his problem. * 21/09/09 Noel follows up to Sam to agree that where a site is using gleaned map cache info, it may not have any state, other than the first packet to know what version to respond with. He concurs with the observation regarding square routing the map request and data packet are destined for different locations. Noel moots that answers are painful. * 21/09/09 Darrel moots that TTL (clock sweep) based versioning looks attractive * 21/09/09 Sam asks for clarification on clock sweep. * 21/09/09 Darrel responds that clock sweep is a mechanism to allow a site to set TTL which means the ITR will request a new mapping at TTL expire. * 21/09/09 Sam is no wiser for the clarification in light of communication between two XTRs. * 21/09/09 Darrel suggests that if the data-plane version changes it is reflected in the map-request/map-reply which updates the ITR side. * 21/09/09 Noel is confused how cache freshness helps with the square routing problem. He also asks for better terminology. He puts forward an question with example of how a ITR is to get mapping information. * 21/09/09 Darrel says it goes through a mapping resolution cycle. "this is a feature". The ETR could then use TTL (clock sweep) if the header version changes to trigger freshness in the ITRs * 21/09/09 Noel suggests that extra mapping resolution (RTT) is what people don't like. It also questions what happens to the return packet during RTT. One option (probably unacceptable) is to force traffic through an xTR so square routing doesn't occur. -- Ticket URL: lisp LISP WG document issues From terry.manderson@icann.org Tue Sep 22 04: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 9FF513A6A12 for ; Tue, 22 Sep 2009 04:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 0uwl6RmW5O5k for ; Tue, 22 Sep 2009 04:09:32 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id F0B1F3A6814 for ; Tue, 22 Sep 2009 04:09:31 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 22 Sep 2009 04:10:35 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Tue, 22 Sep 2009 04:10:33 -0700 Thread-Topic: [lisp] #5: LISP protocol version is alive and kicking Thread-Index: Aco7crI3Ilt+uG67Sd2w1ovHqJWZbgAAps6l Message-ID: In-Reply-To: <976CF890-C393-4E28-8FF2-2E909077A9F3@terrym.net> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 11:09:32 -0000 So you have probably just seen that I have summarized this issue to into th= e tracker. Please review and let me know if you think I have misread or mischaracterized anything that was discussed. Speaking now as an individual, it looks like we are now taking a circular motion with #5, my personal observations of the discussion stands as: a) only one control plane version should exist. b) data plane versions are handled by the control plane. (map-request/map-reply structures) c) No extra RTT is desired. d) Experimentation (versions) can occur outside of RFC compliance. e) Some state is required, but no more than necessary (as required in mapping.) f) keeping the data header simpler is a bigger win. g) TTL (clock sweep) can be used to maintain ITR mapping freshness. h) having the versions in the map-reply encounters square routing issues, and requires the ITR to do an RTT to get map-info. see "c". Thus far I don't see any convergence on what the version looks like in the map-request/map-reply (type value or otherwise) And it appears that an answer to deal with the 'unwanted' RTT in "h" is needed in light of no data gleaning. Is this a fair approximation of the current position? Cheers Terry From jnc@mercury.lcs.mit.edu Tue Sep 22 06:38: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 2ED223A6A5A for ; Tue, 22 Sep 2009 06:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 RMq+05IBnw-M for ; Tue, 22 Sep 2009 06:38:27 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 699A73A67A6 for ; Tue, 22 Sep 2009 06:38:27 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1D8FE6BE55D; Tue, 22 Sep 2009 09:39:30 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090922133930.1D8FE6BE55D@mercury.lcs.mit.edu> Date: Tue, 22 Sep 2009 09:39:30 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 13:38:28 -0000 > From: Terry Manderson > g) TTL (clock sweep) can be used to maintain ITR mapping freshness. I'm not sure about this one yet: we _might_ want an explicit mechanism (piggybacked mapping versions or checksums) to check for stale mappings; probably there will be some experimentation to see i) if stale mappings are a problem, and ii) how well a piggybacked mechanism works, before we can say for sure. Also, there is a case we can handle, but haven't yet talked about in the spec, which is a packet for EID X arriving at an ETR which is no longer an ETR for the destination EID. That ETR might want to SMR the ITR (although we need to make sure it's not a DOS vector), although I don't know if it will be common enough to be worth putting in a mechanism to fix those cases. Ditto for ICMP Port Unreachable (if the packet winds up at something that's not a LISP ETR) - and that one's definitely a DoS vector. > Thus far I don't see any convergence on what the version looks like > in the map-request/map-reply (type value or otherwise) The type value is 4 bits, that ought to be more than enough? > Is this a fair approximation of the current position? Other than the ones I commented on, I think so. Noel From mrw@sandstorm.net Tue Sep 22 06:44: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 74A983A6964 for ; Tue, 22 Sep 2009 06:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=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 MPgrBfwVfewS for ; Tue, 22 Sep 2009 06:44:21 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 7B35328C114 for ; Tue, 22 Sep 2009 06:44:21 -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 n8MDjFgo047594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2009 09:45:15 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <5BC251B0-0860-4EBD-BDC1-A7858F22BF9F@sandstorm.net> From: Margaret Wasserman To: Vince Fuller In-Reply-To: <20090922042637.GA14702@vaf-lnx1> 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, 22 Sep 2009 09:45:15 -0400 References: <20090922042637.GA14702@vaf-lnx1> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 13:44:22 -0000 Hi Vince, On Sep 22, 2009, at 12:26 AM, Vince Fuller wrote: > > Solution: > > 1) Modify the base LISP specification (draft-ietf-lisp-05) to > define a new > LISP control message type called Encapsulated Control Message. > 2) Modify the LISP-MS document (draft-ietf-lisp-ms-03) to specify > that > Encapsulated Map Requests use the new message type and that they > are > sent to UDP port 4342 (LISP-CONTROL) instead of 4341 (LISP-DATA). Are you proposing that we send both unencapsulated LISP control messages (such as Map-Register packets) AND encapsulated LISP control packets (such as Map-Request and Map-Reply) to the same port (4342)? If so, how do you propose to demultiplex the different packet types? If I am understanding what you are proposing correctly, it is quite problematic. In LISP -04, the packets that arrive on port 4342 are demux'ed using the first 4 bits as a message type, as defined in section 4.1.1. If encapsulated packets arrive on the same port, what would their headers look like? Do you expect to see IP/UDP (Dest Port = 4342)/ LISP Data/IP/UDP(Dest Port = 4342)/LISP Control? If so, you have a serious problem, because there is no easy way to determine whether the message is or isn't encapsulated when it arrives at port 4342, either the first or second time through the receive portion of the stack. There is nothing stopping the first four bits of the LISP Data header (flags & reserved) from being equal to the values assigned to unencapsulated LISP control messages. > 3) Modify the Multicast document (draft-ietf-lisp-multicast-02.txt) > to similarly replace all use of UDP port 4341 with port 4342 for > encapsulated unicast PIM Join/Prune messages. LISP > > These changes greatly simplify processing of LISP packets by an > ETR: all > traffic received on UDP port 4341 is decapsulated and forwarded to > an end > system while all traffic received on port 4342 is processed by the > ETR > itself. Furthermore, these changes eliminate any user vs. control > message > ambiguity for traffic received by an ETR on port 4341. You haven't given any justification for why the End-Node-to-ITR or ETR- to-End-Node communication can or should be encapsulated. Sam and Joel proposed that it should not be encapsulated at all, and I prefer that solution. Is there a problem with that solution that caused you to consider this alternative? If so, could you explain what it is? Thanks, Margaret From jnc@mercury.lcs.mit.edu Tue Sep 22 06:58: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 0E49C28C14D for ; Tue, 22 Sep 2009 06:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 wNo+Zba+OXPp for ; Tue, 22 Sep 2009 06:58: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 51D2128C143 for ; Tue, 22 Sep 2009 06:58:34 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9DFA16BE574; Tue, 22 Sep 2009 09:59:37 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090922135937.9DFA16BE574@mercury.lcs.mit.edu> Date: Tue, 22 Sep 2009 09:59:37 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 13:58:35 -0000 > From: Margaret Wasserman > Are you proposing that we send both unencapsulated LISP control > messages .. AND encapsulated LISP control packets .. to the same > port (4342)? Yes. > If so, how do you propose to demultiplex the different packet types? A new value in the 'type' field. > justification for why the End-Node-to-ITR or ETR- to-End-Node > communication can or should be encapsulated. ... proposed that it > should not be encapsulated at all ... Is there a problem with that > solution that caused you to consider this alternative? If so, could > you explain what it is? I'll have to let someone else answer that - my brain goes foggy on some of the details. Noel From mrw@sandstorm.net Tue Sep 22 07:14: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 3A1673A67E7 for ; Tue, 22 Sep 2009 07:14:50 -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 91xckCAiqS2Z for ; Tue, 22 Sep 2009 07:14:49 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 447D43A68DF for ; Tue, 22 Sep 2009 07:14:49 -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 n8MEFcu3049486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2009 10:15:38 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090922135937.9DFA16BE574@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, 22 Sep 2009 10:15:37 -0400 References: <20090922135937.9DFA16BE574@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 14:14:50 -0000 Hi Noel, On Sep 22, 2009, at 9:59 AM, Noel Chiappa wrote: > >> If so, how do you propose to demultiplex the different packet types? > > A new value in the 'type' field. The problem is that the "type" field isn't in the same place in both packets... My understanding is that unencapsulated control packets will contain: IP(v4 or v6) Header UDP Headers (Dest Port = 4243) LISP Control Message (with type in first 4 bits) While encapsulated control packets will contain: Outer IP(v4 or v6) Header Outer UDP Header (Dest Port = 4243) LISP Data Header (with flags in first 4 bits) IP(v4 or v6 Header) UDP Header (Dest Port = 4243) LISP Control Message (with type in first 4 bits) (Am I misunderstanding something about how these packets will be encapsulated?) If I am right about the encapsulation above, when I receive a UDP packet with destination port 4243, what do I do? If I look at the first four bits after the first (or only) UDP header to determine the message type, I will be reading either a LISP Control Message type, OR the first four LISP Data flag bits. Since there is nothing stopping the flag bits from matching a valid LISP Control Message type, I can't use those bits to determine whether the packet is encapsulated or not. So, how do I figure out whether to process this packet as an unencapsulated LISP control packet or an encapsulated one? Margaret From jnc@mercury.lcs.mit.edu Tue Sep 22 07:27: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 347903A697F for ; Tue, 22 Sep 2009 07:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 XhD6QcLGuAz1 for ; Tue, 22 Sep 2009 07:27:25 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 6A7A53A67EB for ; Tue, 22 Sep 2009 07:27:25 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7F82B6BE55D; Tue, 22 Sep 2009 10:28:28 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090922142828.7F82B6BE55D@mercury.lcs.mit.edu> Date: Tue, 22 Sep 2009 10:28:28 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 14:27:26 -0000 > From: Margaret Wasserman >>> If so, how do you propose to demultiplex the different packet types? > A new value in the 'type' field. BTW, this answer assume your question was actually 'how do I tell an encapsulated control packet from a regular control packet like a plain Map-Request'. Apologies if I misunderstood your question. > My understanding is that unencapsulated control packets will contain: > IP(v4 or v6) Header > UDP Headers (Dest Port = 4243) > LISP Control Message (with type in first 4 bits) I think that's right, except I think it's 4342, not 4243. > While encapsulated control packets will contain: > Outer IP(v4 or v6) Header > Outer UDP Header (Dest Port = 4243) > LISP Data Header (with flags in first 4 bits) > IP(v4 or v6 Header) > UDP Header (Dest Port = 4243) > LISP Control Message (with type in first 4 bits) Uhh, no, maybe I'm confused (I often am :-), but I _thought_ the idea was this: Outer IP(v4 or v6) Header Outer UDP Header (Dest Port = 4342) Outer LISP Control Header (with type in first 4 bits, value = 'Encapsulated') Inner IP(v4 or v6) Header Inner UDP Header (Dest Port = 4342) Inner LISP Control Header (with type in first 4 bits) I.e. it would use a Control Header in the outer (encapsulating) LISP header, not a Data Header. That's the reason it's sent to 4342, the Control port. If I am confused (again :-) someone will, I hope, de-confuse me... :-) NOel From mrw@sandstorm.net Tue Sep 22 07: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 BBD1B3A6A59 for ; Tue, 22 Sep 2009 07:40:14 -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 6qROwxumyQYj for ; Tue, 22 Sep 2009 07:40:14 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id BD5AF3A6A00 for ; Tue, 22 Sep 2009 07:40:11 -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 n8MEf5GD051080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2009 10:41:05 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <3D61335D-6D38-4D0C-BAD7-1185228E15DE@sandstorm.net> 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 v936) Date: Tue, 22 Sep 2009 10:41:04 -0400 References: <20090922135937.9DFA16BE574@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 14:40:15 -0000 Hi Again, On further reflection, I am thinking that perhaps I misundertood the encapsulation... On Sep 22, 2009, at 10:15 AM, Margaret Wasserman wrote: > While encapsulated control packets will contain: > > Outer IP(v4 or v6) Header > Outer UDP Header (Dest Port = 4243) > LISP Data Header (with flags in first 4 bits) Perhaps this is actually a LISP Control Message with a type of "Encapsulated Control Message"? > IP(v4 or v6 Header) > UDP Header (Dest Port = 4243) > LISP Control Message (with type in first 4 bits) If so, I understand how this mechanism would work, but I still don't understand why we would prefer this mechanism to Sam and Joel's simpler proposal. Personally, I would prefer that we view the outer IP/UDP headers on LISP control messages as a transport (how the xTR gets its packets to/ from the Map Resolver/Server), and include everything that is needed by the mapping system in the control message itself. I think that is cleaner and much less likely to run into problems with intermediate systems, etc. Margaret From jnc@mercury.lcs.mit.edu Tue Sep 22 07:47: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 617DA28C0FC for ; Tue, 22 Sep 2009 07:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 QVWae0r1wweX for ; Tue, 22 Sep 2009 07:47: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 5A9713A6A81 for ; Tue, 22 Sep 2009 07:47:40 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9E6066BE55D; Tue, 22 Sep 2009 10:48:43 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090922144843.9E6066BE55D@mercury.lcs.mit.edu> Date: Tue, 22 Sep 2009 10:48:43 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 14:47:46 -0000 > From: Margaret Wasserman > include everything that is needed by the mapping system in the > control message itself. This is just a guess (I tend to tune out these sorts of detailed low-level issues, since they cause my eyes to glaze over), but one possible reason for going the other way is that if you do that, you have one more packet type to write code for. If you just encapsulate the whole thing, you only need a couple of lines of code - strip the wrapper, and process the packet as normal. >From Sam's comments, it sounds like maybe the issue is that reprocessing that inner packet is easy on some machine (just feed it back into ip_handle_packet(), or whatever it's called), whereas on others that doesn't work, so on those machines, instead of being less work, it's more. At least, that's the impression I'm getting. Noel From mrw@sandstorm.net Tue Sep 22 07:58: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 008FD28C125 for ; Tue, 22 Sep 2009 07:58:59 -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 agHk7tgyWytx for ; Tue, 22 Sep 2009 07:58:58 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 400F828C0D7 for ; Tue, 22 Sep 2009 07:58: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 n8MExgiQ052226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2009 10:59:42 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-Reply-To: <20090922144843.9E6066BE55D@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, 22 Sep 2009 10:59:42 -0400 References: <20090922144843.9E6066BE55D@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 14:58:59 -0000 Hi Noel, On Sep 22, 2009, at 10:48 AM, Noel Chiappa wrote: > > This is just a guess (I tend to tune out these sorts of detailed low- > level > issues, since they cause my eyes to glaze over), but one possible > reason > for going the other way is that if you do that, you have one more > packet > type to write code for. If you just encapsulate the whole thing, you > only > need a couple of lines of code - strip the wrapper, and process the > packet > as normal. > > From Sam's comments, it sounds like maybe the issue is that > reprocessing > that inner packet is easy on some machine (just feed it back into > ip_handle_packet(), or whatever it's called), whereas on others that > doesn't work, so on those machines, instead of being less work, it's > more. > At least, that's the impression I'm getting. Logically, this is pretty simple on all of the systems I'm aware of... However, it always takes more processing to process an encapsulated packet, as you pass the packet through the IP receive logic twice, once for the outer header, and again for the inner header. Also, there can be a bunch of security complexity, because tunneling allows you to get packets where they shouldn't be. So, you either need to do a bunch of checks to make sure that the addresses in the outer header match the ones in the inner header, or you need to be very careful that the packets are properly filtered/firewalled _after_ they are decapsulated. In general, encapsulating (AKA tunneling) packets can be very useful when you are trying to achieve some sort of overlay topology (like LISP), but they seem unnecessary for communication between xTRs and Map Servers/Resolvers, because those systems all have RLOCs and can use them to talk to each other without the need for tunneling, etc. There has been some discussion of whether encapsulation is needed to support mixed IPv4/IPv6 address cases, but I don't understand why that would be. Take DNS for example -- a host communicates with a DNS server using whatever DNS server address it has configured. The requesting host chooses its own source address and the version of IP to match the DNS server address. That doesn't stop the requesting host from being able to receive both A (IPv4) records and AAAA (IPv6) records in response to a query, or even from doing a reverse lookup on both IPv4 and IPv6 addresses. The transport is just a transport. Margaret From jnc@mercury.lcs.mit.edu Tue Sep 22 08:26: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 F243C28C139 for ; Tue, 22 Sep 2009 08:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 q51VvlHqVofK for ; Tue, 22 Sep 2009 08:26:11 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 1C0F128C131 for ; Tue, 22 Sep 2009 08:26:11 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4DB176BE553; Tue, 22 Sep 2009 11:27:10 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090922152710.4DB176BE553@mercury.lcs.mit.edu> Date: Tue, 22 Sep 2009 11:27:10 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 15:26:12 -0000 > From: Sam Hartman Went back to re-read this to make sure I'd understood your issue properly, and I see I was confused (this is getting somewhat repetitious... :-) > Under your solution, I'm still required to consume UDP packets not > destined to myself. ... I'm an ETR. I receive a control packet ... > Inside that packet is another IP header, another UDP header, and the > actual map request. That inner IP header is not addressed to me. Let me make sure I understand this. This ETR actually _is_ the machine that Map-Request should properly be forwarded to, _but_ because the orignating ITR didn't know the ETR's RLOC (all it knew was what EID it wanted looked up), that header can't contain the ETR's RLOC. (It happens to contain the destination EID, which is a hack to help ALT, more below.) > So, I still cannot pass this packet to my local IP and UDP stack. There is a hack around this, (just bash the inner destination IP address to be your own, adjust the IP and UDP checksums (it will be the same value to add to both), and then pass the packet to your local stack), but I'm not sure that's the right answer anyway.... > In conclusion, I don't think this proposal fully addresses my > problem. But is doing a whole new Map-Request format the right answer either, _particlarly_ when that oddball Map-Request is only needed to work with a particular mapping system (ALT), which might well be replaced down the road? (At this point I went back and re-read Vince's original message.) To me, part of the charm of the whole Map-Resolver/etc stuff was that it insulated the xTRs from the details of the mapping system, meaning we could replace it more easily. But these 'tendrils' are starting to creep in, where we are tuning the underlying basic map-resolution mechanism to the details of the ALT. Noel From jmh@joelhalpern.com Tue Sep 22 08:43: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 EEFE03A6A5F for ; Tue, 22 Sep 2009 08:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=-0.245, 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 x0UIW8Mgcw6G for ; Tue, 22 Sep 2009 08:43:24 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 2FEA93A6A10 for ; Tue, 22 Sep 2009 08:43:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 6BA5332317A7; Tue, 22 Sep 2009 08:44:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id C9BFB32317A1; Tue, 22 Sep 2009 08:44:27 -0700 (PDT) Message-ID: <4AB8F0D8.10202@joelhalpern.com> Date: Tue, 22 Sep 2009 11:44:24 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Noel Chiappa References: <20090922152710.4DB176BE553@mercury.lcs.mit.edu> In-Reply-To: <20090922152710.4DB176BE553@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 15:43:25 -0000 But this does not call for a whole new Map-Request format. The existing Map-Request format has all the information that is needed for processing, passing on, and responding to, the request. The inner UDP header repeats information from the Map-Request itself. I suspect that at this point we need to wait and let the US west coast have a chance to digest this exchange, so that they can speak for themselves. Yours, Joel Noel Chiappa wrote: > > From: Sam Hartman > > Went back to re-read this to make sure I'd understood your issue properly, > and I see I was confused (this is getting somewhat repetitious... :-) > > > Under your solution, I'm still required to consume UDP packets not > > destined to myself. ... I'm an ETR. I receive a control packet ... > > Inside that packet is another IP header, another UDP header, and the > > actual map request. That inner IP header is not addressed to me. > > Let me make sure I understand this. > > This ETR actually _is_ the machine that Map-Request should properly be > forwarded to, _but_ because the orignating ITR didn't know the ETR's RLOC > (all it knew was what EID it wanted looked up), that header can't contain > the ETR's RLOC. (It happens to contain the destination EID, which is a > hack to help ALT, more below.) > > > So, I still cannot pass this packet to my local IP and UDP stack. > > There is a hack around this, (just bash the inner destination IP address > to be your own, adjust the IP and UDP checksums (it will be the same value > to add to both), and then pass the packet to your local stack), but I'm > not sure that's the right answer anyway.... > > > > In conclusion, I don't think this proposal fully addresses my > > problem. > > But is doing a whole new Map-Request format the right answer either, > _particlarly_ when that oddball Map-Request is only needed to work with a > particular mapping system (ALT), which might well be replaced down the > road? > > (At this point I went back and re-read Vince's original message.) > > To me, part of the charm of the whole Map-Resolver/etc stuff was that it > insulated the xTRs from the details of the mapping system, meaning we > could replace it more easily. But these 'tendrils' are starting to creep > in, where we are tuning the underlying basic map-resolution mechanism to > the details of the ALT. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From mrw@sandstorm.net Tue Sep 22 08:46: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 85F673A6A3B for ; Tue, 22 Sep 2009 08:46:11 -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 WIj8u2YYR5mI for ; Tue, 22 Sep 2009 08:46:10 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 836E13A697F for ; Tue, 22 Sep 2009 08:46:10 -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 n8MFl30i055212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2009 11:47:03 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-Reply-To: <20090922152710.4DB176BE553@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, 22 Sep 2009 11:47:03 -0400 References: <20090922152710.4DB176BE553@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 15:46:11 -0000 On Sep 22, 2009, at 11:27 AM, Noel Chiappa wrote: > This ETR actually _is_ the machine that Map-Request should properly be > forwarded to, _but_ because the orignating ITR didn't know the ETR's > RLOC > (all it knew was what EID it wanted looked up), that header can't > contain > the ETR's RLOC. (It happens to contain the destination EID, which is a > hack to help ALT, more below.) True, except you haven't explained why we need this header at all... What if the ITR sent a simple question to the Map Resolver of the form "What RLOC(s) should I use to reach this EID (or EID prefix)?". This could be sent from one of the ITRs RLOCs to the Map Resolver, and we don't need to use any non-routable EIDs in the IP header(s) at all. I _understand_ that the ALT mapping system relies on using the EID as a destination address _inside the ALT_ in order to reach the right mapping server to resolve the request. But, that ALT-specific detail should remain hidden inside the ALT, IMO. >> So, I still cannot pass this packet to my local IP and UDP stack. > > There is a hack around this, (just bash the inner destination IP > address > to be your own, adjust the IP and UDP checksums (it will be the same > value > to add to both), and then pass the packet to your local stack), but > I'm > not sure that's the right answer anyway.... The fact that that just bashing the address could work points out why this type of encapsulation isn't needed at all. The EID for the request is already in the Map Request itself, so there isn't any need to include it in an encapsulated header. >> In conclusion, I don't think this proposal fully addresses my >> problem. > > But is doing a whole new Map-Request format the right answer either, > _particlarly_ when that oddball Map-Request is only needed to work > with a > particular mapping system (ALT), which might well be replaced down the > road? Who said we'd need a whole new Map-Request format? We're asking for a simpler encapsulation, not a whole new format. > > (At this point I went back and re-read Vince's original message.) > > To me, part of the charm of the whole Map-Resolver/etc stuff was > that it > insulated the xTRs from the details of the mapping system, meaning we > could replace it more easily. But these 'tendrils' are starting to > creep > in, where we are tuning the underlying basic map-resolution > mechanism to > the details of the ALT. What Vince has proposed does the exact _opposite_ of isolating the xTRs from the mapping system, as they are required to build mapping- system-specific requests (using EIDs as destination addresses) and then encapsulate them to get them to the mapping system. A system where we ask simple questions like "What RLOC(s) should I (as an ITR) use to reach this EID (or EID prefix)?" and get simple answers like "Use this/these RLOC(s) to reach this EID Prefix" over a simple (unencapsulated) transport would actually _hide_ the details of the mapping system from the xTRs. Margaret From dino@cisco.com Tue Sep 22 09:08: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 23F8B3A6AA0 for ; Tue, 22 Sep 2009 09:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 JqXBg98Yi9ey for ; Tue, 22 Sep 2009 09:08:34 -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 3FC633A6882 for ; Tue, 22 Sep 2009 09:08:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAeTuEqrR7PD/2dsb2JhbADAKohPAZAJBYQbimQ X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="245232566" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 22 Sep 2009 16:09:38 +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 n8MG9cPR007022; Tue, 22 Sep 2009 09:09:38 -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 n8MG9cMt011933; Tue, 22 Sep 2009 16:09:38 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, 22 Sep 2009 09:09:38 -0700 Received: from [192.168.1.2] ([10.21.92.96]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:09:37 -0700 Message-Id: <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@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 v936) Date: Tue, 22 Sep 2009 09:09:37 -0700 References: <20090922042637.GA14702@vaf-lnx1> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 16:09:37.0765 (UTC) FILETIME=[155BB150:01CA3B9F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1853; t=1253635778; x=1254499778; 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=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=s0uUo6xJEi2sx1U6T4DaW2DBH+s0dTSfptvP83h/4Vs=; b=i8aD7DNBfp8g/YqC4xn8O24F70thQ2kX0aqTHyRqUIYm0WLfcmJc3xZ7fv LzfHCpm4ioCq+Ez0F+8PIV5yv3VmYklutc9RoOh8Xq9UqOiODTSJObk7g/1W +YkNz+veBS; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 16:08:35 -0000 > however, Joel and I discussed a solution proposal, and I'm sort of > frustrated/disappointed that you did not respond to that or explain > why your solution should be preferred by the working group. I did respond both publicly and privately with Joel. Dino > Here's why I prefer my solution better. Under your solution, I'm > still required to consume UDP packets not destined to myself. > > Consider. I'm an ETR. I receive a control packet on port 4342 with > the new encapsulated message type. > > Inside that packet is another IP header, another UDP header, and the > actual map request. That inner IP header is not addressed to me. So, > I still cannot pass this packet to my local IP and UDP stack. I have > to implement my own IP option handling, my own UDP checksum handling, > and all the rest of a UDP receiver. Use APIs in the LISP process. And we need to make this simple for the network architecture and users. > I can do a quick and dirty hack of a UDP receiver rapidly: I've done > so in a couple of hours for another project. (I'm using another > mechanism for the current LISP; also not appropriate for production > code, but for a variety of reasons it made more sense.) However doing > it right is fairly involved. > > In conclusion, I don't think this proposal fully addresses my problem. The proposal makes a small change to what we have now. So we can process the various options of mixed address families and keeping the ALT and other mechanisms pure. What Joel proposes is a huge change to the mapping system. And if you encapsulate at the ITR versus the map-resolver is 6 and one-half dozen or the other. Dino > > > --Sam > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Tue Sep 22 09:09: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 3D6FF3A690D for ; Tue, 22 Sep 2009 09:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 6r7IVdVx4Rsb for ; Tue, 22 Sep 2009 09:09:19 -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 2AA173A6902 for ; Tue, 22 Sep 2009 09:09:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHuTuEqrR7PD/2dsb2JhbADAN4hPAZAJBYQbimQ X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="393724718" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 22 Sep 2009 16:10:23 +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 n8MGANm1008718; Tue, 22 Sep 2009 09:10:23 -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 n8MGAQhe003645; Tue, 22 Sep 2009 16:10:26 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, 22 Sep 2009 09:10:22 -0700 Received: from [192.168.1.2] ([10.21.92.96]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:10:22 -0700 Message-Id: <1FA4E6A1-946B-4451-B87A-1CE28A3DCC32@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 v936) Date: Tue, 22 Sep 2009 09:10:22 -0700 References: <20090922042637.GA14702@vaf-lnx1> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 16:10:22.0610 (UTC) FILETIME=[30167F20:01CA3B9F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=679; t=1253635823; x=1254499823; 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=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=nFyp6lNcc33oAuaVRgCz/pgrJjw4QdJ1C/94EGAbUM4=; b=a8EF7ZwWwEOW50jr99qcqQwLBDrZgigrRnQbX+3++yFK45GbsbyMfJ1xL0 doqLS/wR8Hx6UOFKW7FqqjkuGr8UUMyc/bA2VBwul3oHm61o667ODlUySKpS SbCs+cfsLf; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 16:09:20 -0000 That is already in the inner map-request. Why duplicate it? Then you have a problem with what fields do you pay attention to if they are different. Dino On Sep 22, 2009, at 3:42 AM, Sam Hartman wrote: > Let me propose a compromise here. > > If the encapsulated control message included the following fields: > * message type > * Source AFI > * Source IP > * Dest AFI > * Dest EID > * inner message length > * inner message > > > I'd be totally happy with it. You may need the source port in there; > I'm not sure. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Tue Sep 22 09:12: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 276753A6911 for ; Tue, 22 Sep 2009 09:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 1GaQEEmxUxVI for ; Tue, 22 Sep 2009 09:12:33 -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 155173A68BF for ; Tue, 22 Sep 2009 09:12:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAeUuEqrR7PE/2dsb2JhbADAOYhPAZAJBYQb X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="191341040" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 22 Sep 2009 16:13:36 +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 n8MGDarv030482; Tue, 22 Sep 2009 09:13:36 -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 n8MGDZEA016942; Tue, 22 Sep 2009 16:13:36 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, 22 Sep 2009 09:13:35 -0700 Received: from [192.168.1.2] ([10.21.92.96]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:13:35 -0700 Message-Id: <45AC71FE-B09A-4855-85C9-99ABA873B4CF@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AB8F0D8.10202@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, 22 Sep 2009 09:13:34 -0700 References: <20090922152710.4DB176BE553@mercury.lcs.mit.edu> <4AB8F0D8.10202@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 16:13:35.0308 (UTC) FILETIME=[A2F1E0C0:01CA3B9F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2935; t=1253636016; x=1254500016; 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=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=IG+Iz8+PrFgjSHp2U2dGoMWC+w5BPcRa1Pq656ClsY8=; b=ERDlTIeO2UViopJl2UkJA+PKSD5HiFR9UhXP8dG8lBDib7zlmDwGmvOdGl ExQGItmt82oeuORPA91cwDSY3LUnONgDr4IVGK3xH2SyAb1xOH6YtJA5gdnM J1aVRHIuC8; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 16:12:34 -0000 > But this does not call for a whole new Map-Request format. The > existing Map-Request format has all the information that is needed > for processing, passing on, and responding to, the request. The > inner UDP header repeats information from the Map-Request itself. The only item repeated is the UDP header. So what? > I suspect that at this point we need to wait and let the US west > coast have a chance to digest this exchange, so that they can speak > for themselves. Indigestion. ;-) Dino > > Yours, > Joel > > Noel Chiappa wrote: >> > From: Sam Hartman >> Went back to re-read this to make sure I'd understood your issue >> properly, >> and I see I was confused (this is getting somewhat repetitious... :-) >> > Under your solution, I'm still required to consume UDP packets >> not >> > destined to myself. ... I'm an ETR. I receive a control >> packet ... >> > Inside that packet is another IP header, another UDP header, >> and the >> > actual map request. That inner IP header is not addressed to me. >> Let me make sure I understand this. >> This ETR actually _is_ the machine that Map-Request should properly >> be >> forwarded to, _but_ because the orignating ITR didn't know the >> ETR's RLOC >> (all it knew was what EID it wanted looked up), that header can't >> contain >> the ETR's RLOC. (It happens to contain the destination EID, which >> is a >> hack to help ALT, more below.) >> > So, I still cannot pass this packet to my local IP and UDP >> stack. >> There is a hack around this, (just bash the inner destination IP >> address >> to be your own, adjust the IP and UDP checksums (it will be the >> same value >> to add to both), and then pass the packet to your local stack), but >> I'm >> not sure that's the right answer anyway.... >> > In conclusion, I don't think this proposal fully addresses my >> > problem. >> But is doing a whole new Map-Request format the right answer either, >> _particlarly_ when that oddball Map-Request is only needed to work >> with a >> particular mapping system (ALT), which might well be replaced down >> the >> road? >> (At this point I went back and re-read Vince's original message.) >> To me, part of the charm of the whole Map-Resolver/etc stuff was >> that it >> insulated the xTRs from the details of the mapping system, meaning we >> could replace it more easily. But these 'tendrils' are starting to >> creep >> in, where we are tuning the underlying basic map-resolution >> mechanism to >> the details of the ALT. >> Noel >> _______________________________________________ >> 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 Tue Sep 22 09:32: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 838D43A6AA1 for ; Tue, 22 Sep 2009 09:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 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 emDrXbC0FA0O for ; Tue, 22 Sep 2009 09:32:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id C95643A67A6 for ; Tue, 22 Sep 2009 09:32:40 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F2613413C; Tue, 22 Sep 2009 12:33:40 -0400 (EDT) To: Dino Farinacci References: <20090922042637.GA14702@vaf-lnx1> <1FA4E6A1-946B-4451-B87A-1CE28A3DCC32@cisco.com> From: Sam Hartman Date: Tue, 22 Sep 2009 12:33:40 -0400 In-Reply-To: <1FA4E6A1-946B-4451-B87A-1CE28A3DCC32@cisco.com> (Dino Farinacci's message of "Tue\, 22 Sep 2009 09\:10\:22 -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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 16:32:41 -0000 >>>>> "Dino" == Dino Farinacci writes: Dino> That is already in the inner map-request. Why duplicate it? Dino> Then you have a problem with what fields do you pay Dino> attention to if they are different. O, I'm happier with Margaret's solution. Anything that gets rid of the inner IP and UDP header works for me. I explained in my longer message why the inner IP and UDP header are problematic. Margaret has explained why they are unneeded. Unneeded, problematic things should go away. I was simply proposing a compromise that might be easier to implement than just sending the inner map request as Margaret, Joel and I originally suggested. I'm definitely happy with that original approach as well. From mrw@sandstorm.net Tue Sep 22 09:36: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 46CAE3A6AA1 for ; Tue, 22 Sep 2009 09:36:21 -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 7sUqqP1qmW2P for ; Tue, 22 Sep 2009 09:36:20 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 766D23A68E8 for ; Tue, 22 Sep 2009 09:36:20 -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 n8MGbKvD058125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2009 12:37:20 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@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, 22 Sep 2009 12:37:20 -0400 References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 16:36:21 -0000 Hi Dino, On Sep 22, 2009, at 12:09 PM, Dino Farinacci wrote: > > And we need to make this simple for the network architecture and > users. Could you explain how sending encapsulated Map-Requests is simpler for the network architecture and users? >> I can do a quick and dirty hack of a UDP receiver rapidly: I've done >> so in a couple of hours for another project. (I'm using another >> mechanism for the current LISP; also not appropriate for production >> code, but for a variety of reasons it made more sense.) However doing >> it right is fairly involved. >> >> In conclusion, I don't think this proposal fully addresses my >> problem. > > The proposal makes a small change to what we have now. So we can > process the various options of mixed address families and keeping > the ALT and other mechanisms pure. This is not the first time that you've indicated that you believe there may be problem with "mixed address families" if we do not use encapsulation for the Map-Request, but you have not explained what the problem would be. Joel and I have both indicated that we don't see why using an unencapsulated Map-Request would cause problems for "mixed AFI families". If you still think this would cause a problem, could you explain it? > What Joel proposes is a huge change to the mapping system. And if > you encapsulate at the ITR versus the map-resolver is 6 and one-half > dozen or the other. I don't see how Joel's proposal is a huge change... Could you explain why you see it that way? If it is roughly equivalent to do the encapsulation in the Map Resolver instead of in the ITR, why do you object so strongly to doing it in the Map Resolver? Margaret From dino@cisco.com Tue Sep 22 09:36: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 2B2383A68E8 for ; Tue, 22 Sep 2009 09:36:50 -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 fEeU85F9rOem for ; Tue, 22 Sep 2009 09:36:48 -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 D28673A67A6 for ; Tue, 22 Sep 2009 09:36:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIOauEqrR7O6/2dsb2JhbADAQ4hPAZALBYQbimQ X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="393746150" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 22 Sep 2009 16:37:53 +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 n8MGbq7g007111; Tue, 22 Sep 2009 09:37:52 -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 n8MGbn7X001692; Tue, 22 Sep 2009 16:37:53 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, 22 Sep 2009 09:37:49 -0700 Received: from [192.168.1.2] ([10.21.92.96]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:37:49 -0700 Message-Id: <034F0113-E208-4F4B-B9E9-FC0FEB1EE88F@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 v936) Date: Tue, 22 Sep 2009 09:37:48 -0700 References: <20090922042637.GA14702@vaf-lnx1> <1FA4E6A1-946B-4451-B87A-1CE28A3DCC32@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 16:37:49.0256 (UTC) FILETIME=[0590BC80:01CA3BA3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1283; t=1253637473; x=1254501473; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20=20Requests |Sender:=20; bh=aCeEJrCUoD9p/K6cXPGjh1hqlX77wYnqwe5E8pxSIMY=; b=u5T8M22JOmui/rBjPfnEfVNGlL04QSJIeyNi90PKg/t8Dn5cnDy5j5AdMO uaKu1VjZ1t+0wLUyOsj3xDdrnskIKwCjwxsY1XK1mODUHx7Ox2f0hq2iMzLD tLovS80HSY; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 16:36:50 -0000 >>>>>> >>>>>> "Dino" == Dino Farinacci writes: > > Dino> That is already in the inner map-request. Why duplicate it? > Dino> Then you have a problem with what fields do you pay > Dino> attention to if they are different. > > O, I'm happier with Margaret's solution. Anything that gets rid of > the inner IP and UDP header works for me. The inner header is easier for an ALT router to process. We really don't want to change that. We want to keep the map-resolver and map-server simpler as well. So just prepending and appending headers is simpler. I don't understand Margaret's proposal because there was too much email back and forth and a lot of misunderstandings. > I explained in my longer message why the inner IP and UDP header are > problematic. Margaret has explained why they are unneeded. Well I think they are needed. > Unneeded, problematic things should go away. > > I was simply proposing a compromise that might be easier to implement The simplest way IMO is what Vince proposed. > than just sending the inner map request as Margaret, Joel and I > originally suggested. I'm definitely happy with that original > approach as well. So, can you briefly summarize Margaret's proposal. Dino From dino@cisco.com Tue Sep 22 09:45: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 710E128C0E0 for ; Tue, 22 Sep 2009 09:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 M0k9hfiYm55T for ; Tue, 22 Sep 2009 09:45:08 -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 B60473A6924 for ; Tue, 22 Sep 2009 09:45:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGOcuEqrR7O6/2dsb2JhbADAY4hPAZALBYQbgV0 X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="245255986" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 22 Sep 2009 16:46:12 +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 n8MGkCuJ026375; Tue, 22 Sep 2009 09:46:12 -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 n8MGkCk7025517; Tue, 22 Sep 2009 16:46:12 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, 22 Sep 2009 09:46:12 -0700 Received: from [192.168.1.2] ([10.21.92.96]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:46:12 -0700 Message-Id: <676A8C54-34B4-4584-A937-149EEAA9CB4C@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 v936) Date: Tue, 22 Sep 2009 09:46:11 -0700 References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 16:46:12.0093 (UTC) FILETIME=[314792D0:01CA3BA4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3435; t=1253637972; x=1254501972; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=aJCEGCer/ZjBl/sNWcYcG2/iMbghzoNV+L3q07cLxWw=; b=d5xi5cG6QrduVEbgOK+Y5+QUQqF2Lof/edwDtILzLBnToWIY0X42KuHQWh RIpDIHPBpywQBi8vHc3SeltHupDKU0UPyUwxHi8v5712PeMdFFC7gMBhbyp0 5fGiIaIlDp; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 16:45:10 -0000 > Hi Dino, > > On Sep 22, 2009, at 12:09 PM, Dino Farinacci wrote: >> >> And we need to make this simple for the network architecture and >> users. > > Could you explain how sending encapsulated Map-Requests is simpler > for the network architecture and users? You want to use off-the-shelf routers for the ALT if you can. You want the flexibility to send an IPv6 Map-Request that keeps the original header built by the ITR to be "routed" by ALT routers on the ALT network even when the path from the ITR to the map-resolver is IPv4- only. You need all the fields that is in the current specs so you can debug problems easier. We have capabilities to do traceroute across ITRs and ETRs and have plans to do it across the ALT. The packet formats are set up in a way right now where all these features fall out easily. >>> I can do a quick and dirty hack of a UDP receiver rapidly: I've done >>> so in a couple of hours for another project. (I'm using another >>> mechanism for the current LISP; also not appropriate for production >>> code, but for a variety of reasons it made more sense.) However >>> doing >>> it right is fairly involved. >>> >>> In conclusion, I don't think this proposal fully addresses my >>> problem. >> >> The proposal makes a small change to what we have now. So we can >> process the various options of mixed address families and keeping >> the ALT and other mechanisms pure. > > This is not the first time that you've indicated that you believe > there may be problem with "mixed address families" if we do not use > encapsulation for the Map-Request, but you have not explained what > the problem would be. Joel and I have both indicated that we don't > see why using an unencapsulated Map-Request would cause problems for > "mixed AFI families". If you still think this would cause a > problem, could you explain it? For debugability reasons you want to build an IPv6 Map-Request with an IPv6 EID being sought in the payload as well as in the destination address of the IPv6 header. You want this to be pure so people can debug IPv6 separately from IPv4 in a ships in the night approach. But the path from the ITR to the map-resolver could be IPv4-only so you need to encapsulate. Joel suggested sending the Map-Request directly from the ITR to the map-resolver and have the map-resolver encapsulate to make the packet flow on the ALT. That means if you wanted to send a IPv6 Map-Request (it should be termed here seeking an IPv6 EID) it would have to be built in an IPv4 packet encoded with a payload with an IPv6 EID). As you can see there are all sorts of combinations that can arise from this. Does the user type "debug ip lisp mapping" and get IPv6 information? Does the user type "debug ipv6 lisp mapping" and get IPv4 headers to print out. There is a huge usability implication with this. >> What Joel proposes is a huge change to the mapping system. And if >> you encapsulate at the ITR versus the map-resolver is 6 and one- >> half dozen or the other. > > I don't see how Joel's proposal is a huge change... Could you > explain why you see it that way? If it is roughly equivalent to do > the encapsulation in the Map Resolver instead of in the ITR, why do > you object so strongly to doing it in the Map Resolver? See above. Dino From jmh@joelhalpern.com Tue Sep 22 09: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 B930F3A685E for ; Tue, 22 Sep 2009 09:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=-0.244, 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 XHFCtqUG8LVU for ; Tue, 22 Sep 2009 09:55:06 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id AE4663A67F4 for ; Tue, 22 Sep 2009 09:55:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 2816B3231862; Tue, 22 Sep 2009 09:56:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id CF5513231863; Tue, 22 Sep 2009 09:56:08 -0700 (PDT) Message-ID: <4AB901A5.90302@joelhalpern.com> Date: Tue, 22 Sep 2009 12:56:05 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> In-Reply-To: <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 16:55:07 -0000 To restate: The proposal under discussion is that the ITR would send requests to the MR using an IP packet addressed to the MR containing a UDP header with the control port, which contains the Map Query that needs to be resolved. The MR would encapsulate this in whatever fashion the ALT wants. Thus, the ITR mechanism is simple and decoupled from the ALT encapsulation. The MS would use this same simple format when sending the packet from itself to the ETR. Again, this keeps the ETR decoupled from the ALT details. As far as I can tell, any combination of address families for the ITR / MR, the ETR / MS, and the EID being sought will work with this setup. Obviously, the ITR and the MR have to share an address family, the ETR and the MS have to share an address family, and the ETR has to support the address family used as the RLOC of the ITR in the request. But there is no coupling among these three. And there is no coupling between that and the address family for the EID. As for debugging, that seems to be in the eye of the beholder. The question of how a command gives back the current mapping tables in an ITR, or generates a query to see the response, is going to depend upon the CLI of the device much more than it will upon this encapsulation question. Yours, Joel Dino Farinacci wrote: >> Hi Dino, >> >> On Sep 22, 2009, at 12:09 PM, Dino Farinacci wrote: >>> >>> And we need to make this simple for the network architecture and users. >> >> Could you explain how sending encapsulated Map-Requests is simpler for >> the network architecture and users? > > You want to use off-the-shelf routers for the ALT if you can. You want > the flexibility to send an IPv6 Map-Request that keeps the original > header built by the ITR to be "routed" by ALT routers on the ALT network > even when the path from the ITR to the map-resolver is IPv4-only. > > You need all the fields that is in the current specs so you can debug > problems easier. > > We have capabilities to do traceroute across ITRs and ETRs and have > plans to do it across the ALT. The packet formats are set up in a way > right now where all these features fall out easily. > >>>> I can do a quick and dirty hack of a UDP receiver rapidly: I've done >>>> so in a couple of hours for another project. (I'm using another >>>> mechanism for the current LISP; also not appropriate for production >>>> code, but for a variety of reasons it made more sense.) However doing >>>> it right is fairly involved. >>>> >>>> In conclusion, I don't think this proposal fully addresses my problem. >>> >>> The proposal makes a small change to what we have now. So we can >>> process the various options of mixed address families and keeping the >>> ALT and other mechanisms pure. >> >> This is not the first time that you've indicated that you believe >> there may be problem with "mixed address families" if we do not use >> encapsulation for the Map-Request, but you have not explained what the >> problem would be. Joel and I have both indicated that we don't see >> why using an unencapsulated Map-Request would cause problems for >> "mixed AFI families". If you still think this would cause a problem, >> could you explain it? > > For debugability reasons you want to build an IPv6 Map-Request with an > IPv6 EID being sought in the payload as well as in the destination > address of the IPv6 header. You want this to be pure so people can debug > IPv6 separately from IPv4 in a ships in the night approach. But the path > from the ITR to the map-resolver could be IPv4-only so you need to > encapsulate. > > Joel suggested sending the Map-Request directly from the ITR to the > map-resolver and have the map-resolver encapsulate to make the packet > flow on the ALT. That means if you wanted to send a IPv6 Map-Request (it > should be termed here seeking an IPv6 EID) it would have to be built in > an IPv4 packet encoded with a payload with an IPv6 EID). As you can see > there are all sorts of combinations that can arise from this. > > Does the user type "debug ip lisp mapping" and get IPv6 information? > Does the user type "debug ipv6 lisp mapping" and get IPv4 headers to > print out. > > There is a huge usability implication with this. > >>> What Joel proposes is a huge change to the mapping system. And if you >>> encapsulate at the ITR versus the map-resolver is 6 and one-half >>> dozen or the other. >> >> I don't see how Joel's proposal is a huge change... Could you explain >> why you see it that way? If it is roughly equivalent to do the >> encapsulation in the Map Resolver instead of in the ITR, why do you >> object so strongly to doing it in the Map Resolver? > > See above. > > Dino > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From mrw@sandstorm.net Tue Sep 22 10:02: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 E26203A67D7 for ; Tue, 22 Sep 2009 10:02:05 -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 jovtzJj278zM for ; Tue, 22 Sep 2009 10:02:05 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id E218A3A698F for ; Tue, 22 Sep 2009 10:02:04 -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 n8MH2iII059743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2009 13:02:45 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <578ABB19-71C0-4348-9344-9BC84DF406A2@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <034F0113-E208-4F4B-B9E9-FC0FEB1EE88F@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, 22 Sep 2009 13:02:44 -0400 References: <20090922042637.GA14702@vaf-lnx1> <1FA4E6A1-946B-4451-B87A-1CE28A3DCC32@cisco.com> <034F0113-E208-4F4B-B9E9-FC0FEB1EE88F@cisco.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 17:02:06 -0000 On Sep 22, 2009, at 12:37 PM, Dino Farinacci wrote: > >> than just sending the inner map request as Margaret, Joel and I >> originally suggested. I'm definitely happy with that original >> approach as well. > > So, can you briefly summarize Margaret's proposal. I don't really have a proposal. I agreed with Joel's proposal (in response to Sam's original message) that we should use unencapsulated packets for all xTR <=> Map Resolver/Server communication, including Map-Requests. So, we'd just send a Map-Request message in a single set of IP/UDP headers from one of the ITR's RLOCs to a configured Map Resolver. If the ITR has more than one RLOC at which it could receive a reply (such as an RLOC from a different address family, or RLOCs with different reachability properties), it could include that information in the "Map Reply Record" of the outgoing request. This approach has several advantages over the encapsulated packets described in LISP -04: It doesn't require ETRs to process packets that are not addressed to them, it allows cleaner separation between LISP control and data traffic (since they go to separate ports), it has somewhat less (bandwidth and processing overhead), and it provides better isolation of the details of the mapping system (in case we decide to swap ALT out later). Vince's proposal has some, but not all, of those advantages. It does provide cleaner separation between LISP control and data traffic (as they go to separate ports). It does not require ETRs to pluck packets out of the LISP Data stream (as -04 does), but ETRs still have to deal with inner headers that aren't addressed to them. And, it still has the problem that the ITR is building an ALT-specific request and encapsulating it to the Map Resolver, which provides considerably less architectural isolation than I would like to see, as it won't necessarily be a property of all mapping systems that they will want an inner packet that is addressed to the source EID. I have another related issue with the Map-Request, which is that it contains both a source EID address and a source EID prefix. Is it expected that an ITR will keep at least one valid source EID around for each prefix, so that it can include it (in the Map Request, and perhaps as an inner header destination address if we keep the encapsulation) when it wants to refresh the RLOC mapping for an EID prefix? Margaret From dino@cisco.com Tue Sep 22 10:02: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 DE4143A690D for ; Tue, 22 Sep 2009 10:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 cCCiw8a087Z5 for ; Tue, 22 Sep 2009 10:02: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 918973A67D7 for ; Tue, 22 Sep 2009 10:02:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOefuEqrR7MV/2dsb2JhbADAVohPAZALBYQbgV0 X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="245267603" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 22 Sep 2009 17:03:36 +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 n8MH3bmU023442; Tue, 22 Sep 2009 10:03:37 -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 n8MH3baC005157; Tue, 22 Sep 2009 17:03:37 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, 22 Sep 2009 10:03:37 -0700 Received: from [192.168.1.2] ([10.21.92.96]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 10:03:36 -0700 Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AB901A5.90302@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, 22 Sep 2009 10:03:36 -0700 References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 17:03:36.0776 (UTC) FILETIME=[9FF58C80:01CA3BA6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5957; t=1253639017; x=1254503017; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=4oIk1AXG0nLBQLeHGhbmKgnUARkbnJYTsf/NBp3ZJt0=; b=Bh47TlIlJpC1ZcteZiP8PmYCd/zDcpazuwXd0nwhgjbu7osQDpsuMbDk6+ pI+M6qd8gvzdPsDcxnouMeJOud74DzLcIgsOLjOwkgFyFFr94XZepamSUNHL L0eTftgTzyOp3uGleEe3Brii1aaDb17l2FYdgq1P7gEJdver3/eUg=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 17:02:34 -0000 > To restate: > The proposal under discussion is that the ITR would send requests to > the MR using an IP packet addressed to the MR containing a UDP > header with the control port, which contains the Map Query that > needs to be resolved. Is a Map Query different than a Map-Request? > The MR would encapsulate this in whatever fashion the ALT wants. > Thus, the ITR mechanism is simple and decoupled from the ALT > encapsulation. Which means the MR would have to parse the Map-Request to pull out the EID to build the header. An extra cost we did not have when the ITR did this. > The MS would use this same simple format when sending the packet > from itself to the ETR. Again, this keeps the ETR decoupled from > the ALT details. Right. > As far as I can tell, any combination of address families for the > ITR / MR, the ETR / MS, and the EID being sought will work with this > setup. Obviously, the ITR and the MR have to share an address > family, the ETR and the MS have to share an address family, and the > ETR has to support the address family used as the RLOC of the ITR in > the request. But there is no coupling among these three. And there > is no coupling between that and the address family for the EID. Right, so this is no different from what we have today but you want the encapsulating of the control packet to happen on the MR and MS where we want the encapsulating to happen on ITR and ETR. Today an MR/NS is really simple. It just decaps and encaps and looks up packets in a routing table. It really doesn't have to run any LISP actually. It can be a product from a vendor that wants to sell infrastructure but not do the entire LISP spec. Your proposal makes the MR/MS do the work that the ITR and ETR are already doing. > As for debugging, that seems to be in the eye of the beholder. The > question of how a command gives back the current mapping tables in > an ITR, or generates a query to see the response, is going to depend > upon the CLI of the device much more than it will upon this > encapsulation question. Right. Dino > > Yours, > Joel > > > Dino Farinacci wrote: >>> Hi Dino, >>> >>> On Sep 22, 2009, at 12:09 PM, Dino Farinacci wrote: >>>> >>>> And we need to make this simple for the network architecture and >>>> users. >>> >>> Could you explain how sending encapsulated Map-Requests is simpler >>> for the network architecture and users? >> You want to use off-the-shelf routers for the ALT if you can. You >> want the flexibility to send an IPv6 Map-Request that keeps the >> original header built by the ITR to be "routed" by ALT routers on >> the ALT network even when the path from the ITR to the map-resolver >> is IPv4-only. >> You need all the fields that is in the current specs so you can >> debug problems easier. >> We have capabilities to do traceroute across ITRs and ETRs and have >> plans to do it across the ALT. The packet formats are set up in a >> way right now where all these features fall out easily. >>>>> I can do a quick and dirty hack of a UDP receiver rapidly: I've >>>>> done >>>>> so in a couple of hours for another project. (I'm using another >>>>> mechanism for the current LISP; also not appropriate for >>>>> production >>>>> code, but for a variety of reasons it made more sense.) However >>>>> doing >>>>> it right is fairly involved. >>>>> >>>>> In conclusion, I don't think this proposal fully addresses my >>>>> problem. >>>> >>>> The proposal makes a small change to what we have now. So we can >>>> process the various options of mixed address families and keeping >>>> the ALT and other mechanisms pure. >>> >>> This is not the first time that you've indicated that you believe >>> there may be problem with "mixed address families" if we do not >>> use encapsulation for the Map-Request, but you have not explained >>> what the problem would be. Joel and I have both indicated that we >>> don't see why using an unencapsulated Map-Request would cause >>> problems for "mixed AFI families". If you still think this would >>> cause a problem, could you explain it? >> For debugability reasons you want to build an IPv6 Map-Request with >> an IPv6 EID being sought in the payload as well as in the >> destination address of the IPv6 header. You want this to be pure so >> people can debug IPv6 separately from IPv4 in a ships in the night >> approach. But the path from the ITR to the map-resolver could be >> IPv4-only so you need to encapsulate. >> Joel suggested sending the Map-Request directly from the ITR to the >> map-resolver and have the map-resolver encapsulate to make the >> packet flow on the ALT. That means if you wanted to send a IPv6 Map- >> Request (it should be termed here seeking an IPv6 EID) it would >> have to be built in an IPv4 packet encoded with a payload with an >> IPv6 EID). As you can see there are all sorts of combinations that >> can arise from this. >> Does the user type "debug ip lisp mapping" and get IPv6 >> information? Does the user type "debug ipv6 lisp mapping" and get >> IPv4 headers to print out. >> There is a huge usability implication with this. >>>> What Joel proposes is a huge change to the mapping system. And if >>>> you encapsulate at the ITR versus the map-resolver is 6 and one- >>>> half dozen or the other. >>> >>> I don't see how Joel's proposal is a huge change... Could you >>> explain why you see it that way? If it is roughly equivalent to >>> do the encapsulation in the Map Resolver instead of in the ITR, >>> why do you object so strongly to doing it in the Map Resolver? >> See above. >> Dino >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Tue Sep 22 10:09: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 9CFE33A688D for ; Tue, 22 Sep 2009 10:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.841 X-Spam-Level: X-Spam-Status: No, score=-2.841 tagged_above=-999 required=5 tests=[AWL=-0.242, 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 UuQN+MHcGuXW for ; Tue, 22 Sep 2009 10:09:55 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 7D2D93A67F4 for ; Tue, 22 Sep 2009 10:09:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id F27D0322C18B; Tue, 22 Sep 2009 10:10:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id E6383322C269; Tue, 22 Sep 2009 10:10:58 -0700 (PDT) Message-ID: <4AB90520.60903@joelhalpern.com> Date: Tue, 22 Sep 2009 13:10:56 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 17:09:56 -0000 Yes, I want the MS and MR to do the work of isolating the ITR/ETR from the details of the format used by the ALT. Yes, that means the MS / MR are more than just relay nodes. So be it. There are presumably a lot more ITRs and ETRs than there are MS and MR, so I would prefer that the MS / MR pay the code complexity cost. The request (yes I used Map-Query when I should have said Map-Request. Sorry.) rates are presumably going to be low enough that this is quite doable. Frankly, I had not even realized when I read the original map server draft that you intended them to be pure relay agents. I had thought that their purpose was isolation and versatility. Yours, Joel Dino Farinacci wrote: >> To restate: >> The proposal under discussion is that the ITR would send requests to >> the MR using an IP packet addressed to the MR containing a UDP header >> with the control port, which contains the Map Query that needs to be >> resolved. > > Is a Map Query different than a Map-Request? > >> The MR would encapsulate this in whatever fashion the ALT wants. >> Thus, the ITR mechanism is simple and decoupled from the ALT >> encapsulation. > > Which means the MR would have to parse the Map-Request to pull out the > EID to build the header. An extra cost we did not have when the ITR did > this. > >> The MS would use this same simple format when sending the packet from >> itself to the ETR. Again, this keeps the ETR decoupled from the ALT >> details. > > Right. > >> As far as I can tell, any combination of address families for the ITR >> / MR, the ETR / MS, and the EID being sought will work with this >> setup. Obviously, the ITR and the MR have to share an address family, >> the ETR and the MS have to share an address family, and the ETR has to >> support the address family used as the RLOC of the ITR in the >> request. But there is no coupling among these three. And there is no >> coupling between that and the address family for the EID. > > Right, so this is no different from what we have today but you want the > encapsulating of the control packet to happen on the MR and MS where we > want the encapsulating to happen on ITR and ETR. > > Today an MR/NS is really simple. It just decaps and encaps and looks up > packets in a routing table. It really doesn't have to run any LISP > actually. It can be a product from a vendor that wants to sell > infrastructure but not do the entire LISP spec. > > Your proposal makes the MR/MS do the work that the ITR and ETR are > already doing. > >> As for debugging, that seems to be in the eye of the beholder. The >> question of how a command gives back the current mapping tables in an >> ITR, or generates a query to see the response, is going to depend upon >> the CLI of the device much more than it will upon this encapsulation >> question. > > Right. > > Dino > >> >> Yours, >> Joel >> >> >> Dino Farinacci wrote: >>>> Hi Dino, >>>> >>>> On Sep 22, 2009, at 12:09 PM, Dino Farinacci wrote: >>>>> >>>>> And we need to make this simple for the network architecture and >>>>> users. >>>> >>>> Could you explain how sending encapsulated Map-Requests is simpler >>>> for the network architecture and users? >>> You want to use off-the-shelf routers for the ALT if you can. You >>> want the flexibility to send an IPv6 Map-Request that keeps the >>> original header built by the ITR to be "routed" by ALT routers on the >>> ALT network even when the path from the ITR to the map-resolver is >>> IPv4-only. >>> You need all the fields that is in the current specs so you can debug >>> problems easier. >>> We have capabilities to do traceroute across ITRs and ETRs and have >>> plans to do it across the ALT. The packet formats are set up in a way >>> right now where all these features fall out easily. >>>>>> I can do a quick and dirty hack of a UDP receiver rapidly: I've done >>>>>> so in a couple of hours for another project. (I'm using another >>>>>> mechanism for the current LISP; also not appropriate for production >>>>>> code, but for a variety of reasons it made more sense.) However doing >>>>>> it right is fairly involved. >>>>>> >>>>>> In conclusion, I don't think this proposal fully addresses my >>>>>> problem. >>>>> >>>>> The proposal makes a small change to what we have now. So we can >>>>> process the various options of mixed address families and keeping >>>>> the ALT and other mechanisms pure. >>>> >>>> This is not the first time that you've indicated that you believe >>>> there may be problem with "mixed address families" if we do not use >>>> encapsulation for the Map-Request, but you have not explained what >>>> the problem would be. Joel and I have both indicated that we don't >>>> see why using an unencapsulated Map-Request would cause problems for >>>> "mixed AFI families". If you still think this would cause a >>>> problem, could you explain it? >>> For debugability reasons you want to build an IPv6 Map-Request with >>> an IPv6 EID being sought in the payload as well as in the destination >>> address of the IPv6 header. You want this to be pure so people can >>> debug IPv6 separately from IPv4 in a ships in the night approach. But >>> the path from the ITR to the map-resolver could be IPv4-only so you >>> need to encapsulate. >>> Joel suggested sending the Map-Request directly from the ITR to the >>> map-resolver and have the map-resolver encapsulate to make the packet >>> flow on the ALT. That means if you wanted to send a IPv6 Map-Request >>> (it should be termed here seeking an IPv6 EID) it would have to be >>> built in an IPv4 packet encoded with a payload with an IPv6 EID). As >>> you can see there are all sorts of combinations that can arise from >>> this. >>> Does the user type "debug ip lisp mapping" and get IPv6 information? >>> Does the user type "debug ipv6 lisp mapping" and get IPv4 headers to >>> print out. >>> There is a huge usability implication with this. >>>>> What Joel proposes is a huge change to the mapping system. And if >>>>> you encapsulate at the ITR versus the map-resolver is 6 and >>>>> one-half dozen or the other. >>>> >>>> I don't see how Joel's proposal is a huge change... Could you >>>> explain why you see it that way? If it is roughly equivalent to do >>>> the encapsulation in the Map Resolver instead of in the ITR, why do >>>> you object so strongly to doing it in the Map Resolver? >>> See above. >>> Dino >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp > > From dino@cisco.com Tue Sep 22 10:19: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 1ABE23A68C1 for ; Tue, 22 Sep 2009 10:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 YvWNAJ4uzABq for ; Tue, 22 Sep 2009 10:19: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 D32493A67D7 for ; Tue, 22 Sep 2009 10:19:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALCkuEqrR7MV/2dsb2JhbADAWIhPAZALBYQb X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="245280138" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 22 Sep 2009 17:19:15 +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 n8MHJFR7006895; Tue, 22 Sep 2009 10:19:15 -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 n8MHJFdT026708; Tue, 22 Sep 2009 17:19:15 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, 22 Sep 2009 10:19:14 -0700 Received: from [192.168.1.2] ([10.21.92.96]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 10:19:14 -0700 Message-Id: <1C864DEA-AA58-486D-94AB-D6BEE1B8210B@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <578ABB19-71C0-4348-9344-9BC84DF406A2@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, 22 Sep 2009 10:19:13 -0700 References: <20090922042637.GA14702@vaf-lnx1> <1FA4E6A1-946B-4451-B87A-1CE28A3DCC32@cisco.com> <034F0113-E208-4F4B-B9E9-FC0FEB1EE88F@cisco.com> <578ABB19-71C0-4348-9344-9BC84DF406A2@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 17:19:14.0112 (UTC) FILETIME=[CEA7AC00:01CA3BA8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4925; t=1253639955; x=1254503955; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=PtfHb85a+WE/sxhbDMEWWIxJ6uiBd26cKSVR1JSm8us=; b=bh8LV21e0jlXIeRUNqVFAbkI1vimF2lJVGfW14Dlh0M/9u08fqjUHzoVVK rWlmSD5ExfpKNB1SgUVYCX2hWlrbcsGyzfNUXoCiTE5EorxJ7rP8oC9CGXUr /e1+8Dy/cGzgkgHPRO6nWugcMNdnquo4VCsOydWghq6DJSlAMYvpY=; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 17:19:53 -0000 > On Sep 22, 2009, at 12:37 PM, Dino Farinacci wrote: >> >>> than just sending the inner map request as Margaret, Joel and I >>> originally suggested. I'm definitely happy with that original >>> approach as well. >> >> So, can you briefly summarize Margaret's proposal. > > I don't really have a proposal. I agreed with Joel's proposal (in > response to Sam's original message) Okay, that is good to know. So there are 2 options then. > that we should use unencapsulated packets for all xTR <=> Map > Resolver/Server communication, including Map-Requests. So, we'd > just send a Map-Request message in a single set of IP/UDP headers > from one of the ITR's RLOCs to a configured Map Resolver. If the > ITR has more than one RLOC at which it could receive a reply (such > as an RLOC from a different address family, or RLOCs with different > reachability properties), it could include that information in the > "Map Reply Record" of the outgoing request. Just note this last part happens today the way the Map-Request is encoded. > This approach has several advantages over the encapsulated packets > described in LISP -04: It doesn't require ETRs to process packets > that are not addressed to them, it allows cleaner separation between > LISP Once the encapsulated packet gets to the LISP process because the outer header *is addressed to ETRs*, then it can look at the inner destination address to see if the EID is one of it's configured EID- prefixes. And if not, and the ETR is attached to the ALT, the ETR *may* want to forward it. There is important functionality here that you don't want to lose. > control and data traffic (since they go to separate ports), it has > somewhat less (bandwidth and processing overhead), and it provides > better isolation of the details of the mapping system (in case we > decide to swap ALT out later). The separation is made because of using port 4342. Once that pops the packet out of the data plane then you can process it. So having the inner header destination address not addressed to the ETR has no impact on the data plane. That is the reason for Vince's fix! > Vince's proposal has some, but not all, of those advantages. It > does provide cleaner separation between Let me remind you that Vince's proposal is an easy fix to the architecture where the ITR encaps Map-Requests and the ETR decaps Map- Requests. > LISP control and data traffic (as they go to separate ports). It > does not require ETRs to pluck packets out of the LISP Data stream > (as -04 does), but ETRs still have to deal with inner headers that > aren't addressed to them. And, it still has the problem that the > ITR is building an ALT-specific request and But not in the data plane. So it doesn't matter. The ITR is not building an ALT specific request. It allows the database mapping topology to not have to do deep packet inspection. That is a big advantage. > encapsulating it to the Map Resolver, which provides considerably > less architectural isolation than I would like to see, as it won't > necessarily be a property of all mapping systems that they will want > an inner packet that is addressed to the source EID. If you make any component in the mapping system have to parse packets, then any changes to Map-Requests will require a fork-lift upgrade to the entire mapping system. When the mapping system gets to be large it will be a complete non-starter. We think it's a really good feature to make the mapping system node be regular ole IP routers. We can do this when the mapping system is a DHT as well. Do you realize that we can take out BGP from the ALT and make it MPLS and not have to change the xTRs and MS/MRs if we wanted to? If we wanted the ALT to run another protocol like say OSPF, we could do that now. If we wanted the ALT to be a static configuration of a hierarchy like DNS is, we can do this now. And we don't have to change code in the MRs and MSs to do this. This is extremely powerful. > I have another related issue with the Map-Request, which is that it > contains both a source EID address and a source EID prefix. That is there so when you are debugging on an ALT router you know the source of the packet. > Is it expected that an ITR will keep at least one valid source EID > around for each prefix, so that it No, why would it need to do that? And what does "keep source EID around" mean? > can include it (in the Map Request, and perhaps as an inner header > destination address if we keep the encapsulation) when it wants to > refresh the RLOC mapping for an EID prefix? Map-Requests are triggered by a map-cache miss from a data packet. So the source is known at that time and inserted in the Map-Request. Dino From dino@cisco.com Tue Sep 22 10:23: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 53C713A6A89 for ; Tue, 22 Sep 2009 10:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 ELzWIpeyCrHj for ; Tue, 22 Sep 2009 10:23: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 010913A68E2 for ; Tue, 22 Sep 2009 10:23:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANSkuEqrR7MV/2dsb2JhbADAXIhPAZALBYQbgV0 X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="207071228" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 22 Sep 2009 17:24:41 +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 n8MHOenL020462; Tue, 22 Sep 2009 10:24:40 -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 n8MHOewK018345; Tue, 22 Sep 2009 17:24:40 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, 22 Sep 2009 10:24:39 -0700 Received: from [192.168.1.2] ([10.21.92.96]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 10:24:39 -0700 Message-Id: <43AC3DA1-06AD-4989-A1C2-D7B5BFC0A06D@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AB90520.60903@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, 22 Sep 2009 10:24:39 -0700 References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> <4AB90520.60903@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 17:24:39.0297 (UTC) FILETIME=[907AF710:01CA3BA9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7668; t=1253640280; x=1254504280; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=efdOnKp3e2UgJJ76T9uL4PeKzuOjLf7/CQpbpdK8npc=; b=GMUvKR2PA/wo6tQWNPOdXl6lyq4XcW1yDrzpTNB2tWZs6trzMs+M51tAlu ZA65c73/H3sk7HkNotSeRzgWDQu79xXFiiJYhfm+K8+8ij+UTxNEDw7l1J93 YCN31VofiThRXRhJx6zB+Th7jdL3vpDaOqqFI6xl7w5IbBVo1ngbU=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 17:23:38 -0000 > Yes, I want the MS and MR to do the work of isolating the ITR/ETR > from the details of the format used by the ALT. Yes, that means the > MS / MR are more than just relay nodes. So be it. Noted. > There are presumably a lot more ITRs and ETRs than there are MS and > MR, so I would prefer that the MS / MR pay the code complexity cost. The complexity is internal and not to the user. But the user has a level of indirection at the site. The cost is by the programmer at development time. So it is fixed and one-time. And with the Encapsulating Control Message, we could create a virtualized LISP on top of LISP so Map-Replies and even Map-Registers could be encapsulated. Think about that for a moment. Could come in handy as a great feature. Also, there are large hosting sites that want to be attached to the ALT, so the ITR will need to support sending with a destination address to an EID. > The request (yes I used Map-Query when I should have said Map- > Request. Sorry.) rates are presumably going to be low enough that > this is quite doable. That is hard to say. It depends how misconfigured things get. ;-) > Frankly, I had not even realized when I read the original map server > draft that you intended them to be pure relay agents. I had thought > that their purpose was isolation and versatility. Both. As well as anycast nodes. Dino > > Yours, > Joel > > Dino Farinacci wrote: >>> To restate: >>> The proposal under discussion is that the ITR would send requests >>> to the MR using an IP packet addressed to the MR containing a UDP >>> header with the control port, which contains the Map Query that >>> needs to be resolved. >> Is a Map Query different than a Map-Request? >>> The MR would encapsulate this in whatever fashion the ALT wants. >>> Thus, the ITR mechanism is simple and decoupled from the ALT >>> encapsulation. >> Which means the MR would have to parse the Map-Request to pull out >> the EID to build the header. An extra cost we did not have when the >> ITR did this. >>> The MS would use this same simple format when sending the packet >>> from itself to the ETR. Again, this keeps the ETR decoupled from >>> the ALT details. >> Right. >>> As far as I can tell, any combination of address families for the >>> ITR / MR, the ETR / MS, and the EID being sought will work with >>> this setup. Obviously, the ITR and the MR have to share an address >>> family, the ETR and the MS have to share an address family, and >>> the ETR has to support the address family used as the RLOC of the >>> ITR in the request. But there is no coupling among these three. >>> And there is no coupling between that and the address family for >>> the EID. >> Right, so this is no different from what we have today but you want >> the encapsulating of the control packet to happen on the MR and MS >> where we want the encapsulating to happen on ITR and ETR. >> Today an MR/NS is really simple. It just decaps and encaps and >> looks up packets in a routing table. It really doesn't have to run >> any LISP actually. It can be a product from a vendor that wants to >> sell infrastructure but not do the entire LISP spec. >> Your proposal makes the MR/MS do the work that the ITR and ETR are >> already doing. >>> As for debugging, that seems to be in the eye of the beholder. >>> The question of how a command gives back the current mapping >>> tables in an ITR, or generates a query to see the response, is >>> going to depend upon the CLI of the device much more than it will >>> upon this encapsulation question. >> Right. >> Dino >>> >>> Yours, >>> Joel >>> >>> >>> Dino Farinacci wrote: >>>>> Hi Dino, >>>>> >>>>> On Sep 22, 2009, at 12:09 PM, Dino Farinacci wrote: >>>>>> >>>>>> And we need to make this simple for the network architecture >>>>>> and users. >>>>> >>>>> Could you explain how sending encapsulated Map-Requests is >>>>> simpler for the network architecture and users? >>>> You want to use off-the-shelf routers for the ALT if you can. You >>>> want the flexibility to send an IPv6 Map-Request that keeps the >>>> original header built by the ITR to be "routed" by ALT routers on >>>> the ALT network even when the path from the ITR to the map- >>>> resolver is IPv4-only. >>>> You need all the fields that is in the current specs so you can >>>> debug problems easier. >>>> We have capabilities to do traceroute across ITRs and ETRs and >>>> have plans to do it across the ALT. The packet formats are set up >>>> in a way right now where all these features fall out easily. >>>>>>> I can do a quick and dirty hack of a UDP receiver rapidly: >>>>>>> I've done >>>>>>> so in a couple of hours for another project. (I'm using another >>>>>>> mechanism for the current LISP; also not appropriate for >>>>>>> production >>>>>>> code, but for a variety of reasons it made more sense.) >>>>>>> However doing >>>>>>> it right is fairly involved. >>>>>>> >>>>>>> In conclusion, I don't think this proposal fully addresses my >>>>>>> problem. >>>>>> >>>>>> The proposal makes a small change to what we have now. So we >>>>>> can process the various options of mixed address families and >>>>>> keeping the ALT and other mechanisms pure. >>>>> >>>>> This is not the first time that you've indicated that you >>>>> believe there may be problem with "mixed address families" if we >>>>> do not use encapsulation for the Map-Request, but you have not >>>>> explained what the problem would be. Joel and I have both >>>>> indicated that we don't see why using an unencapsulated Map- >>>>> Request would cause problems for "mixed AFI families". If you >>>>> still think this would cause a problem, could you explain it? >>>> For debugability reasons you want to build an IPv6 Map-Request >>>> with an IPv6 EID being sought in the payload as well as in the >>>> destination address of the IPv6 header. You want this to be pure >>>> so people can debug IPv6 separately from IPv4 in a ships in the >>>> night approach. But the path from the ITR to the map-resolver >>>> could be IPv4-only so you need to encapsulate. >>>> Joel suggested sending the Map-Request directly from the ITR to >>>> the map-resolver and have the map-resolver encapsulate to make >>>> the packet flow on the ALT. That means if you wanted to send a >>>> IPv6 Map-Request (it should be termed here seeking an IPv6 EID) >>>> it would have to be built in an IPv4 packet encoded with a >>>> payload with an IPv6 EID). As you can see there are all sorts of >>>> combinations that can arise from this. >>>> Does the user type "debug ip lisp mapping" and get IPv6 >>>> information? Does the user type "debug ipv6 lisp mapping" and get >>>> IPv4 headers to print out. >>>> There is a huge usability implication with this. >>>>>> What Joel proposes is a huge change to the mapping system. And >>>>>> if you encapsulate at the ITR versus the map-resolver is 6 and >>>>>> one-half dozen or the other. >>>>> >>>>> I don't see how Joel's proposal is a huge change... Could you >>>>> explain why you see it that way? If it is roughly equivalent to >>>>> do the encapsulation in the Map Resolver instead of in the ITR, >>>>> why do you object so strongly to doing it in the Map Resolver? >>>> See above. >>>> Dino >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp From mrw@sandstorm.net Tue Sep 22 10:32: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 C1E6728C117 for ; Tue, 22 Sep 2009 10:32:55 -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 2sMc-VYkQk4L for ; Tue, 22 Sep 2009 10:32:55 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id C214C28C118 for ; Tue, 22 Sep 2009 10:32:54 -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 n8MHXtkA062578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2009 13:33:55 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: 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 v936) Date: Tue, 22 Sep 2009 13:33:55 -0400 References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 17:32:55 -0000 On Sep 22, 2009, at 1:03 PM, Dino Farinacci wrote: > > Today an MR/NS is really simple. It just decaps and encaps and looks > up packets in a routing table. It really doesn't have to run any > LISP actually. It can be a product from a vendor that wants to sell > infrastructure but not do the entire LISP spec. Your current perception of the MR and MS as BGP routers is understandable, given the nature of the ALT. However, that isn't guaranteed to be a constant for LISP. The constant will be that the MR and MS provide a mapping service to their clients (ITRs and ETRs). Ideally, the interface to the mapping service should remain constant, even if the underlying mapping system changes. So, it doesn't make architectural sense for an ITR to build an encapsulated ALT mapping packet and send it to the MR. I also don't think it is realistic that the MR/MS will remain as simple as you describe, nor do I believe that it is possible (or even desirable) for the MR or the MS to have no LISP-specific code. ITRs register with Map Servers, so obviously Map Servers will have LISP-specific code to process and maintain those registrations. Map Servers also need authentication information configured for each of the ITRs they serve, etc. There are also likely to be a number of anti-spoofing requirements for the mapping system that go well beyond the need to read the EID from the request. For example, the mapping system (at one end or the other) will have to check the contents of the "Map Reply Record" if one is included in the Map Request, to ensure that the mapping information in that reply is accurate, and that it is consistent with the source RLOC(s) included in the outer header(s). We may also have to do something to authenticate the map replies, which will almost certainly involve processing the contents bytes of the reply packet. It might, for example, involve verifying the reply, hashing the contents of the reply, and signing the reply with a certificate... Margaret From jmh@joelhalpern.com Tue Sep 22 10:42: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 A82B33A6946 for ; Tue, 22 Sep 2009 10:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.84 X-Spam-Level: X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[AWL=-0.241, 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 ul1E6TNxwwHr for ; Tue, 22 Sep 2009 10:42:42 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 3D5BA3A67AD for ; Tue, 22 Sep 2009 10:42:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B9DDE32317C6; Tue, 22 Sep 2009 10:43:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 324B132317B0; Tue, 22 Sep 2009 10:43:46 -0700 (PDT) Message-ID: <4AB90CCF.4080607@joelhalpern.com> Date: Tue, 22 Sep 2009 13:43:43 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <20090922042637.GA14702@vaf-lnx1> <1FA4E6A1-946B-4451-B87A-1CE28A3DCC32@cisco.com> <034F0113-E208-4F4B-B9E9-FC0FEB1EE88F@cisco.com> <578ABB19-71C0-4348-9344-9BC84DF406A2@sandstorm.net> <1C864DEA-AA58-486D-94AB-D6BEE1B8210B@cisco.com> In-Reply-To: <1C864DEA-AA58-486D-94AB-D6BEE1B8210B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 17:42:44 -0000 I must be misunderstanding your point: Dino Farinacci wrote: ... > If you make any component in the mapping system have to parse packets, > then any changes to Map-Requests will require a fork-lift upgrade to the > entire mapping system. When the mapping system gets to be large it will > be a complete non-starter. ... If MR and MS nodes are pure relay, then in order to change the format of a Map Query, as sent by an ITR, every ETR in the world would have to have the upgraded software. In contrast, MS could accept an alternative form, and transform it to whatever the ALT handles. And MRs (which have registrations from ETRs) could, at least in theory, transform the ALT format into whatever the ETR wants. In practice, I think that changing the map request or map response format is going to be extremely difficult under either model. But if I had to pick one that I thought might be upgradeable, it would be an approach with MR and MS as active components rather than merely relays. Yours, Joel From mrw@sandstorm.net Tue Sep 22 10:54: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 C14E53A67E2 for ; Tue, 22 Sep 2009 10:54: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 ttXoJiF8JeEb for ; Tue, 22 Sep 2009 10:54:14 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 7CBA93A67B6 for ; Tue, 22 Sep 2009 10:54:14 -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 n8MHtEMb063832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2009 13:55:14 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <1C864DEA-AA58-486D-94AB-D6BEE1B8210B@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, 22 Sep 2009 13:55:14 -0400 References: <20090922042637.GA14702@vaf-lnx1> <1FA4E6A1-946B-4451-B87A-1CE28A3DCC32@cisco.com> <034F0113-E208-4F4B-B9E9-FC0FEB1EE88F@cisco.com> <578ABB19-71C0-4348-9344-9BC84DF406A2@sandstorm.net> <1C864DEA-AA58-486D-94AB-D6BEE1B8210B@cisco.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 17:54:15 -0000 On Sep 22, 2009, at 1:19 PM, Dino Farinacci wrote: >> This approach has several advantages over the encapsulated packets >> described in LISP -04: It doesn't require ETRs to process packets >> that are not addressed to them, it allows cleaner separation >> between LISP > > Once the encapsulated packet gets to the LISP process because the > outer header *is addressed to ETRs*, then it can look at the inner > destination address to see if the EID is one of it's configured EID- > prefixes. And if not, and the ETR is attached to the ALT, the ETR > *may* want to forward it. > > There is important functionality here that you don't want to lose. Are you picturing ETRs as multi-interface routers that may serve as transit points in the ALT? I thought that the ALT topology was entirely separate from the RLOCs topology, so it seems somewhat broken for an ETR to take a packet that was already processed by the ALT (and then sent to the ETR at his RLOC), and send it back into the ALT. Shouldn't the ITR get a negative response instead? >> control and data traffic (since they go to separate ports), it has >> somewhat less (bandwidth and processing overhead), and it provides >> better isolation of the details of the mapping system (in case we >> decide to swap ALT out later). > > The separation is made because of using port 4342. Once that pops > the packet out of the data plane then you can process it. So having > the inner header destination address not addressed to the ETR has no > impact on the data plane. > > That is the reason for Vince's fix! I agree that Vince's proposed change would fix one part of the reported problem -- the need to pluck Map-Requests out of the data stream. Are you effectively saying that the inner encapsulation is meaningless at this point, except as a 28 to 48 byte field that holds one IP address that is already included elsewhere in the packet? What is the ETR supposed to do if there are errors in the inner packet that require an ICMP response? Or if the inner packet is _not_ addressed to one of the ETRs RLOCs? Which RLOC should the ETR use for a reply if the inner and outer source RLOCs don't match? >> I have another related issue with the Map-Request, which is that it >> contains both a source EID address and a source EID prefix. > > That is there so when you are debugging on an ALT router you know > the source of the packet. > >> Is it expected that an ITR will keep at least one valid source EID >> around for each prefix, so that it > > No, why would it need to do that? > > And what does "keep source EID around" mean? > Map-Requests are triggered by a map-cache miss from a data packet. > So the source is known at that time and inserted in the Map-Request. I was told in another thread that it would be possible, and probably desirable, to refresh map cache entries before they expire. So, I won't necessarily have an outgoing packet with a destination EID at that time. So, what would I use as the destination EID for the inner header, instead? Do I need to store the original EID that was used to create the mapping, so that I can use it again? Choose an arbitrary EID from the prefix? Something else? Margaret From dino@cisco.com Tue Sep 22 12:16: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 70F8D3A68EF for ; Tue, 22 Sep 2009 12:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 qSorjc9vJo93 for ; Tue, 22 Sep 2009 12:16: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 3118D3A6831 for ; Tue, 22 Sep 2009 12:16:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIu/uEqrR7O6/2dsb2JhbAC/fIhPAZAZBYQb X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="245341218" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 22 Sep 2009 19:17: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 n8MJHB8X018715; Tue, 22 Sep 2009 12:17: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 n8MJHBpQ017064; Tue, 22 Sep 2009 19:17:11 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, 22 Sep 2009 12:17:11 -0700 Received: from dhcp-171-70-249-6.cisco.com ([171.70.249.6]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 12:17:10 -0700 Message-Id: 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 v936) Date: Tue, 22 Sep 2009 12:17:09 -0700 References: <20090922042637.GA14702@vaf-lnx1> <1FA4E6A1-946B-4451-B87A-1CE28A3DCC32@cisco.com> <034F0113-E208-4F4B-B9E9-FC0FEB1EE88F@cisco.com> <578ABB19-71C0-4348-9344-9BC84DF406A2@sandstorm.net> <1C864DEA-AA58-486D-94AB-D6BEE1B8210B@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 19:17:11.0000 (UTC) FILETIME=[48CF1580:01CA3BB9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=724; t=1253647031; x=1254511031; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=4Rtqz32Ech71VrjWo5o1kQ/1pFWKdV3+tUZVxnT2cwY=; b=nLADIxutywoCP34wCoy/9gY2t/lzpmKk++tim+hcSmjlBXhfh/eoFcUYdt WcQZHiZxuHkxlo7mKttNeguNO13DCtZoiYsLxQRpyBpbgmqkkhyGNNOlI+Hk AZh/8u0LjF; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 19:16:08 -0000 > was told in another thread that it would be possible, and probably > desirable, to refresh map cache entries before they expire. So, I > won't necessarily have an outgoing packet with a destination EID at > that time. So, what would I use as the destination EID for the > inner header, instead? Do I need to store the original EID that > was used to create the mapping, so that I can use it again? Choose > an arbitrary EID from the prefix? Something else? The destination-EID in refreshes can use the EID-prefix with zero-fill host bits. I will make a note to make this more clear in the spec. You said source-EID in your last email but I see you meant destination- EID. Ack. Dino From dino@cisco.com Tue Sep 22 12:26: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 85A623A6AC3 for ; Tue, 22 Sep 2009 12:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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+mwXfzSKEmU for ; Tue, 22 Sep 2009 12:26:52 -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 2B5993A6ACC for ; Tue, 22 Sep 2009 12:26:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFrCuEqrR7PE/2dsb2JhbAC/YIhPAZAaBYQb X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="393859957" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Sep 2009 19:27:56 +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 n8MJRujh027042; Tue, 22 Sep 2009 12:27:56 -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 n8MJRutL013982; Tue, 22 Sep 2009 19:27:56 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, 22 Sep 2009 12:27:56 -0700 Received: from dhcp-171-70-249-6.cisco.com ([171.70.249.6]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 12:27:56 -0700 Message-Id: <21B45D04-13B5-4DFD-A099-AE8886E507A8@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AB90CCF.4080607@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, 22 Sep 2009 12:27:55 -0700 References: <20090922042637.GA14702@vaf-lnx1> <1FA4E6A1-946B-4451-B87A-1CE28A3DCC32@cisco.com> <034F0113-E208-4F4B-B9E9-FC0FEB1EE88F@cisco.com> <578ABB19-71C0-4348-9344-9BC84DF406A2@sandstorm.net> <1C864DEA-AA58-486D-94AB-D6BEE1B8210B@cisco.com> <4AB90CCF.4080607@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 19:27:56.0077 (UTC) FILETIME=[C94E05D0:01CA3BBA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2128; t=1253647676; x=1254511676; 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=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=RMknyKthCfHlMNUh7WBSv78DvoOI7CqukeFJymNv7ZI=; b=o2MuLvq6M26LWJ7cLow8hUixvOef0VtiI1h+Lop57DlD0Mbpm1v8J2S6qF qzxPMYbOLzzIz3DFYlGG0JVMgMhR5rjS1itqantGjoS2FDRP5sKkqwl04ICA lyptURXLMm; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 19:26:53 -0000 > I must be misunderstanding your point: > > Dino Farinacci wrote: > ... >> If you make any component in the mapping system have to parse >> packets, then any changes to Map-Requests will require a fork-lift >> upgrade to the entire mapping system. When the mapping system gets >> to be large it will be a complete non-starter. > ... > > If MR and MS nodes are pure relay, then in order to change the > format of a Map Query, as sent by an ITR, every ETR in the world > would have to have the upgraded software. You will find that if you change the Map-Request format, all of xTRs and MS/MRs will have to change. In our scheme only the xTRs do. The reason the MS/MR would change in your proposal is because you are requiring them to parse the Map-Request. > In contrast, MS could accept an alternative form, and transform it > to whatever the ALT handles. And MRs (which have registrations from > ETRs) could, at least in theory, transform the ALT format into > whatever the ETR wants. Using the destination address as an EID is not an ALT specific requirement. In an enterprise, ala LISP variant 1.0, Map-Requests will be sent in the default VRF. When you don't have a routing table size problem, EIDs could be routable in such environments. I also see that an ALT that runs a DHT will cause a routing table to be built where the key is an EID to a standard routing table. A DHT can be just like any other routing protocol. > In practice, I think that changing the map request or map response > format is going to be extremely difficult under either model. But > if I had to pick one that I thought might be upgradeable, it would > be an approach with MR and MS as active components rather than > merely relays. If you change the Map-Request format, we have 3 options: o Create a new LISP type. o Create a new UDP port number. o Use versioning. And in all cases, the xTRs will have to change. Rather than trying to dominate a design to keep changing the protocol, maybe we should build version 1 that works first. Dino From dino@cisco.com Tue Sep 22 12: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 142533A6809 for ; Tue, 22 Sep 2009 12:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 oDgulx7GqzXp for ; Tue, 22 Sep 2009 12:34:44 -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 E08E53A6359 for ; Tue, 22 Sep 2009 12:34:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADvEuEqrR7MV/2dsb2JhbAC/QohPAZAhBYQb X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="245351653" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 22 Sep 2009 19:35:48 +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 n8MJZmCP011448; Tue, 22 Sep 2009 12:35:48 -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 n8MJZmHq007267; Tue, 22 Sep 2009 19:35:48 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, 22 Sep 2009 12:35:48 -0700 Received: from dhcp-171-70-249-6.cisco.com ([171.70.249.6]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 12:35:47 -0700 Message-Id: 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 v936) Date: Tue, 22 Sep 2009 12:35:47 -0700 References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 19:35:47.0590 (UTC) FILETIME=[E2593260:01CA3BBB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3114; t=1253648148; x=1254512148; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=mus6+R2/poamy0ncG0Z6nYWCPIxvdu+1vHBqo2m/BeQ=; b=b3wZ9Fu8XpBo4RA80Ga6I4ssJhnO7vI6TIx3o3Fkmod2lo8E8XjPDaKHki 87T66pJtF20B2n/qUNSRKJ6Tmbva+RQgBnKRCMj7rGqKePvsPce0KqzivkTJ gL2KDK4bo63qAu6XVBQXgfHMjJCXwttIfYh7Q0la+HOT0jcA5jb9U=; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 19:34:45 -0000 > On Sep 22, 2009, at 1:03 PM, Dino Farinacci wrote: >> >> Today an MR/NS is really simple. It just decaps and encaps and >> looks up packets in a routing table. It really doesn't have to run >> any LISP actually. It can be a product from a vendor that wants to >> sell infrastructure but not do the entire LISP spec. > > Your current perception of the MR and MS as BGP routers is > understandable, given the nature of the ALT. > However, that isn't guaranteed to be a constant for LISP. The > constant will be that the MR and MS Nothing is guaranteed but ALT is *likely* to stick. It should be clear once the benefits are understood. > provide a mapping service to their clients (ITRs and ETRs). > Ideally, the interface to the mapping service should remain > constant, even if the underlying mapping system changes. So, it > doesn't make architectural sense for an ITR to build an encapsulated > ALT mapping packet and send it to the MR. And it does. The fact that an EID is a destination address does not make the xTRs think the database is of a certain type. > I also don't think it is realistic that the MR/MS will remain as > simple as you describe, nor do I believe that it is possible (or > even desirable) for the MR or the MS to have no LISP-specific code. Well let's not make them complicated on purpose. If we have a real need to make them do more, we add it at that time, with compelling benefits. What Joel proposes is just not different enough from a functionality point of view. And we will lose features that I have already outlined in previous emails today. > ITRs register with Map Servers, so obviously Map Servers will have > LISP-specific code to process and No they don't. ETRs register to Map-Servers. > maintain those registrations. Map Servers also need authentication > information configured for each of the ITRs they serve, etc. Map-Servers process Map-Registers period. The way they authenticate and what features they do depends on the implementation. > There are also likely to be a number of anti-spoofing requirements > for the mapping system that go well beyond the need to read the EID > from the request. For example, the mapping system (at one end or the Like what? > other) will have to check the contents of the "Map Reply Record" if > one is included in the Map Request, to ensure that the mapping > information in that reply is accurate, and that it is consistent > with the That is going to take a lot of complicated protocol machinery. > source RLOC(s) included in the outer header(s). We may also have to > do something to authenticate the map replies, which will almost > certainly involve processing the contents bytes of the reply > packet. It That is going to take a lot of complicated protocol machinery. > might, for example, involve verifying the reply, hashing the > contents of the reply, and signing the reply with a certificate... That is going to take a lot of complicated protocol machinery. Dino From mrw@sandstorm.net Tue Sep 22 12:55: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 D87AF3A6978 for ; Tue, 22 Sep 2009 12:55:26 -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 Xwu8X8nlWr43 for ; Tue, 22 Sep 2009 12:55:26 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id CB1123A693A for ; Tue, 22 Sep 2009 12:55:24 -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 n8MJss7A071913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2009 15:54:54 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <117AC316-9CEF-40ED-A67C-5B3E1EC8881B@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 v936) Date: Tue, 22 Sep 2009 15:54:53 -0400 References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 19:55:27 -0000 On Sep 22, 2009, at 3:35 PM, Dino Farinacci wrote: > >> ITRs register with Map Servers, so obviously Map Servers will have >> LISP-specific code to process and > > No they don't. ETRs register to Map-Servers. You are right, of course. I am still struggling with some of the LISP terminology. I apologize. > >> maintain those registrations. Map Servers also need >> authentication information configured for each of the ITRs they >> serve, etc. > > Map-Servers process Map-Registers period. The way they authenticate > and what features they do depends on the implementation. It is my understanding that Map-Register messages will include authentication information that has to be checked by the Map-Server. In LISP -04, Map Servers are required to implement IPsec AH and to have pre-shared keys with all of the ETRs from whom they accept registrations. I realize that we may change to a different security mechanism at some point, but the need for security processing and some sort of credentials for each registering ETR (and/or for each registered EID prefix) won't go away. > >> There are also likely to be a number of anti-spoofing requirements >> for the mapping system that go well beyond the need to read the EID >> from the request. For example, the mapping system (at one end or the > > Like what? > >> other) will have to check the contents of the "Map Reply Record" if >> one is included in the Map Request, to ensure that the mapping >> information in that reply is accurate, and that it is consistent >> with the > > That is going to take a lot of complicated protocol machinery. > >> source RLOC(s) included in the outer header(s). We may also have >> to do something to authenticate the map replies, which will almost >> certainly involve processing the contents bytes of the reply >> packet. It > > That is going to take a lot of complicated protocol machinery. > >> might, for example, involve verifying the reply, hashing the >> contents of the reply, and signing the reply with a certificate... > > That is going to take a lot of complicated protocol machinery. Exactly. So, there will need to be some complicated LISP-specific protocol machinery in the mapping system, whether we have the xTRs handle encapsulated Map-Requests or not... The LISP mapping system needs to provide some form of protection against spoofed address mapping, in order for LISP to be operationally deployable. I understand that it doesn't do this now, but it needs to be added. If that's inconsistent with your current architectural model for the mapping system, then the architectural model has to change. The requirement for a reasonably secure mapping system isn't going to go away just because it requires "complicated protocol machinery". Margaret From dino@cisco.com Tue Sep 22 14:13: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 8315A3A6AFB for ; Tue, 22 Sep 2009 14:13:26 -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 hvEXWhH3JC4G for ; Tue, 22 Sep 2009 14:13:25 -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 4EA8B3A6862 for ; Tue, 22 Sep 2009 14:13:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPfauEqrR7O6/2dsb2JhbAC+UYhPAZAdBYQb X-IronPort-AV: E=Sophos;i="4.44,433,1249257600"; d="scan'208";a="393935859" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 22 Sep 2009 21:14:30 +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 n8MLETYT011615; Tue, 22 Sep 2009 14:14:30 -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 n8MLETwj006039; Tue, 22 Sep 2009 21:14:29 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, 22 Sep 2009 14:14:29 -0700 Received: from dhcp-171-70-249-6.cisco.com ([171.70.249.6]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 14:14:29 -0700 Message-Id: <23B96C35-4220-44E9-AB5F-0C38B0017AF3@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <117AC316-9CEF-40ED-A67C-5B3E1EC8881B@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, 22 Sep 2009 14:14:28 -0700 References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> <117AC316-9CEF-40ED-A67C-5B3E1EC8881B@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 21:14:29.0387 (UTC) FILETIME=[AC03B5B0:01CA3BC9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3425; t=1253654070; x=1254518070; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=xv/T5G5B6FfR2yyKQHQl/iT3Hu0T7Zr/juS6zFHPnyY=; b=KVaPfG5GXm/X2JjkRi767lkypR8b+JxCl7gro5sjyeosJcrPWwJFbdlvQW Epp8bUEI+DkUQdTAlrTdv54dTRpTRmdmS1lAhH+PsNkPSWkU71axfTq25+qD p9iqM8/8pm; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 21:13:26 -0000 > On Sep 22, 2009, at 3:35 PM, Dino Farinacci wrote: >> >>> ITRs register with Map Servers, so obviously Map Servers will have >>> LISP-specific code to process and >> >> No they don't. ETRs register to Map-Servers. > > You are right, of course. I am still struggling with some of the > LISP terminology. I apologize. >> >>> maintain those registrations. Map Servers also need >>> authentication information configured for each of the ITRs they >>> serve, etc. >> >> Map-Servers process Map-Registers period. The way they authenticate >> and what features they do depends on the implementation. > > It is my understanding that Map-Register messages will include > authentication information that has to be checked by the Map- > Server. In LISP -04, Map Servers are required to implement IPsec AH > and to have pre-shared keys with all of the ETRs from whom they > accept registrations. I realize that we may change to a different > security mechanism at some point, but the need for security > processing and some sort of credentials for each registering ETR > (and/or for each registered EID prefix) won't go away. Using AH or using authentication imbedded in the Map-Register doesn't change that a Map-Register needs to be parsed. >>> There are also likely to be a number of anti-spoofing requirements >>> for the mapping system that go well beyond the need to read the >>> EID from the request. For example, the mapping system (at one end >>> or the >> >> Like what? >> >>> other) will have to check the contents of the "Map Reply Record" >>> if one is included in the Map Request, to ensure that the mapping >>> information in that reply is accurate, and that it is consistent >>> with the >> >> That is going to take a lot of complicated protocol machinery. >> >>> source RLOC(s) included in the outer header(s). We may also have >>> to do something to authenticate the map replies, which will almost >>> certainly involve processing the contents bytes of the reply >>> packet. It >> >> That is going to take a lot of complicated protocol machinery. >> >>> might, for example, involve verifying the reply, hashing the >>> contents of the reply, and signing the reply with a certificate... >> >> That is going to take a lot of complicated protocol machinery. > > Exactly. So, there will need to be some complicated LISP-specific > protocol machinery in the mapping system, whether we have the xTRs > handle encapsulated Map-Requests or not... My point is that we should question complicated mechanisms to judge if the benefits are compelling for the cost. > The LISP mapping system needs to provide some form of protection > against spoofed address mapping, in I think the mechanisms we already have are pretty good when you compare the features with the cost of the mechanism. > order for LISP to be operationally deployable. I understand that it > doesn't do this now, but it needs to be added. If that's > inconsistent with your current architectural model for the mapping > system, then the architectural model has to change. The requirement > for a reasonably secure mapping system isn't going to go away just > because it requires "complicated protocol machinery". It all comes down to the value of variable "reasonable". Dino > > Margaret > > From vaf@cisco.com Tue Sep 22 14:56: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 1BB4C3A6AD4 for ; Tue, 22 Sep 2009 14:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 9cVPqbgOqLhi for ; Tue, 22 Sep 2009 14:56: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 D7E913A6AAB for ; Tue, 22 Sep 2009 14:56:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIPluEqrR7MV/2dsb2JhbAC+R4hPAZAcBYQb X-IronPort-AV: E=Sophos;i="4.44,433,1249257600"; d="scan'208";a="393963923" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Sep 2009 21:57:32 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8MLvXGd015727; Tue, 22 Sep 2009 14:57:33 -0700 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n8MLvXcL009741; Tue, 22 Sep 2009 21:57:33 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 n8MLo5Mj010081; Tue, 22 Sep 2009 14:50:05 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n8MLo5lO010078; Tue, 22 Sep 2009 14:50:05 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Tue, 22 Sep 2009 14:50:05 -0700 From: Vince Fuller To: "Joel M. Halpern" Message-ID: <20090922215005.GA7034@vaf-lnx1> References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> <4AB90520.60903@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AB90520.60903@joelhalpern.com> User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2818; t=1253656653; x=1254520653; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=0A=09Requests |Sender:=20; bh=JxxGsedUhcK84xfWlEKiw9AVTy0zboGvnXDJB8SFRAI=; b=fM9LLjL8X/rYSiw5+8INUoqqvWCEsRpMXe5E7AeDZYFs+d+bPGVzl5OSN8 ULfCfE5ndlzk3XzJKfxSKrfROSjDDAdOsqAi/j8vt3LTZit+V8X1yTA3chLa qQgTqnmbpovB3J22ok/KaBM4Fmap3sFRt6cSJ/FREpqNLMRFjxwFo=; Authentication-Results: sj-dkim-1; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 21:56:30 -0000 On Tue, Sep 22, 2009 at 01:10:56PM -0400, Joel M. Halpern wrote: > Yes, I want the MS and MR to do the work of isolating the ITR/ETR from > the details of the format used by the ALT. Yes, that means the MS / MR > are more than just relay nodes. So be it. > There are presumably a lot more ITRs and ETRs than there are MS and MR, > so I would prefer that the MS / MR pay the code complexity cost. The > request (yes I used Map-Query when I should have said Map-Request. > Sorry.) rates are presumably going to be low enough that this is quite > doable. Frankly, I had not even realized when I read the original map > server draft that you intended them to be pure relay agents. I had > thought that their purpose was isolation and versatility. Hi Joel- Thanks for writing this and other notes in this thread. I agree that your approach would allow a more clean separation between the service interface used by ETRs/ITRs and the mapping database system that is currently built using ALT. From a design and architectural abstraction point of view, I can certainly see the appeal of clearly isolating any dependencies on the ALT within Map-Servers and Map-Resolvers. On the other hand, defining a mechanism for an MR to receive a "raw" Map-Request from an ITR then generate a new Map-Request on to the ALT and have an MS reverse the process to propagate the Map-Request to an ETR will require substantially greater changes to the specifications. A few other disadvantages that also come to mind include: 1) needing to store additional state in the MRs and MSs, 2) loss of information that is useful for debugging Map-Request processing, 3) loss of information that is potentially useful for future end-to-end security associations. I suspect that my co-authors and others may have additional thoughts to offer. My goal in proposing the solution that I outlined last night was to make minor changes to the existing design to solve two clearly-identified problems, namely, the difficulty in separating data and control messages and the potential for user data packets to be mis-interpreted as control messages; both of these were consequences of using UDP port 4341 for encapsulated control messages. While I definitely welcome the larger design discussion that you have opened, I believe it is a bit out of scope for the specific problem that we are trying to fix with the existing specifications. Can we agree to fix this problem while we continue discussing the larger issue of improving the design of the service interface? Remember that the LISP drafts are all Experimental; the specific problem we are trying to fix has the potential to delay implementation and experimentation, something I think we all would like to avoid. Thanks, --Vince From hartmans@mit.edu Tue Sep 22 16:03: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 B83C03A68D8 for ; Tue, 22 Sep 2009 16:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 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 IUbnLn-2Lli1 for ; Tue, 22 Sep 2009 16:03: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 DA51F3A683D for ; Tue, 22 Sep 2009 16:03:33 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1EFF5413E; Tue, 22 Sep 2009 19:04:34 -0400 (EDT) To: Margaret Wasserman References: <20090922042637.GA14702@vaf-lnx1> <1FA4E6A1-946B-4451-B87A-1CE28A3DCC32@cisco.com> <034F0113-E208-4F4B-B9E9-FC0FEB1EE88F@cisco.com> <578ABB19-71C0-4348-9344-9BC84DF406A2@sandstorm.net> From: Sam Hartman Date: Tue, 22 Sep 2009 19:04:34 -0400 In-Reply-To: <578ABB19-71C0-4348-9344-9BC84DF406A2@sandstorm.net> (Margaret Wasserman's message of "Tue\, 22 Sep 2009 13\:02\:44 -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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 23:03:34 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> On Sep 22, 2009, at 12:37 PM, Dino Farinacci wrote: >> >> than just sending the inner map request as Margaret, Joel and I >>> originally suggested. I'm definitely happy with that original >>> approach as well. >> >> So, can you briefly summarize Margaret's proposal. Margaret> I don't really have a proposal. I agreed with Joel's Margaret> proposal (in response to Sam's original message) that we Margaret> should use unencapsulated packets for all xTR <=> Map Margaret> Resolver/Server communication, including Map-Requests. Margaret> So, we'd just send a Map-Request message in a single set Margaret> of IP/UDP headers from one of the ITR's RLOCs to a Margaret> configured Map Resolver. Joel went on to point out that all the information you need--the source RLOC, the source EID, the destination EID--is all already in the map request packet. Margaret> If the ITR has more than one Margaret> RLOC at which it could receive a reply (such as an RLOC Margaret> from a different address family, or RLOCs with different Margaret> reachability properties), it could include that This dosen't work and was not part of Joel's proposal. The problem is that the reply record includes entries for all the ETRs for the domain, not for the current ITR. 1) The ITR may not be an ETR 2) There may be additional ETRs. Currently, neither the current map request nor Joel's proposal supports including multiple source RLOCs. From jmh@joelhalpern.com Tue Sep 22 16:10: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 CDF653A6A0C for ; Tue, 22 Sep 2009 16:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.045 X-Spam-Level: X-Spam-Status: No, score=-3.045 tagged_above=-999 required=5 tests=[AWL=-0.446, 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 DKZKW0Gvdju9 for ; Tue, 22 Sep 2009 16:10:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id ABB4C3A69E1 for ; Tue, 22 Sep 2009 16:10:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id BC67A3231747; Tue, 22 Sep 2009 16:11:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.1.12] (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 hgblob.tigertech.net (Postfix) with ESMTP id 4406C32317A1; Tue, 22 Sep 2009 16:11:55 -0700 (PDT) Message-ID: <4AB959B9.6040105@joelhalpern.com> Date: Tue, 22 Sep 2009 19:11:53 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Vince Fuller References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> <4AB90520.60903@joelhalpern.com> <20090922215005.GA7034@vaf-lnx1> In-Reply-To: <20090922215005.GA7034@vaf-lnx1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 23:10:52 -0000 Thanks Vince. I am not sure I understand what you are asking. If you are asking "can we start by putting the change you have proposed into the current draft?" then my answer is yes. Your proposal is an improvement and we can put it in this draft. If you are asking "can we approve this document for publication as an experimental RFC without resolving the larger design question?" then I think the answer is no. We have to decide before RFC publication what design we want. Given the state of the work, I do not think the size of the change to the spec is a particularly important dimension. The question is what the right approach is, not what the livable approach with the smallest change to the draft is. (Sorry, that sentence is probably overstated and probably sounds like I am implying ill will on your or Dino's part. I do not see any ill will or attempt to do something wrong. I just disagree about the priorities.) Yours, Joel Vince Fuller wrote: > On Tue, Sep 22, 2009 at 01:10:56PM -0400, Joel M. Halpern wrote: >> Yes, I want the MS and MR to do the work of isolating the ITR/ETR from >> the details of the format used by the ALT. Yes, that means the MS / MR >> are more than just relay nodes. So be it. >> There are presumably a lot more ITRs and ETRs than there are MS and MR, >> so I would prefer that the MS / MR pay the code complexity cost. The >> request (yes I used Map-Query when I should have said Map-Request. >> Sorry.) rates are presumably going to be low enough that this is quite >> doable. Frankly, I had not even realized when I read the original map >> server draft that you intended them to be pure relay agents. I had >> thought that their purpose was isolation and versatility. > > Hi Joel- > > Thanks for writing this and other notes in this thread. I agree that > your approach would allow a more clean separation between the service > interface used by ETRs/ITRs and the mapping database system that is > currently built using ALT. From a design and architectural abstraction > point of view, I can certainly see the appeal of clearly isolating any > dependencies on the ALT within Map-Servers and Map-Resolvers. > > On the other hand, defining a mechanism for an MR to receive a "raw" > Map-Request from an ITR then generate a new Map-Request on to the ALT > and have an MS reverse the process to propagate the Map-Request to an ETR > will require substantially greater changes to the specifications. A few > other disadvantages that also come to mind include: 1) needing to store > additional state in the MRs and MSs, 2) loss of information that is useful > for debugging Map-Request processing, 3) loss of information that is > potentially useful for future end-to-end security associations. I suspect > that my co-authors and others may have additional thoughts to offer. > > My goal in proposing the solution that I outlined last night was to make > minor changes to the existing design to solve two clearly-identified > problems, namely, the difficulty in separating data and control messages > and the potential for user data packets to be mis-interpreted as control > messages; both of these were consequences of using UDP port 4341 for > encapsulated control messages. > > While I definitely welcome the larger design discussion that you have > opened, I believe it is a bit out of scope for the specific problem that > we are trying to fix with the existing specifications. Can we agree to > fix this problem while we continue discussing the larger issue of improving > the design of the service interface? Remember that the LISP drafts are all > Experimental; the specific problem we are trying to fix has the potential > to delay implementation and experimentation, something I think we all would > like to avoid. > > Thanks, > --Vince > From hartmans@mit.edu Tue Sep 22 16:20: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 3F8D93A67ED for ; Tue, 22 Sep 2009 16:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_102=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 XEUiqR0IRkWO for ; Tue, 22 Sep 2009 16:20:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 0BC693A6403 for ; Tue, 22 Sep 2009 16:20:39 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7F75E413E; Tue, 22 Sep 2009 19:21:40 -0400 (EDT) To: Vince Fuller References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> <4AB90520.60903@joelhalpern.com> <20090922215005.GA7034@vaf-lnx1> From: Sam Hartman Date: Tue, 22 Sep 2009 19:21:40 -0400 In-Reply-To: <20090922215005.GA7034@vaf-lnx1> (Vince Fuller's message of "Tue\, 22 Sep 2009 14\:50\:05 -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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 23:20:41 -0000 Speaking as an individual. v> While I definitely welcome the larger design discussion that you have v> opened, I believe it is a bit out of scope for the specific problem that v> we are trying to fix with the existing specifications. No, as the one who opened the issue, I'm quite sure that I mentioned the fact that an ETR is forced to process UDP packets not destined to itself as one of the problems I cared about. So, that part of this is definitely in scope. It may not be part of what you chose to work on, but it is part of what I asked the editors and WG to consider. v> Can we agree to v> fix this problem while we continue discussing the larger issue of improving v> the design of the service interface As I stated this does not work for me. My critical problem is processing UDP packets not destined to one of my interfaces. So, no, I'm not OK with a solution that doesn't solve that problem. v> ? Remember that the LISP drafts are all v> Experimental; the specific problem we are trying to fix has the potential v> to delay implementation and experimentation, something I think we all would v> like to avoid. I think that receiving packets not destined for myself is a bigger implementation problem for me than the aspects of this that you did choose to work on. However I'm very confused about what this is delaying. I thought you already had an implementation of an MS and MR. I want to see this issue fixed reasonably soon because it will allow me to avoid certain implementation hacks and produce a better quality implementation. However, unlike #2, this issue is not blocking my testing. I think I have a work around. Is there someone else who has come forward and indicated this is delaying them? v> On the other hand, defining a mechanism for an MR to receive a "raw" v> Map-Request from an ITR then generate a new Map-Request on to the ALT v> and have an MS reverse the process to propagate the Map-Request to an ETR v> will require substantially greater changes to the specifications. Can you elaborate on this point? It's not obvious to me why it's significantly more complicated than saying that the MR changes the outer header, and the MS does the same. You'd need to go through both for the packet generated by the MR and MS and explain what the source IP, dest IP, source UDP port, and dest UDP port would be. That doesn't seem to bad too me. What am I missing? v> A few v> other disadvantages that also come to mind include: 1) needing to store v> additional state in the MRs and MSs, I'm sorry but I don't see what additional state is needed. Please elaborate. v> 2) loss of information that is useful v> for debugging Map-Request processing, What information is lost? As far as I can tell, the only information that is lost is the EID in the inner packet. However that's duplicated in the map request itself. If the source IP in the inner packet differs from the source IP in the outer packet, that is also lost, but I don't see that as a big deal--it's a bug. What am I missing? v> 3) loss of information that is v> potentially useful for future end-to-end security associations. What information that is lost would be useful for end-to-end security associations? In the future, please answer these sorts of questions when you bring up arguments about increased debugging complexity, increased spec complexity,or security problems. If you're going to say that something makes these worse, give an example. I realize this was not your intent, but if you don't answer that question it comes across as if you are just trying to spread FUD. From dino@cisco.com Tue Sep 22 16:40: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 421083A67AE for ; Tue, 22 Sep 2009 16:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 tpKbj+vAPbHW for ; Tue, 22 Sep 2009 16:40:23 -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 7B95F3A6403 for ; Tue, 22 Sep 2009 16:40:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPP8uEqrR7MV/2dsb2JhbAC9dohPAZAcBYQbgV0 X-IronPort-AV: E=Sophos;i="4.44,433,1249257600"; d="scan'208";a="394025687" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Sep 2009 23:41:26 +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 n8MNfSlb024455; Tue, 22 Sep 2009 16:41:28 -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 n8MNfSga014111; Tue, 22 Sep 2009 23:41:28 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, 22 Sep 2009 16:41:28 -0700 Received: from dhcp-171-70-249-6.cisco.com ([171.70.249.6]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 16:41:27 -0700 Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4AB959B9.6040105@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, 22 Sep 2009 16:41:27 -0700 References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> <4AB90520.60903@joelhalpern.com> <20090922215005.GA7034@vaf-lnx1> <4AB959B9.6040105@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Sep 2009 23:41:27.0549 (UTC) FILETIME=[340C72D0:01CA3BDE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1888; t=1253662888; x=1254526888; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=7icC/A1tXYcNZcXe0vvADA0dkujStpu3ZHUqN3bLbh4=; b=kJ9BSdLqgQXkGrpfB3lS5L85Fm9dj6h5/4xftIbrG6+8blAU3M1GgD6RjX Mw7aobZwHtB/Z6GJsn6R2/ydzkBa3K0iK7QJYnvHaQ/Uwrr1QLrcd8RT8gEr RxIKY0/P14cZvd/TG362GLBUNJWmf/4h2QYQlP+SxphbhwSglT9ss=; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 22 Sep 2009 23:40:26 -0000 > Given the state of the work, I do not think the size of the change > to the spec is a particularly important dimension. The question is > what the right approach is, not what the livable approach with the > smallest change to the draft is. (Sorry, that sentence is probably > overstated and probably sounds like I am implying ill will on your > or Dino's part. I do not see any ill will or attempt to do something > wrong. I just disagree about the priorities.) What's your opinion about changing implementations? Encap/decap on the MR and MS is a huge implementation change and at this point. We don't know what will break. There are a lot of features that won't work on the test network. Unless, we get a very detailed design, we can't evaluate the new proposal. You would have to detail out: o How you won't break LISP variant 1.0. o How you won't break mix-AF support. o How you won't break lig. o How you won't break traceroute on the ALT network. o How you don't break ALT attached xTRs. o How IPv4 Map-Replies can be returned for IPv6 Map-Requests. o How map-resolver and map-server caching will be dealt with. o ICMP unreachables now can be delivered to the requesting ITR. Now they will be delivered to the encapsulating MR. The MR will have to cache Map-Requests. We have 3 implementations going now and maybe more coming soon. And those 3 implementations don't interoperate now and we need them to so we can learn about what's already in the specs. That is, we don't have enough data indicating what we have is bad. But we do have data on what features we have working. I would prefer that we use your brain cycles on more critical issues like updating map-caches on ITRs when ETRs change their mappings. As well as thinking about LISP network component placement for scalability. IMHO, Dino From vaf@cisco.com Tue Sep 22 17:23: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 4C2BC3A68F8 for ; Tue, 22 Sep 2009 17:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Tp5D9CSELiXw for ; Tue, 22 Sep 2009 17:23:04 -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 1DA6C3A67AC for ; Tue, 22 Sep 2009 17:23:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEQHuUqrR7O6/2dsb2JhbAC+EYhPAZAiBYQbimQ X-IronPort-AV: E=Sophos;i="4.44,434,1249257600"; d="scan'208";a="207232180" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 23 Sep 2009 00:24:09 +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 n8N0O9Z0028781; Tue, 22 Sep 2009 17:24:09 -0700 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8N0O8iV014328; Wed, 23 Sep 2009 00:24:08 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 n8N0Getx018353; Tue, 22 Sep 2009 17:16:40 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n8N0GeKn018350; Tue, 22 Sep 2009 17:16:40 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Tue, 22 Sep 2009 17:16:40 -0700 From: Vince Fuller To: Sam Hartman Message-ID: <20090923001640.GA17281@vaf-lnx1> References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> <4AB90520.60903@joelhalpern.com> <20090922215005.GA7034@vaf-lnx1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2390; t=1253665449; x=1254529449; c=relaxed/simple; s=sjdkim2002; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=0A=09Requests |Sender:=20; bh=UBYSC6c/rwHmIvkr892xiZp5e2E9xoGUYRHEETtNN08=; b=B3TtSVDLS/xqwWaa95U+LUIpA1Lkq0oRsl7P2C4SiDbGhhmret6lpZEuJv gtPgT2Wb1yB1W5V5o037pP/P7tJLRYf0g0U35ZDgyHyEUVFR1VewqcO8PZpS FjliW+GWT+; Authentication-Results: sj-dkim-2; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 00:23:05 -0000 > No, as the one who opened the issue, I'm quite sure that I mentioned > the fact that an ETR is forced to process UDP packets not destined to > itself as one of the problems I cared about. So, that part of this is > definitely in scope. > It may not be part of what you chose to work on, but it is part of what I > asked the editors and WG to consider. No, your issue with "an ETR is forced to process UDP packets not destined to itself" is outside the scope of the specific problem in #22 and the specific changes that we have proposed. > As I stated this does not work for me. My critical problem is > processing UDP packets not destined to one of my interfaces. So, no, > I'm not OK with a solution that doesn't solve that problem. This sounds like an implementation problem not a design problem. LISP+ALT has, from the beginning, specified a mechanism that requires ETRs to accept and process Map-Requests that are destined to their owning EID prefixes but not to a specific IP address configured on a local interface. If you consider that behavior to be a problem then it should be tracked as a separate issue. > I think that receiving packets not destined for myself is a bigger > implementation problem for me than the aspects of this that you did > choose to work on. Others have successfully implemented this behavior which suggests that it is not a fundamental problem. In any case, it is unrelated to the issue of UDP port 4341 being used for both control and data packets and should be addressed separately. > However I'm very confused about what this is delaying. > I thought you already had an implementation of an MS and MR. > I want to see this issue fixed reasonably soon because it will allow me to > avoid certain implementation hacks and produce a better quality > implementation. We do have implementations of MS, MR, and the required Encapsulated Map Request processing on ITRs and ETRs. We have discovered through testing those imlementations that Map-Request processing efficiency will be poor and that deployment on an operational network will be problematic as long as UDP port 4341 is used for both user data packets and Encapsulated Map Requests. The changes that I described in my earlier message are intended to fix that specific problem not to change the design of MS/MR functionality. --Vince From trac@tools.ietf.org Tue Sep 22 17: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 A668E3A6827 for ; Tue, 22 Sep 2009 17:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.046, 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 D7+gH2B-t-tv for ; Tue, 22 Sep 2009 17:31:16 -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 91D0A3A67AC for ; Tue, 22 Sep 2009 17:31:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MqFmO-0002pK-Jh; Tue, 22 Sep 2009 17:32:20 -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: Wed, 23 Sep 2009 00:32:20 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/23 Message-ID: <060.5ae30f807b9da31e01375a39e603e0c9@tools.ietf.org> X-Trac-Ticket-ID: 23 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] #23: inner source RLOC undefined in some cases 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: Wed, 23 Sep 2009 00:31:17 -0000 #23: inner source RLOC undefined in some cases ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@mit.edu | Owner: Type: technical | Status: new Priority: minor | Component: ms Severity: - | Keywords: ----------------------------------+----------------------------------------- I am constructing the inner packet of a map request either because I'm directly connected to the alt or because I'm going to send an outer packet to the MR. I need to construct a packet as the same IP version as the destination EID I'm sending to. It is undefined what RLOC I use for the source IP address in the inner header if I have no RLOC of that address family. For example I have v4 RLOCs and am sending to a v6 eid. It's undefined what RLOC I should use in the inner header. We should specify this. Except for receiving ICMP errors generated on the alt, it probably doesn't matter much, but it is a deficiency in the spec. -- Ticket URL: lisp LISP WG document issues From dino@cisco.com Tue Sep 22 17:37: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 9A7AB3A68FB for ; Tue, 22 Sep 2009 17:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 8Usc7vutBw4a for ; Tue, 22 Sep 2009 17:37:47 -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 8A0C73A68DD for ; Tue, 22 Sep 2009 17:37:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMcKuUqrR7MV/2dsb2JhbAC+C4hPAZAhBYQbgV0 X-IronPort-AV: E=Sophos;i="4.44,434,1249257600"; d="scan'208";a="207234110" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 23 Sep 2009 00:38:52 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8N0cpSu029847; Tue, 22 Sep 2009 17:38:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n8N0cpPa003315; Wed, 23 Sep 2009 00:38:51 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, 22 Sep 2009 17:38:51 -0700 Received: from dhcp-171-70-249-6.cisco.com ([171.70.249.6]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 17:38:51 -0700 Message-Id: <8B0367F4-8853-4D7C-9CFC-9052E6524F1C@cisco.com> From: Dino Farinacci To: trac@localhost.amsl.com In-Reply-To: <060.5ae30f807b9da31e01375a39e603e0c9@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 v936) Date: Tue, 22 Sep 2009 17:38:51 -0700 References: <060.5ae30f807b9da31e01375a39e603e0c9@tools.ietf.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Sep 2009 00:38:51.0320 (UTC) FILETIME=[38B23380:01CA3BE6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1815; t=1253666331; x=1254530331; 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=20#23=3A=20inner=20source=20R LOC=20undefined=20in=20some=20cases |Sender:=20; bh=z64Vm0lxf0v7Wthzg/X9KZNsfKLTTgyOgPpBC+qk4K8=; b=lllSqCx+RezJ+C0MdRiKo72QSzmKjiywBBzNPfpeoBd9XuPutVum5VnuXS cTFJiDHDxhyVZCD+y3rrXUu3pK08s+9xprbe+wnqpyT3LE9brWJvTqjo9NVG 0NKOuRp1ztQo1gAZEeSMfBf1SOBOlmoV1xOYLI3GIv0/HHTzLxM78=; 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] #23: inner source RLOC undefined in some cases X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 00:37:48 -0000 I don't think this should be an issue. It is a misconfiguration if you choose to want to encapsulate in a packet with an address family you don't have a address assigned to. This is no different than say you telnet to an IPv4 host and you have no IPv4 address assigned. It should be left up to the implementation to decide to do. Dino On Sep 22, 2009, at 5:32 PM, lisp issue tracker wrote: > #23: inner source RLOC undefined in some cases > ---------------------------------- > +----------------------------------------- > Reporter: hartmans-ietf@mit.edu | Owner: > Type: technical | Status: new > Priority: minor | Component: ms > Severity: - | Keywords: > ---------------------------------- > +----------------------------------------- > I am constructing the inner packet of a map request either because I'm > directly connected to the alt or because I'm going to send an outer > packet to the MR. > > I need to construct a packet as the same IP version as the destination > EID I'm sending to. > > It is undefined what RLOC I use for the source IP address in the inner > header if I have no RLOC of that address family. > > For example I have v4 RLOCs and am sending to a v6 eid. It's > undefined what RLOC I should use in the inner header. > > We should specify this. Except for receiving ICMP errors generated > on the > alt, it probably doesn't matter much, but it is a deficiency in the > spec. > > -- > Ticket URL: > lisp > LISP WG document issues > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Tue Sep 22 17:53: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 4BB5B3A6A47 for ; Tue, 22 Sep 2009 17:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 SKX5b6xd9xNT for ; Tue, 22 Sep 2009 17:53:23 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 5D9433A68FC for ; Tue, 22 Sep 2009 17:53:23 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 05F336BE55B; Tue, 22 Sep 2009 20:54:26 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090923005427.05F336BE55B@mercury.lcs.mit.edu> Date: Tue, 22 Sep 2009 20:54:26 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 00:53:24 -0000 > From: Vince Fuller > the issue of UDP port 4341 being used for both control and data packets > ... > We have discovered through testing those imlementations that > Map-Request processing efficiency will be poor and that deployment on > an operational network will be problematic as long as UDP port 4341 is > used for both user data packets and Encapsulated Map Requests. The > changes that I described in my earlier message are intended to fix that > specific problem >From what I've seen, nobody has a problem with that change. Maybe we should focus on that for the moment, and get agreement on that, so that change can go in -05 (or -06, I forget which one we're on now)? I am happy with the change to stop using Data packets to encapsulate Control packets Noel From hartmans@mit.edu Tue Sep 22 18:04: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 EC7653A694C for ; Tue, 22 Sep 2009 18:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 XjVGHsMuGGau for ; Tue, 22 Sep 2009 18:04:11 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id DCDC83A68FC for ; Tue, 22 Sep 2009 18:04:10 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2761E413E; Tue, 22 Sep 2009 21:05:11 -0400 (EDT) To: Dino Farinacci References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> <4AB90520.60903@joelhalpern.com> <20090922215005.GA7034@vaf-lnx1> <4AB959B9.6040105@joelhalpern.com> From: Sam Hartman Date: Tue, 22 Sep 2009 21:05:11 -0400 In-Reply-To: (Dino Farinacci's message of "Tue\, 22 Sep 2009 16\:41\:27 -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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 01:04:13 -0000 >>>>> "Dino" == Dino Farinacci writes: >> Given the state of the work, I do not think the size of the change >> to the spec is a particularly important dimension. The question is >> what the right approach is, not what the livable approach with the >> smallest change to the draft is. (Sorry, that sentence is probably >> overstated and probably sounds like I am implying ill will on your >> or Dino's part. I do not see any ill will or attempt to do something >> wrong. I just disagree about the priorities.) Dino> You would have to detail out: OK. So, first let me detail changes to the map request. We add a second source RLOC field so that an ITR can include two source RLOCs from different address families. It's my understanding that today in the cross-AFI case, I'll include one RLOC in the IP header and may include an RLOC of the opposite address family in the source RLOC field of the map request. We need to include two RLOCs in the map request. An alternate design would be to have the MR and MS swap the RLOCs if they swap address families of the outer header. I prefer to include two RLOCs in a map request because the behavior of the MR and MS is simpler. Encapsulation behavior: I have a map request. I'm an MS or an ITR and I want to produce a packet suitable for sending over the RLOC internet. I have a destination RLOC I wish to send to. I search the map request packet. If there is no source RLOC in the map request packet of the destination RLOC AFI, I will use one of my RLOCs. I construct an IP header using the source RLOC I just selected as the IP address, the destination RLOC that is an input to the encapsulation procedure as the destination. Inside this is a UDP header. I select a valid ephemeral port as the source port and the destination port of 4342. An encapsulator MAY choose to always use their own source RLOC . The reason for allowing this is to support map servers that have URPF that prevent them from using the ITR's RLOC. That probably decreases debugging success, but may be better than completely failing to work as an MS. Decapsulation procedure: I'm an MR. I've received the result of the encapsulation procedure. I wish to produce a packet for sending over the alt. I search the map request for an RLOC of the same AFI as the destination EID. If there is no such RLOC, I pick one of my own RLOCs. Picking my own RLOC is an arbitrary decision; there may be other decisions. As I mention in issue #23, this is already undefined in the current system. I needed to propose a specific fix to #23 in order to answer your questions below. I construct an IP packet of the version of the destination EID. The source address is the RLOC I've picked above--either the RLOC from the map request or the RLOC of the MR if no such RLOC exists. The destination IP address is the destination EID. The source UDP port can be the same as from the packet I received, if that helps debugging. ETR behavior: The ETR receives the map request. It generates a reply and sends it to UDP port 4342 on one of the source RLOCs read from the packet. This fails if the ETR and ITR do not share RLOCs in the same address family; so does the current procedure. Dino> o How you won't break LISP variant 1.0. I think LISP 1.0 is out of scope for this WG. If a particular implementation wants to support it, that's there business. However I don't think spending time on LISP 1.0 is something this WG should do. Dino> o How you won't break mix-AF support. The encapsulation procedure above always succeed. The map request packet itself is never modified by the encapsulation or decapsulation procedure. So, the ETR will receive the map request. If the ETR and ITR share a source RLOC AFI in common, then the ETR can respond. That's sufficient to argue that cross-AFI is not broken. Dino> o How you won't break lig. LIG generates a map request with either one or two source RLOC entries depending on what address families it supports. It follows the encapsulation procedure with the destination RLOC set to the RLOC of a map resolver. Dino> o How you won't break traceroute on the ALT network. The alt draft does not specify traceroute. If you would like to make a proposal that we support traceroute on the alt and give requirements for that, we can consider that as a WG. Until then, the WG has no obligation to break traceroute. However I'm reasonably sure that this will work or can be made to work with traceroute. Dino> o How you don't break ALT attached xTRs. Dino> o How IPv4 Map-Replies can be returned for IPv6 Map-Requests. Dino> o How map-resolver and map-server caching will be dealt with. Dino> o ICMP unreachables now can be delivered to the requesting ITR. Now Dino> they will be delivered to Dino> the encapsulating MR. The MR will have to cache Map-Requests. This is not true in my proposal. By caching things, an MR could deliver errors in more cases than it does otherwise, but I think without caching error handling is good.. Dino> We have 3 implementations going now and maybe more coming soon. And Dino> those 3 implementations don't interoperate now and we need them to so Dino> we can learn about what's already in the specs. The most important thing you can do to improve interoperability to use standard components consistent with their specs. we found problems with lig because LISP implementations had to use their own UDP stack because of this issue. Implementing LISP is harder because of this issue. We found problems with LISP implementations because LISP does not use IPsec as specified but instead diverges from the IPsec standards. I expect that every time we run into things where LISP just uses a header or packet type of some other protocol but does not use the semantics and does not allow integration with a normal implementation of that protocol, we'll find huge interoperability problems. I may not have as much experience implementing protocols as some people here, but I can say with very high confidence that improving use of existing protocols will significantly help your interoperability problem. --Sam with implementor hat on From hartmans@mit.edu Tue Sep 22 18:07: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 30E5D3A694C for ; Tue, 22 Sep 2009 18:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 N98Rb+QJFyun for ; Tue, 22 Sep 2009 18:07: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 5D7173A6935 for ; Tue, 22 Sep 2009 18:07:31 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3C488413E; Tue, 22 Sep 2009 21:08:32 -0400 (EDT) To: Dino Farinacci References: <060.5ae30f807b9da31e01375a39e603e0c9@tools.ietf.org> <8B0367F4-8853-4D7C-9CFC-9052E6524F1C@cisco.com> From: Sam Hartman Date: Tue, 22 Sep 2009 21:08:32 -0400 In-Reply-To: <8B0367F4-8853-4D7C-9CFC-9052E6524F1C@cisco.com> (Dino Farinacci's message of "Tue\, 22 Sep 2009 17\:38\:51 -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: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #23: inner source RLOC undefined in some cases X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 01:07:32 -0000 >>>>> "Dino" == Dino Farinacci writes: Dino> I don't think this should be an issue. It is a misconfiguration if you Dino> choose to want to encapsulate in a packet with an address family you Dino> don't have a address assigned to. No. I have v4 RLOCs and wish to send a packet to a V6 EID. If the ETR/ITR for that EID domain have V4 RLOCs as well this works. From hartmans@mit.edu Tue Sep 22 18:09: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 67B953A67FC for ; Tue, 22 Sep 2009 18:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 fvrZ7feD7qJs for ; Tue, 22 Sep 2009 18:09: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 6DB293A67F2 for ; Tue, 22 Sep 2009 18:09:33 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1AE85413E; Tue, 22 Sep 2009 21:10:34 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090923005427.05F336BE55B@mercury.lcs.mit.edu> From: Sam Hartman Date: Tue, 22 Sep 2009 21:10:34 -0400 In-Reply-To: <20090923005427.05F336BE55B@mercury.lcs.mit.edu> (Noel Chiappa's message of "Tue\, 22 Sep 2009 20\:54\:26 -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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 01:09:34 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Vince Fuller >> the issue of UDP port 4341 being used for both control and data packets >> ... >> We have discovered through testing those imlementations that >> Map-Request processing efficiency will be poor and that deployment on >> an operational network will be problematic as long as UDP port 4341 is >> used for both user data packets and Encapsulated Map Requests. The >> changes that I described in my earlier message are intended to fix that >> specific problem Noel> From what I've seen, nobody has a problem with that change. Maybe we should Noel> focus on that for the moment, and get agreement on that, so that change can go Noel> in -05 (or -06, I forget which one we're on now)? I'd rather wait until we have a complete solution to #22. I think it is very problematic to implement half fixes. It makes it very easy for the editors to block changes they don't like in a manner that makes the process much less open and fair. It removes a lot of the forcing functions for building consensus. From mrw@sandstorm.net Tue Sep 22 18:11: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 9F3D13A6879 for ; Tue, 22 Sep 2009 18:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.103, 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 1nST79p-Loji for ; Tue, 22 Sep 2009 18:11:29 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 8EB6B3A6AC4 for ; Tue, 22 Sep 2009 18:11:29 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8N1CULs087534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2009 21:12:30 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <94977312-C807-4A6B-891A-52049C08FF5A@sandstorm.net> From: Margaret Wasserman To: Vince Fuller In-Reply-To: <20090923001640.GA17281@vaf-lnx1> 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, 22 Sep 2009 21:12:29 -0400 References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> <4AB90520.60903@joelhalpern.com> <20090922215005.GA7034@vaf-lnx1> <20090923001640.GA17281@vaf-lnx1> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 01:11:30 -0000 Hi Vince, On Sep 22, 2009, at 8:16 PM, Vince Fuller wrote: > No, your issue with "an ETR is forced to process UDP packets not > destined > to itself" is outside the scope of the specific problem in #22 and the > specific changes that we have proposed. Have you read issue #22? It seems to me that it quite clearly includes "an ETR being required to process UDP packets not destined to itself". The text of the issue is here: http://trac.tools.ietf.org/wg/lisp/trac/ticket/22 In fact the sentence above that you claim is outside of this issue is almost exactly the same as the first sentence of the issue, itself... I agree that the changes that you have proposed do not fully address this issue. >> I think that receiving packets not destined for myself is a bigger >> implementation problem for me than the aspects of this that you did >> choose to work on. > > Others have successfully implemented this behavior which suggests > that it > is not a fundamental problem. Not necessarily. As far as I know, no one who claims to have successfuly implemented this has answered questions about how errors in these packets are detected and handled. > In any case, it is unrelated to the issue of UDP port 4341 being > used for > both control and data packets and should be addressed separately. I agree that these issue could be considered separately. So, perhaps you should open a new issue for this one, perhaps referencing issue #22 and making it clear how they differ? > > We do have implementations of MS, MR, and the required Encapsulated > Map > Request processing on ITRs and ETRs. We have discovered through > testing those > imlementations that Map-Request processing efficiency will be poor > and that > deployment on an operational network will be problematic as long as > UDP port > 4341 is used for both user data packets and Encapsulated Map > Requests. The > changes that I described in my earlier message are intended to fix > that > specific problem not to change the design of MS/MR functionality. I understand, and agree, that you have addressed that particular problem. As I indicated in an earlier message, however, the proposed change in the Map-Request encapsulation resolves other issues and has other advantages. Personally, I still support moving to Joel's proposal for unencapsulated Map-Requests. Margaret From jnc@mercury.lcs.mit.edu Tue Sep 22 18:26: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 608603A6A0C for ; Tue, 22 Sep 2009 18:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 lzFyfGpyp+zz for ; Tue, 22 Sep 2009 18:26: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 957B93A69A4 for ; Tue, 22 Sep 2009 18:26:05 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9E1306BE55B; Tue, 22 Sep 2009 21:27:09 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090923012709.9E1306BE55B@mercury.lcs.mit.edu> Date: Tue, 22 Sep 2009 21:27:09 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 01:26:06 -0000 > From: Sam Hartman > I'd rather wait until we have a complete solution to #22. I thought that's all there was in #22? What else does it cover? (Goes off to read the tracking page...) Noel From jnc@mercury.lcs.mit.edu Tue Sep 22 18:50: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 50FD03A66B4 for ; Tue, 22 Sep 2009 18:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 G90WaHHxLN4I for ; Tue, 22 Sep 2009 18:50:54 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 7E1033A63C9 for ; Tue, 22 Sep 2009 18:50:54 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0DBCE6BE55B; Tue, 22 Sep 2009 21:51:58 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090923015159.0DBCE6BE55B@mercury.lcs.mit.edu> Date: Tue, 22 Sep 2009 21:51:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 01:50:55 -0000 > From: Margaret Wasserman >> In any case, it is unrelated to the issue of UDP port 4341 being used >> for both control and data packets and should be addressed separately. > I agree that these issue could be considered separately. So, perhaps > you should open a new issue for this one, perhaps referencing issue #22 > and making it clear how they differ? I support doing this. Anything we can do to clear issues off the decks, making the remaining issues clearer, would be good. Noel From jnc@mercury.lcs.mit.edu Tue Sep 22 20:44: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 172D33A6869 for ; Tue, 22 Sep 2009 20:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 Z-nOHHOzDvLC for ; Tue, 22 Sep 2009 20:44:25 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 720EE3A684F for ; Tue, 22 Sep 2009 20:44:25 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B69876BE5D9; Tue, 22 Sep 2009 23:45:29 -0400 (EDT) To: bew@cisco.com, lisp@ietf.org Message-Id: <20090923034529.B69876BE5D9@mercury.lcs.mit.edu> Date: Tue, 22 Sep 2009 23:45:29 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] To IPsec or not IPsec (Issue #2)? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 03:44:27 -0000 > From: Brian Weis > "IPSec is not a good fit for this application." ... > All that seems wanted for the Map-Server is a packet integrity method > ... > Would there be support for replacing the use of AH with a simple > Authentication Data field in the Map-Register packet? Defining one or > more MACs and their usage for this protocol can be straightforward. Sounds good to me, although we might want to do something about replay. Maybe we could add a timestamp type field, and initial implementations could leave it blank -> no replay protection; later on we can add protocol mechanism (a packet exchange) to allow us to do that? > Key management would most certainly be restricted to manually shared > keys for now, but it can be automated if and when a generalized > automated key management method for routing is defined. Right, it's a logically separate protocol, so we can come along and add that later. (We can't do everything before everything else, we have to order things, and this seems like more of an O+M issue than something we have to solve Right Now to start field trials.) Noel From dino@cisco.com Tue Sep 22 21:07: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 7ADD83A682D for ; Tue, 22 Sep 2009 21:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 TM5F6NoGr8wF for ; Tue, 22 Sep 2009 21:07:58 -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 853153A6805 for ; Tue, 22 Sep 2009 21:07:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALM8uUqrR7O6/2dsb2JhbAC9OIhPAZAjBYQbgV2JBw X-IronPort-AV: E=Sophos;i="4.44,435,1249257600"; d="scan'208";a="191519611" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 23 Sep 2009 04:09:03 +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 n8N493Lq032216; Tue, 22 Sep 2009 21:09:03 -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 n8N493H7022838; Wed, 23 Sep 2009 04:09:03 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, 22 Sep 2009 21:09:03 -0700 Received: from [192.168.1.2] ([10.21.118.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 21:09:03 -0700 Message-Id: <427FA4FC-8917-4128-B5CB-42088D9854BE@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 v936) Date: Tue, 22 Sep 2009 21:09:02 -0700 References: <060.5ae30f807b9da31e01375a39e603e0c9@tools.ietf.org> <8B0367F4-8853-4D7C-9CFC-9052E6524F1C@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Sep 2009 04:09:03.0279 (UTC) FILETIME=[96026BF0:01CA3C03] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=733; t=1253678943; x=1254542943; 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]=20#23=3A=20inner=20source=20RLOC =20undefined=20in=20some=20cases |Sender:=20; bh=CGuft0mNcC2gtv1dsMJGarw5K4l0KylKvhaLFmqMLqY=; b=oJXGSqeYiTjEopm59NyI2jfL+BMorFiJ0Q37VQyjrYtYsrrX3byFXET/0u yR6RxTHjHkCkYWS8D4FcRIgpOpVA1oGKLamlpDvg8LHdR1hGCAQGHude/aOo xt2rMRMRQD; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #23: inner source RLOC undefined in some cases X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 04:07:59 -0000 >>>>>> >>>>>> "Dino" == Dino Farinacci writes: > > Dino> I don't think this should be an issue. It is a > misconfiguration if you > Dino> choose to want to encapsulate in a packet with an address > family you > Dino> don't have a address assigned to. > > No. I have v4 RLOCs and wish to send a packet to a V6 EID. If the > ETR/ITR for that EID domain have V4 RLOCs as well this works. Right, because you are encapsulating in IPv4. But if you encapsulate in IPv6, you need an IPv6 assigned locally to put in the source address field. If you do not, then you drop the packet (for the later case) due to misconfiguration. So what is your point. You are not being clear. Dnio From jzwiebel@cisco.com Tue Sep 22 21:11: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 A4D6C3A67F1 for ; Tue, 22 Sep 2009 21:11:46 -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=[AWL=-0.000, 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 RXlzKKgmgaqr for ; Tue, 22 Sep 2009 21:11:44 -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 E83E23A6805 for ; Tue, 22 Sep 2009 21:11:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroEACs9uUqrR7O6/2dsb2JhbACCJTC6YohPAZAjBYQbgV0 X-IronPort-AV: E=Sophos;i="4.44,435,1249257600"; d="scan'208,217";a="207261928" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 23 Sep 2009 04:12:49 +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 n8N4CnNP004131; Tue, 22 Sep 2009 21:12:49 -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 n8N4CmqG028117; Wed, 23 Sep 2009 04:12:49 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); Tue, 22 Sep 2009 21:12:48 -0700 Received: from [10.0.1.4] ([10.21.65.99]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 21:12:47 -0700 In-Reply-To: References: <20090922152710.4DB176BE553@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-89-494053628 Message-Id: From: John Zwiebel Date: Tue, 22 Sep 2009 18:12:40 -1000 To: Margaret Wasserman X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 23 Sep 2009 04:12:47.0842 (UTC) FILETIME=[1BDC0420:01CA3C04] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23412; t=1253679169; x=1254543169; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[lisp]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=aDY/J1TLkiZ9QwVMKBJkw2VD9oURvc35gZnBTj2NFOI=; b=O1w7SmM94L3sCDqmVCUiQgahAdAeLTpgS8H5jNO6/SbRxGEF+gCwALZYOT krk1JqrfF4Elcfu1TEPdTDnpsOnZy8agkTOA7RhRpgI01PKyfcTm4CVI6I5z 6+VGuLN/o2; Authentication-Results: sj-dkim-2; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 04:11:46 -0000 --Apple-Mail-89-494053628 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 22, 2009, at 5:47 AM, Margaret Wasserman wrote: > True, except you haven't explained why we need this header at all... We don't "need" it. There are many ways it could be done. This was the choice that was made based on experience with the systems LISP was being built on. It is an EXPERIMENT. > What if the ITR sent a simple question to the Map Resolver of the > form "What RLOC(s) should I use to reach this EID (or EID prefix)?". Because this requires an extra step that we don't want the ITR to have to deal with. The ITR wants to send map-requests one place, that's the map resolver. If your thought is that the map-resolver provides the RLOC of the ETR, the problem is that it (the MR) isn't "authoritative". The only one who really knows what EIDs it serves is the ETR itself. The current desire is to always get the latest information from the most authoritative source. If you have the intermediate step you have delay problems or attack problems. > But, that ALT-specific detail should remain hidden inside the > ALT, IMO. IMHO, (note I'm trying to be humble) it is. The fact that the ITR sends the control message to the MR first is just a simple way of injecting the map-request into the ALT. We used to have the ITR actually join the ALT, but then it had to run BGP over the ALT. It worked just fine, but the architects thought it could result in a larger BGP topology than they wanted. I agree. Changing the format of the message sent from the ITR to whatever mapping distribution system exists should be considered. But I believe the current EMR format could be used no matter what was substituted in. This is an experiment. > > The fact that that just bashing the address could work points out > why this type of encapsulation isn't needed at all. The EID for > the request is already in the Map Request itself, so there isn't > any need to include it in an encapsulated header. > You -may- be right that it isn't needed. It is just easier to do it this way. Its already done and it works. The decision to back up and start over isn't what I would think would fit into an "experiment" unless there is some overwhelming evidence that what already works isn't going to continue working. > What Vince has proposed does the exact _opposite_ of isolating the > xTRs from the mapping system, as they are required to build mapping- > system-specific requests (using EIDs as destination addresses) and > then encapsulate them to get them to the mapping system. This is extremely simple. Much, much easier than having to be a member of the ALT. In any case, its hard for me to imagine how it could be easier for the ITR to build the map-request. Seems to me that exactly the same information will have to be sent even if it is in a different format. > A system where we ask simple questions like "What RLOC(s) should I > (as an ITR) use to reach this EID (or EID prefix)?" and get simple > answers like "Use this/these RLOC(s) to reach this EID Prefix" over > a simple (unencapsulated) transport would actually _hide_ the > details of the mapping system from the xTRs. At the cost of throwing away tons of stuff that has already been implemented and proven to work, for absolutely no proven gain in functionality other than it appears to be cleaner. In your system the ITR sends a message to the map-resolver. In the current system the ITR sends a message to the map-resolver. They look pretty much identical to me. The only difference is the format of the bits. Joel brought up the question of debugging. As one who has had to look at tons and tons of these messages being forwarded, it is a whole lot easier to monitor the change of the external header keeping the inner packet exactly the same than it is to figure out if the control packet that came in generated the right control packet on the way out. In a different email margaret said: > Your current perception of the MR and MS as BGP routers is > understandable, given the nature of the ALT. However, that isn't > guaranteed to be a constant for LISP. True, but if I were to bet, I'd give 10 to 1 odds on the ALT. I've lost bets. I sold my Apple several months ago. (Oh well) And if something else were to be substituted in, I see no need to change the format of the messages sent from the ITR. You might change them, but you don't actually need to change them. In this thread, we're talking about whether or not it is easy for a given platform/OS to process the messages. While this is important in a final RFC, LISP is an experiment. It may not work at all. Or perhaps we're past that point? Is there actually a consensus that LISP will be deployed and will actually solve the problem? If so, then I back off completely. I guess the only way to know is to call for such a consensus. Any one want to say yes? (I'm not willing to go that far yet.) > So, it doesn't make architectural sense for an ITR to build an > encapsulated ALT mapping packet and send it to the MR. It does to me. Its easy to implement. It works. Its easy to debug. It makes as much sense as any other way I've seen proposed on this list so far. > I also don't think it is realistic that the MR/MS will remain as > simple as you describe, nor do I believe that it is possible (or > even desirable) for the MR or the MS to have no LISP-specific code. This is an argument without any basis. There are no alternate proposals that don't have LISP-specific code. I find it very hard to understand how a LISP map- request could be processed by any system that didn't have "LISP-specific code". Rather the ALT does -NOT- require LISP specific code. Seems like this meets your requirements. > ITRs register with Map Servers, ETRs register with map servers. > There are also likely to be a number of anti-spoofing requirements > for the mapping system that go well beyond the need to read the EID > from the request. This is suppose to be an experiment. The purpose of the experiment is to prove the viability of the LISP concept. If there are gross security problems in the LISP concept, to the extent that it becomes non-deployable, then you'd have an excellent point. But unless you can describe a spoof that -I- will easily understand, the claim for 'anti-spoofing' requirements is well beyond what I would consider to be an Experiment. Joel said: > If MR and MS nodes are pure relay, then in order to change the > format of a Map Query, as sent by an ITR, every ETR in the world > would have to have the upgraded software. > In contrast, MS could accept an alternative form, and transform it > to whatever the ALT handles. Actually the MR does the acceptance to send the request on to the ALT. > And MRs (which have registrations from ETRs) could, at least in > theory, transform the ALT format into whatever the ETR wants. ETRs register to the map-server. I totally agree that the MS can change the format to whatever. Therefore, what we have works. I don't see any reason to change it now. 6 of one 1/2 dozen of the other. ie whether the MR/MS just relays the request or actually formulates the request based on some other message from the ITR to the ETR (processed by whatever intervening systems you want to use) is something that can be determined later. Now we are suppose to be experimenting to determine whether or not the overall LISP concept works at all. I have a real problem seeing how much of what is discussed on this list advances that core concept. > In practice, I think that changing the map request or map response > format is going to be extremely difficult under either model. But > if I had to pick one that I thought might be upgradeable, it would > be an approach with MR and MS as active components rather than > merely relays. IMHO there is no difference. In either case the software on the MR/ MS will have to be changed. The message sent from the ITR to the MR or from the MS to the ETR would be massaged to match whatever was expected or desired. In either case, you probably end up with a 'flag-day' to deploy the new method. Unless you complicate the protocol even more to process both. This is suppose to be an experiment. To me, that means concentrating on getting something to actually work rather than worrying about the details of how it works. There is a BGPv4 for some reason. I'm sure you know better than I what that reason is. DVMRP can't be found any where any longer, yet without it where would multicast be? OSPF has gone through several iterations. IMHO the purpose of this group is not to get it perfect the first time, but to get something out there to see if it works at all. It is an Experiment. Had we done that with PIM, I guarantee you it would look a lot different than it does now. And interdomain multicast would be a reality rather than some dream. --Apple-Mail-89-494053628 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII
On Sep 22, 2009, at 5:47 AM, Margaret Wasserman = wrote:

True, except = you haven't explained why we need this header at all...

=

We don't "need" it.  There are many = ways it could be done.
This was the choice that was made based = on experience with the 
systems LISP was being built = on.

It is an = EXPERIMENT.

What if the ITR sent a simple question to the Map = Resolver of the form "What RLOC(s) should I use to reach this EID (or = EID prefix)?".

Because this requires an = extra step that we don't want the ITR to have to deal = with.
The ITR wants to send map-requests one place, that's the = map resolver.

If your thought is that the = map-resolver provides the RLOC of the ETR, the problem
is that = it (the MR) isn't "authoritative".  The only one who really knows = what EIDs it serves is
the ETR itself.  The current = desire is to always get the latest information from the = most 
authoritative source.  If you have the = intermediate step you have delay problems or
attack = problems.

  But, that ALT-specific detail should = remain hidden inside the ALT, = IMO.

IMHO, (note I'm trying to be = humble) it is.

The fact that the ITR sends the = control message to the MR first is just
a simple way of = injecting the map-request into the ALT.

We used = to have the ITR actually join the ALT, but then it had to run BGP = over
the ALT.  It worked just fine, but the architects = thought it could result in a larger
BGP topology than they = wanted.  I agree.

Changing the format of = the message sent from the ITR to whatever mapping
distribution = system exists should be considered.  But I believe the = current
EMR format could be used no matter what was = substituted in.

This is an = experiment.


The fact = that that just bashing the address could work points out why this type = of encapsulation isn't needed at all.  The EID for the request is = already in the Map Request itself, so there isn't any need to include it = in an encapsulated header.


You -may- be right that it = isn't needed.  It is just easier to do it this way.
Its = already done and it works.  The decision to back up and start = over
isn't what I would think would fit into an "experiment" = unless there is
some overwhelming evidence that what already = works isn't going to 
continue = working.


What Vince has proposed does the = exact _opposite_ of isolating the xTRs from the mapping system, as they = are required to build mapping-system-specific requests (using EIDs as = destination addresses) and then encapsulate them to get them to the = mapping system. 

This is = extremely simple.  Much, much easier than having to be a member of = the ALT.
In any case, its hard for me to imagine how it could = be easier for the ITR to build
the map-request.  Seems to = me that exactly the same information will have to be sent
even = if it is in a different format.

A system where we ask simple = questions like "What RLOC(s) should I (as an ITR) use to reach this EID = (or EID prefix)?" and get simple answers like "Use this/these RLOC(s) to = reach this EID Prefix" over a simple (unencapsulated) transport would = actually _hide_ the details of the mapping system from the = xTRs.

At the cost of throwing away tons = of stuff that has already been implemented and
proven to work, = for absolutely no proven gain in functionality other than it = appears
to be cleaner.

In your system = the ITR sends a message to the map-resolver.

In = the current system the ITR sends a message to the = map-resolver.

They look pretty much identical = to me.  The only difference is the 
format of the = bits.

Joel brought up the question of = debugging.

As one who has had to look at tons = and tons of these messages being forwarded,
it is a whole lot = easier to monitor the change of the external header keeping = the
inner packet exactly the same than it is to figure out if = the control packet that
came in generated the right control = packet on the way out.

In a different email = margaret said:

Your current perception of the MR = and MS as BGP routers is understandable, given the nature of the = ALT.  However, that isn't guaranteed to be a constant for = LISP.

True, but if I were to bet, I'd = give 10 to 1 odds on the ALT.  I've lost bets.
I sold my = Apple several months ago.  (Oh well)

And = if something else were to be substituted in, I see no need to = change
the format of the messages sent from the ITR.  You = might change them, but
you don't actually need to change them. =  

In this thread, we're talking about = whether or not it is easy for a given platform/OS = to 
process the messages.  While this is important = in a final RFC, LISP is an experiment.  
It may not work = at all.

Or perhaps we're past that point? =  Is there actually a consensus that LISP will be
deployed = and will actually solve the problem?  If so, then I back off = completely.

I guess the only way to know is to = call for such a consensus.  Any one want to
say yes? =  (I'm not willing to go that far = yet.)

So, it doesn't make architectural sense for an ITR = to build an encapsulated ALT mapping packet and send it to the = MR.

It does to me.  Its easy = to implement.  It works.  Its easy to debug.
It = makes as much sense as any other way I've seen proposed on this list so = far.

I also don't think it is realistic = that the MR/MS will remain as simple as you describe, nor do I believe = that it is possible (or even desirable) for the MR or the MS  to = have no LISP-specific code.

This is an = argument without any basis.  There are no alternate proposals that = don't have
LISP-specific code.  I find it very hard to = understand how a LISP map-request could be
processed by any = system that didn't have "LISP-specific = code".

Rather the ALT does -NOT- require LISP = specific code.  Seems like this meets = your 
requirements.

ITRs register = with Map Servers, 

ETRs register = with map servers.

There are also likely to be a number of = anti-spoofing requirements for the mapping system that go well beyond = the need to read the EID from the = request.

This is suppose to be an = experiment.  The purpose of the experiment is to prove = the
viability of the LISP concept.  If there are gross = security problems in the LISP concept,
to the extent that it = becomes non-deployable, then you'd have an excellent point. =  But
unless you can describe a spoof that -I- will easily = understand, the claim for 'anti-spoofing'
requirements is well = beyond what I would consider to be an = Experiment.

Joel = said:

If MR and MS nodes are pure relay, = then in order to change the format of a Map Query, as sent by an ITR, = every ETR in the world would have to have the upgraded = software.
In contrast, MS could accept an alternative form, = and transform it to whatever the ALT = handles.

Actually the MR does the = acceptance to send the request on to the ALT.

And MRs (which have = registrations from ETRs) could, at least in theory, transform the ALT = format into whatever the ETR = wants.

ETRs register to the map-server. =  I totally agree that the MS can change the format to = whatever.
Therefore, what we have works.  I don't see any = reason to change it now.

6 of one 1/2 dozen of the = other.  ie whether the MR/MS just relays the request or = actually
formulates the request based on some other message = from the ITR to the ETR (processed
by whatever intervening = systems you want to use) is something that can be determined = later.

Now we are suppose to be experimenting = to determine whether or not the overall LISP 
concept = works at all.  I have a real problem seeing how much of what is = discussed on 
this list advances that core = concept.

In practice, I think that changing = the map request or map response format is going to be extremely = difficult under either model.  But if I had to pick one that I = thought might be upgradeable, it would be an approach with MR and MS as = active components rather than merely = relays.

IMHO there is no difference. =  In either case the software on the MR/MS will have to be = changed.
The message sent from the ITR to the MR or from the = MS to the ETR would be massaged to
match whatever was expected = or desired.  In either case, you probably end up with a = 'flag-day'
to deploy the new method.  Unless you = complicate the protocol even more to process = both.

This is suppose to be an experiment. =  To me, that means concentrating on getting
something to = actually work rather than worrying about the details of how it works. =  

There is a BGPv4 for some reason. =  I'm sure you know better than I what that reason = is.

DVMRP can't be found any where any longer, = yet without it  where would multicast = be?

OSPF has gone through several iterations. =  

IMHO the purpose of this group is not to = get it perfect the first time, but to get something
out there = to see if it works at all.   It is an = Experiment.

Had we done that with PIM, I = guarantee you it would look a lot different than it does = now.
And interdomain multicast would be a reality rather than = some dream.

= --Apple-Mail-89-494053628-- From dino@cisco.com Tue Sep 22 21:13: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 5434D3A683F for ; Tue, 22 Sep 2009 21:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 ku0FRfoSeiLE for ; Tue, 22 Sep 2009 21:13:06 -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 E4A3D3A6805 for ; Tue, 22 Sep 2009 21:13:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN49uUqrR7MV/2dsb2JhbAC9NYhPAZAjBYQbgV2JBw X-IronPort-AV: E=Sophos;i="4.44,435,1249257600"; d="scan'208";a="191520204" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 23 Sep 2009 04:14:11 +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 n8N4EAQS022660; Tue, 22 Sep 2009 21:14:10 -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 n8N4EAE8012088; Wed, 23 Sep 2009 04:14:10 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, 22 Sep 2009 21:14:10 -0700 Received: from [192.168.1.2] ([10.21.118.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 21:14:09 -0700 Message-Id: <24590175-A933-450A-9B7E-21F70E6CB2F1@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 v936) Date: Tue, 22 Sep 2009 21:14:09 -0700 References: <20090922042637.GA14702@vaf-lnx1> <18014235-78E2-4B81-A6A9-FC23CFB0FAC4@cisco.com> <676A8C54-34B4-4584-A937-149EEAA9CB4C@cisco.com> <4AB901A5.90302@joelhalpern.com> <4AB90520.60903@joelhalpern.com> <20090922215005.GA7034@vaf-lnx1> <4AB959B9.6040105@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Sep 2009 04:14:10.0064 (UTC) FILETIME=[4CDE1900:01CA3C04] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7276; t=1253679250; x=1254543250; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20=20Requests |Sender:=20; bh=jhLt5kKBI657ifQeZJwCW6Ss7nEi29S4pOllQUlb/ik=; b=a79Vc/hxC4fPBEaiqS4nCM9bSVIk/EQ0j9VsWlxsIiHuWC/rEN9YTUGkFD Sv+9Xb76gcn+s8rOi2iDyofmJdDQ0w0KJzEyfvGP/L9S6xiZ6owoQgZ9yjO4 rQSGGs4b2HZzmUBeLeMXkcfc7teyjYvjjGV4GPlw6HzhoLp8VPcqE=; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 04:13:07 -0000 Two points: (1) There are many ways to skin a cat. Just because you prefer something doesn't mean it's the right choice. Rather than saying something can be done another way, indicate why it is better. (2) Changing protocols does not mean you are going to improve interoperability. Let's build the right solution for the customers and then make sure we spec it out clearly so we have interoperability. Doing interoperability for sake of sole interoperability does nothing for the user if we don't solve the problems the users want us to solve. Dino On Sep 22, 2009, at 6:05 PM, Sam Hartman wrote: >>>>>> "Dino" == Dino Farinacci writes: > >>> Given the state of the work, I do not think the size of the change >>> to the spec is a particularly important dimension. The question is >>> what the right approach is, not what the livable approach with the >>> smallest change to the draft is. (Sorry, that sentence is probably >>> overstated and probably sounds like I am implying ill will on your >>> or Dino's part. I do not see any ill will or attempt to do something >>> wrong. I just disagree about the priorities.) > > Dino> You would have to detail out: > > OK. > So, first let me detail changes to the map request. > We add a second source RLOC field so that an ITR can include two > source RLOCs from different address families. > It's my understanding that today in the cross-AFI case, I'll > include one RLOC in the IP header and may include an RLOC of the > opposite address family in the source RLOC field of the map request. > > We need to include two RLOCs in the map request. > > An alternate design would be to have the MR and MS swap the RLOCs if > they swap address families of the outer header. I prefer to include > two RLOCs in a map request because the behavior of the MR and MS is > simpler. > > Encapsulation behavior: I have a map request. I'm an MS or an ITR and > I want to produce a packet suitable for sending over the RLOC > internet. > I have a destination RLOC I wish to send to. > > I search the map request packet. If there is no source RLOC in the > map request packet of the destination RLOC AFI, I will use one of > my RLOCs. > I construct an IP header using the source RLOC I just selected as the > IP address, the destination RLOC that is an input to the encapsulation > procedure as the destination. Inside this is a UDP header. I select > a valid ephemeral port as the source port and the destination port of > 4342. > > An encapsulator MAY choose to always use their own source RLOC . The > reason for allowing this is to support map servers that have URPF that > prevent them from using the ITR's RLOC. That probably decreases > debugging success, but may be better than completely failing to work > as an MS. > > > > Decapsulation procedure: I'm an MR. I've received the result of the > encapsulation procedure. I wish to produce a packet for sending over > the alt. I search the map request for an RLOC of the same AFI as the > destination EID. If there is no such RLOC, I pick one of my own > RLOCs. Picking my own RLOC is an arbitrary decision; there may be > other decisions. As I mention in issue #23, this is already undefined > in the current system. I needed to propose a specific fix to #23 in > order to answer your questions below. > > I construct an IP packet of the version of the destination EID. The > source address is the RLOC I've picked above--either the RLOC from the > map request or the RLOC of the MR if no such RLOC exists. The > destination IP address is the destination EID. The source UDP port > can be the same as from the packet I received, if that helps > debugging. > > ETR behavior: The ETR receives the map request. It generates a reply > and sends it to UDP port 4342 on one of the source RLOCs read from the > packet. This fails if the ETR and ITR do not share RLOCs in the same > address family; so does the current procedure. > > > > > Dino> o How you won't break LISP variant 1.0. > > I think LISP 1.0 is out of scope for this WG. If a particular > implementation wants to support it, > that's there business. However I don't think spending time on LISP > 1.0 is something this WG should do. > > Dino> o How you won't break mix-AF support. > > The encapsulation procedure above always succeed. > > The map request packet itself is never modified by the encapsulation > or decapsulation procedure. > So, the ETR will receive the map request. > If the ETR and ITR share a source RLOC AFI in common, then the ETR > can respond. > That's sufficient to argue that cross-AFI is not broken. > > > Dino> o How you won't break lig. > > LIG generates a map request with either one or two source RLOC entries > depending on what address families it supports. It follows the > encapsulation procedure with the destination RLOC set to the RLOC of a > map resolver. > > > > Dino> o How you won't break traceroute on the ALT network. > > The alt draft does not specify traceroute. If you would like to make > a proposal that we support traceroute on the alt and give requirements > for that, we can consider that as a WG. Until then, the WG has no > obligation to break traceroute. However I'm reasonably sure that this > will work or can be made to work with traceroute. > > > Dino> o How you don't break ALT attached xTRs. > Dino> o How IPv4 Map-Replies can be returned for IPv6 Map-Requests. > Dino> o How map-resolver and map-server caching will be dealt with. > Dino> o ICMP unreachables now can be delivered to the requesting > ITR. Now > Dino> they will be delivered to > Dino> the encapsulating MR. The MR will have to cache Map- > Requests. > > This is not true in my proposal. By caching things, an MR could > deliver errors in more cases than it does otherwise, but I think > without caching error handling is good.. > > Dino> We have 3 implementations going now and maybe more coming > soon. And > Dino> those 3 implementations don't interoperate now and we need > them to so > Dino> we can learn about what's already in the specs. > > The most important thing you can do to improve interoperability to use > standard components consistent with their specs. > > we found problems with lig because LISP implementations had to use > their own UDP stack because of this issue. Implementing LISP is > harder because of this issue. > > We found problems with LISP implementations because LISP does not use > IPsec as specified but instead diverges from the IPsec standards. > > I expect that every time we run into things where LISP just uses a > header or packet type of some other protocol but does not use the > semantics and does not allow integration with a normal implementation > of that protocol, we'll find huge interoperability problems. > > I may not have as much experience implementing protocols as some > people here, but I can say with very high confidence that improving > use of existing protocols will significantly help your > interoperability problem. > > --Sam with implementor hat on From dino@cisco.com Tue Sep 22 21:15: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 DBA433A6805 for ; Tue, 22 Sep 2009 21:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 pGAvIlVqZ5jm for ; Tue, 22 Sep 2009 21:15:00 -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 7C1D53A679F for ; Tue, 22 Sep 2009 21:15:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN49uUqrR7MV/2dsb2JhbAC9NYhPAZAjBYQbimQ X-IronPort-AV: E=Sophos;i="4.44,435,1249257600"; d="scan'208";a="191520357" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 23 Sep 2009 04:16: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 n8N4G5kZ024494; Tue, 22 Sep 2009 21:16:05 -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 n8N4G5tS012952; Wed, 23 Sep 2009 04:16:05 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, 22 Sep 2009 21:16:05 -0700 Received: from [192.168.1.2] ([10.21.118.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 21:16:04 -0700 Message-Id: <1DD504EA-DA8A-4D4A-A4E0-902C4DE19999@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 v936) Date: Tue, 22 Sep 2009 21:16:04 -0700 References: <20090923005427.05F336BE55B@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Sep 2009 04:16:05.0006 (UTC) FILETIME=[9160DAE0:01CA3C04] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1742; t=1253679365; x=1254543365; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=rk5ajutM8bL4olb6piqWzKjU5uQ3jezNeM1iXINQ64o=; b=Yss/YPNO4a9eqGo2i8CxbB3E4Z/4H+O0fK5ZGt34qNjDWO9M8NIUIe3Yit Sr9F1PSDikgmK7rx+awb/GYnkG+/Nm/OFoLxuckUk1J4uGNs+8K8kb5j7cjx vFxTuOdSNsL6m9lITx7CCkEK9EoMSrBTUDUuly+ars/e9CDMB6wEc=; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 04:15:02 -0000 >>>>>> >>>>>> "Noel" == Noel Chiappa writes: > >>> From: Vince Fuller >>> the issue of UDP port 4341 being used for both control and data >>> packets >>> ... >>> We have discovered through testing those imlementations that >>> Map-Request processing efficiency will be poor and that deployment >>> on >>> an operational network will be problematic as long as UDP port >>> 4341 is >>> used for both user data packets and Encapsulated Map Requests. The >>> changes that I described in my earlier message are intended to fix >>> that >>> specific problem > > Noel> From what I've seen, nobody has a problem with that change. > Maybe we should > Noel> focus on that for the moment, and get agreement on that, so > that change can go > Noel> in -05 (or -06, I forget which one we're on now)? > > I'd rather wait until we have a complete solution to #22. I think it > is very problematic to implement half fixes. Man Sam, the solution of shared keys works really well. It is not a half solution. Please, please, please let's be practical. A lot of security machinery doesn't have a proven track record over the last 20 years. We should learn from this and ask why this is the case. > It makes it very easy for the editors to block changes they don't like > in a manner that makes the process much less open and fair. It > removes a lot of the forcing functions for building consensus. It's not about like or dislike. It's about proving if we need it. Let's start somewhere simple first. Dino > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Tue Sep 22 22:23: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 D9E703A681A for ; Tue, 22 Sep 2009 22:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 kGx-Ntjg54jV for ; Tue, 22 Sep 2009 22:23:29 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 3CDD63A691D for ; Tue, 22 Sep 2009 22:23:29 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 22 Sep 2009 22:24:34 -0700 From: Terry Manderson To: Noel Chiappa , "lisp@ietf.org" Date: Tue, 22 Sep 2009 22:24:33 -0700 Thread-Topic: [lisp] #5: LISP protocol version is alive and kicking Thread-Index: Aco7iisJEq2zTaBGTlW3054mc3zxagAg/bns Message-ID: In-Reply-To: <20090922133930.1D8FE6BE55D@mercury.lcs.mit.edu> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] #5: LISP protocol version is alive and kicking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 05:23:31 -0000 On 22/09/09 11:39 PM, "Noel Chiappa" wrote: >> From: Terry Manderson >=20 >> g) TTL (clock sweep) can be used to maintain ITR mapping freshness. >=20 > I'm not sure about this one yet: we _might_ want an explicit mechanism > (piggybacked mapping versions or checksums) to check for stale mappings; So you want to ask (or some other way) what the xTR has in mapping? If so, it sounds weighty and akin to an open resolver. Or have I misinterpreted what you are thinking? > probably there will be some experimentation to see i) if stale mappings > are a problem, and ii) how well a piggybacked mechanism works, before > we can say for sure. If versions are to be transferred only in map-reply, my initial thoughts would be that stale xTR mappings should be avoided otherwise the data communication could probably fail due to a mismatch of data header/encapsulation. [..] >=20 >> Thus far I don't see any convergence on what the version looks like >> in the map-request/map-reply (type value or otherwise) >=20 > The type value is 4 bits, that ought to be more than enough? Assuming that the type value is how the WG and/or authors wish to handle th= e version info inclusive of the alterations of section 6.1.4 of draft-ietf-lisp to adjust the use of the type field, which is currently specified as 2 (map-reply). >=20 >> Is this a fair approximation of the current position? >=20 > Other than the ones I commented on, I think so. >=20 Thanks Cheers, Terry From lear@cisco.com Tue Sep 22 22:47: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 14BC93A68F9 for ; Tue, 22 Sep 2009 22:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.218 X-Spam-Level: X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7OOY3TzLl7B8 for ; Tue, 22 Sep 2009 22:47:43 -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 49C0E3A67F9 for ; Tue, 22 Sep 2009 22:47:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwAAG9TuUqQ/uCKe2dsb2JhbACBUVEymCQBAQsLJAahVIhPAZAYBYQbimQ X-IronPort-AV: E=Sophos;i="4.44,436,1249257600"; d="scan'208,217";a="50016572" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 Sep 2009 05:48:47 +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 n8N5mlLC032530; Wed, 23 Sep 2009 07:48:47 +0200 Received: from elear-mac.local (dhcp-10-55-82-122.cisco.com [10.55.82.122]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8N5mkwP023896; Wed, 23 Sep 2009 05:48:47 GMT Message-ID: <4AB9B6BE.6070006@cisco.com> Date: Wed, 23 Sep 2009 07:48:46 +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: In-Reply-To: X-Enigmail-Version: 0.97a Content-Type: multipart/alternative; boundary="------------000007090302020209070500" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7634; t=1253684927; x=1254548927; 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]=20Call=20for=20interest=20in=20w orking=20on=20security |Sender:=20; bh=V62iy91w7JFzOCQJD5/5XdlkvwFDOHS0XDdhf2y82PY=; b=rKplyEdu4thMFwopR/4SSloQUSYTM5+Pscv5rEC4fK/Lyiu0rGItWVI0mi ViiI6D0K2yNRdsGNdMd6IVnE+k66X1CDnsKq/ouPvUAG9Y3PzEKaMxW4HinE JPnGEIGqvs; 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] Call for interest in working on security X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 05:47:45 -0000 This is a multi-part message in MIME format. --------------000007090302020209070500 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sam, I read through your wiki discussion and I think it's pretty good as far as it goes. There are a number of questions that I think you allude to that perhaps you should ask explicitly: 1. How does breaking into an ALT router differ from breaking into a BGP router within the DFZ? To me this really depends on how the ALT is constructed. If it is constructed in a highly aggregated way, as envisioned, then the ability to reroute traffic is limited to only those networks, combined with the BGP metric. The DFZ only has the BGP metric and perhaps some ACLs in some places to fall back on. 2. Can ALT take advantage of SIDR? Here I am not so much an expert on SIDR to say. I will make the following two general assertions, as relates to your comment about key management: * the problem is operationally difficult when there are large numbers of signers and/or long trust chains. * a small number of signers requires concentration of trust far beyond the point of what exists today (perhaps by 3 orders of magnitude or more), leading to potential continuity problems. These were the trade-offs I explored with NERD. Regards, Eliot On 9/21/09 1:10 PM, Sam Hartman wrote: > > Speaking as an individual. There's a bit with my chair hat on at the > end clearly labeled. > > So, I'd like to see some progress on discussing security here. I've > started an outline of what I think we need to cover at > http://tools.ietf.org/wg/lisp/trac/wiki/Security01 . The idea is that > people who agree with the direction I'm taking can join and we can > work together putting together something in the open that we'll bring > to the WG for review when it's ready. I want to do everything in the > open so people know what I'm up to, and so people who have other ideas > are encouraged to actually go write up their ideas. However at this > point I'm not trying to build a WG-wide consensus. > > I've started with a broad outline and a set of reading material. If > the outline and my posited goals for LISP security sounds interesting > to you, then perhaps you want to become involved. If so, then I'd > recommend starting by reading some or all of the recommended reading. > Hopefully some people around here have already read several of the > things there. > > There's probably not enough detail for you to agree with the direction > enough to join the proposal at this point. However I'm definitely > interested in comments even at this stage, especially about things to > add to the reading list, or headings I missed. > > I hope we can get things kick-started. > > Speaking as a chair, If anyone wants wiki space for this sort of > thing, by all means take it. If you run into authorization problems > or anything else, let the chairs know. I ask that you make your page > clearly labeled as an individual/group proposal but not as a WG > effort. Also, it looks tricky to rename pages. So, please don't take > a page name we're likely to want to use. > > If people think using the WG wiki for this sort of pre-WG effort is a > bad idea, then let me know; I can find hosting elsewhere. I was just > trying to be open. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --------------000007090302020209070500 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Sam,

I read through your wiki discussion and I think it's pretty good as far as it goes.  There are a number of questions that I think you allude to that perhaps you should ask explicitly:
  1. How does breaking into an ALT router differ from breaking into a BGP router within the DFZ?
    To me this really depends on how the ALT is constructed.  If it is constructed in a highly aggregated way, as envisioned, then the ability to reroute traffic is limited to only those networks, combined with the BGP metric.  The DFZ only has the BGP metric and perhaps some ACLs in some places to fall back on.
  2. Can ALT take advantage of SIDR?
    Here I am not so much an expert on SIDR to say.
I will make the following two general assertions, as relates to your comment about key management:
  • the problem is operationally difficult when there are large numbers of signers and/or long trust chains.
  • a small number of signers requires concentration of trust far beyond the point of what exists today (perhaps by 3 orders of magnitude or more), leading to potential continuity problems.
These were the trade-offs I explored with NERD.

Regards,

Eliot

On 9/21/09 1:10 PM, Sam Hartman wrote: 

Speaking as an individual.  There's a bit with my chair hat on at the
end clearly labeled.

So, I'd like to see some progress on discussing security here.  I've
started an outline of what I think we need to cover at
http://tools.ietf.org/wg/lisp/trac/wiki/Security01 .  The idea is that
people who agree with the direction I'm taking can join and we can
work together putting together something in the open that we'll bring
to the WG for review when it's ready.  I want to do everything in the
open so people know what I'm up to, and so people who have other ideas
are encouraged to actually go write up their ideas.  However at this
point I'm not trying to build a WG-wide consensus.

I've started with a broad outline and a set of reading material.  If
the outline and my posited goals for LISP security sounds interesting
to you, then perhaps you want to become involved.  If so, then I'd
recommend starting by reading some or all of the recommended reading.
Hopefully some people around here have already read several of the
things there.

There's probably not enough detail for you to agree with the direction
enough to join the proposal at this point.  However I'm definitely
interested in comments even at this stage, especially about things to
add to the reading list, or headings I missed.

I hope we can get things kick-started.

Speaking as a chair, If anyone wants wiki space for this sort of
thing, by all means take it.  If you run into authorization problems
or anything else, let the chairs know.  I ask that you make your page
clearly labeled as an individual/group proposal but not as a WG
effort.  Also, it looks tricky to rename pages.  So, please don't take
a page name we're likely to want to use.

If people think using the WG wiki for this sort of pre-WG effort is a
bad idea, then let me know; I can find hosting elsewhere.  I was just
trying to be open.
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

--------------000007090302020209070500-- From hartmans@mit.edu Wed Sep 23 03:39: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 401C03A67FB for ; Wed, 23 Sep 2009 03:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 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 8OrKWnEXvxDw for ; Wed, 23 Sep 2009 03:39:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 858023A672E for ; Wed, 23 Sep 2009 03:39:18 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EC6C4413E; Wed, 23 Sep 2009 06:40:18 -0400 (EDT) To: Eliot Lear References: <4AB9B6BE.6070006@cisco.com> From: Sam Hartman Date: Wed, 23 Sep 2009 06:40:18 -0400 In-Reply-To: <4AB9B6BE.6070006@cisco.com> (Eliot Lear's message of "Wed\, 23 Sep 2009 07\:48\:46 +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=utf-8 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] Call for interest in working on security X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 10:39:19 -0000 I really appreciate your thoughtful comments. I'll admit that I am personally interested in the non-alt parts of LISP security. My perhaps naive assumption is that something like SIDR can be applied and that I'd like to get a better handle on the surrounding landscape before I think in detail about that. However thinking about how the alt differed from traditional BGP--particularly in terms of the implications of high aggrigation on security--is something I had not done. One other comment: >>>>> "Eliot" =3D=3D Eliot Lear writes: Eliot> I will make the following two general assertions, as relates to = your comment Eliot> about key management: Eliot> =C3=A2=C2=80=C2=A2 the problem is operationally difficult when= there are large numbers of Eliot> signers and/or long trust chains. Eliot> =C3=A2=C2=80=C2=A2 a small number of signers requires concentr= ation of trust far beyond the Eliot> point of what exists today (perhaps by 3 orders of magnitude= or more), Eliot> leading to potential continuity problems. Eliot> These were the trade-offs I explored with NERD. These are interesting. However I don't think I have talked about key management for anything involving signers at all so far. I've talked about key management for map register, but there explicitly talked about a solution with no public key ops. From hartmans@mit.edu Wed Sep 23 08:23: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 7F8F03A6A33 for ; Wed, 23 Sep 2009 08:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 QpXa7Ek-i35x for ; Wed, 23 Sep 2009 08:23:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id AFD8A3A6A80 for ; Wed, 23 Sep 2009 08:23:21 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 19DF2413E; Wed, 23 Sep 2009 11:24:22 -0400 (EDT) To: Dino Farinacci References: <20090923005427.05F336BE55B@mercury.lcs.mit.edu> <1DD504EA-DA8A-4D4A-A4E0-902C4DE19999@cisco.com> From: Sam Hartman Date: Wed, 23 Sep 2009 11:24:22 -0400 In-Reply-To: <1DD504EA-DA8A-4D4A-A4E0-902C4DE19999@cisco.com> (Dino Farinacci's message of "Tue\, 22 Sep 2009 21\:16\:04 -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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 15:23:22 -0000 >>>>> "Dino" == Dino Farinacci writes: >>>>>>> >>>>>>> "Noel" == Noel Chiappa writes: >> >>>> From: Vince Fuller >>>> the issue of UDP port 4341 being used for both control and data >>>> packets >>>> ... >>>> We have discovered through testing those imlementations that >>>> Map-Request processing efficiency will be poor and that deployment >>>> on >>>> an operational network will be problematic as long as UDP port >>>> 4341 is >>>> used for both user data packets and Encapsulated Map Requests. The >>>> changes that I described in my earlier message are intended to fix >>>> that >>>> specific problem >> Noel> From what I've seen, nobody has a problem with that change. >> Maybe we should Noel> focus on that for the moment, and get agreement on that, so >> that change can go Noel> in -05 (or -06, I forget which one we're on now)? >> >> I'd rather wait until we have a complete solution to #22. I think it >> is very problematic to implement half fixes. Dino> Man Sam, the solution of shared keys works really well. It is not a Dino> half solution. Dino> Please, please, please let's be practical. A lot of security machinery Dino> doesn't have a proven track record over the last 20 years. We should Dino> learn from this and ask why this is the case. I've read your message several times, and I'll admit that I'm completely puzzled how a comment I made about fixing map request encapsulation has to do with shared keys, practical security machinary or proven track records. From dino@cisco.com Wed Sep 23 08:41: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 0CF3E3A69D4 for ; Wed, 23 Sep 2009 08:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 aONBCXqGW3rC for ; Wed, 23 Sep 2009 08:41:50 -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 6B5C43A659A for ; Wed, 23 Sep 2009 08:41:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG/euUqrR7PE/2dsb2JhbAC+YohPAZAZBYQbimQ X-IronPort-AV: E=Sophos;i="4.44,439,1249257600"; d="scan'208";a="191655228" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 23 Sep 2009 15:42:56 +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 n8NFgurm011961; Wed, 23 Sep 2009 08:42:56 -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 n8NFguOY020975; Wed, 23 Sep 2009 15:42:56 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); Wed, 23 Sep 2009 08:42:56 -0700 Received: from [192.168.1.2] ([10.21.78.60]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 08:42:56 -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 v936) Date: Wed, 23 Sep 2009 08:42:55 -0700 References: <20090923005427.05F336BE55B@mercury.lcs.mit.edu> <1DD504EA-DA8A-4D4A-A4E0-902C4DE19999@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Sep 2009 15:42:56.0026 (UTC) FILETIME=[850F77A0:01CA3C64] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1827; t=1253720576; x=1254584576; 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=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20=20Requests |Sender:=20; bh=MyQKxq+GFIVgeVvpE4WRXrhHaS+rx88sNxb7sfFOFa8=; b=EHHVR8dCGKDJeD5aInHYiLsX8xr5mf/5QFeI0WDqixdGpPWnxyO5R91SxV k3mj8RfTfsUnQaNilMcAbBy+T86Y9hXowWi7lU07dHRQS80UU64UoYUTKtZV tE9oCwqfPa; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 15:41:52 -0000 I was mixing up threads because they have both been active. Sorry about that. Dino On Sep 23, 2009, at 8:24 AM, Sam Hartman wrote: >>>>>> "Dino" == Dino Farinacci writes: > >>>>>>>> >>>>>>>> "Noel" == Noel Chiappa writes: >>> >>>>> From: Vince Fuller >>>>> the issue of UDP port 4341 being used for both control and data >>>>> packets >>>>> ... >>>>> We have discovered through testing those imlementations that >>>>> Map-Request processing efficiency will be poor and that deployment >>>>> on >>>>> an operational network will be problematic as long as UDP port >>>>> 4341 is >>>>> used for both user data packets and Encapsulated Map Requests. The >>>>> changes that I described in my earlier message are intended to fix >>>>> that >>>>> specific problem >>> > Noel> From what I've seen, nobody has a problem with that change. >>> Maybe we should > Noel> focus on that for the moment, and get agreement on that, so >>> that change can go > Noel> in -05 (or -06, I forget which one we're on now)? >>> >>> I'd rather wait until we have a complete solution to #22. I think >>> it >>> is very problematic to implement half fixes. > > Dino> Man Sam, the solution of shared keys works really well. It > is not a > Dino> half solution. > > Dino> Please, please, please let's be practical. A lot of > security machinery > Dino> doesn't have a proven track record over the last 20 years. > We should > Dino> learn from this and ask why this is the case. > > I've read your message several times, and I'll admit that I'm > completely puzzled how a comment I made about fixing map request > encapsulation has to do with shared keys, practical security machinary > or proven track records. From jari.arkko@piuha.net Wed Sep 23 09:31: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 3EEC53A69AC for ; Wed, 23 Sep 2009 09:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 nbzYYwztfQjo for ; Wed, 23 Sep 2009 09:31:41 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 233133A68A7 for ; Wed, 23 Sep 2009 09:31:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 812F0D491E; Wed, 23 Sep 2009 19:32:46 +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 LEm0ViN36iUE; Wed, 23 Sep 2009 19:32:46 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 15FAFD4903; Wed, 23 Sep 2009 19:32:46 +0300 (EEST) Message-ID: <4ABA4DAD.6050508@piuha.net> Date: Wed, 23 Sep 2009 19:32:45 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Eliot Lear References: <20090917152232.2BC336BE609@mercury.lcs.mit.edu> <4AB25646.1090302@cisco.com> In-Reply-To: <4AB25646.1090302@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] #19: not including the 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: Wed, 23 Sep 2009 16:31:42 -0000 Expert review is a fine rule for an Experimental RFC bits from my perspective. Jari From jnc@mercury.lcs.mit.edu Wed Sep 23 10:03: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 6BECE3A6963 for ; Wed, 23 Sep 2009 10:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 4r70EXd+cImq for ; Wed, 23 Sep 2009 10:03: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 6E5233A6407 for ; Wed, 23 Sep 2009 10:03:42 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DB6076BE5C5; Wed, 23 Sep 2009 13:04:47 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090923170447.DB6076BE5C5@mercury.lcs.mit.edu> Date: Wed, 23 Sep 2009 13:04:47 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 17:03:43 -0000 > From: Sam Hartman >>> the issue of UDP port 4341 being used for both control and data >>> packets >>> ... >>> We have discovered through testing those imlementations that >>> Map-Request processing efficiency will be poor and that deployment >>> on an operational network will be problematic as long as UDP port >>> 4341 is used for both user data packets and Encapsulated Map >>> Requests. The changes that I described in my earlier message are >>> intended to fix that specific problem >> From what I've seen, nobody has a problem with that change. Maybe >> we should focus on that for the moment, and get agreement on that > I'd rather wait until we have a complete solution to #22. I think it > is very problematic to implement half fixes. I have taken a careful look at #22. (Although I didn't catch what "There are also cases where an ETR or .. ALT router consumes ALT packets not addressed to it; those cases seem fine to me." was about.) In trying to understand it, it seems to me to encompass two separate technical issues: i) the need for packet processing on port 4341 to recognize encapsulated packets, and treat them differently from all other port 4341 packets being received from the ITR, and ii) the need for packet processing to recognize packets destined to an EID range (which likely does not correspond to any of the xTRs actual addresses (either EIDs or RLOCs), but which are in fact destined for the xTR. It's true that these two things are likely co-located in the code (either in the old protocol design, or the proposed new one): in either case, an implementor would naturally (for efficiency reasons) first look for cases where decapsulation is needed, and in those cases where it is, peform special processing on those packet to check to see if it had a 'funny' address, one destined for the node itself. However, in technical terms, they are not necessarily connected at the protocol level. One could imagine changing the 4341 encapsulation to some other encapsulation (as the proposal does) without doing anything about the 'destination address' issue. One could also change the 'destination address' value, without changing the encapsulation. (I know, this would require the Map-Server to mung the inner header - this is not a serious proposal, just a 'thought experiment' to show that the two things are not irretrievably intertangled at a technical level.) So, with all that in hand, I would like to focus for a second on the first issue, the encapsulation. Do you have any _technical_ concerns about the proposed encapsulation change? I understand that this doesn't do anything for the other issue you raised in #22; it also doesn't address the issue raised by others, about the use of encapsulation in general (e.g. on the ITR -> Map-Resolver link). All I'm trying to find out here is if you have a _technical_ concern about the proposed encapsulation change - I'm not trying to dismiss your _other_ concerns about this change. If you don't have any technical concerns, we can move onto both i) your other concern(s) about this point, and ii) the other technical issue you have raised in #22. Noel From jnc@mercury.lcs.mit.edu Wed Sep 23 13: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 C85E03A688D for ; Wed, 23 Sep 2009 13:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 cJR+QRsaZ4Pk for ; Wed, 23 Sep 2009 13:19:32 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id EE5043A690E for ; Wed, 23 Sep 2009 13:19:31 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B22736BE5EC; Wed, 23 Sep 2009 16:20:37 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090923202037.B22736BE5EC@mercury.lcs.mit.edu> Date: Wed, 23 Sep 2009 16:20:37 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: [lisp] The other question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 20:19:32 -0000 In the process of doing somthing else, I ran across a point that I thought would probably be useful to point out to the WG as a whole. My perception is that the WG is not as good as it could be at paying attention to the question of _when_ to make changes; it seems to prefer mostly to focus on _if_ it should make a change. I think that's a big problem, since playing with that 'when' variable can make a big difference in the total costs and benefits of the change. The thing is that this WG is in a rather unusual postion, as IETF WG's go these days, in that it's not the usual 'design before implement' environment. There is a sizeable test-bed running this stuff, and we're learning all sorts of valuable lessons from it, including finding obscure bugs in the protocol, its interaction with existing infrastructure, etc. LISP will be running in a complex environment (lots of deployed data-handling infrastructure, running tunnels, other kinds of boxes, yadda-yadda), and there's just no substitute for the actual experience the testbed is giving (and has given us; it's been around for years). For a simple protocol, in a simple environment, you might be able to do a pretty good job with a sheet of paper. In this complex, existing, environment, experience is critical. The downside of a testbed (TANSTAAFL) is that making changes has costs beyond a new rev of the document. An incompatible change means a flag day (or days) for the testbed; a large change means that not only do we lose the test-bed for a while, but also developer attention has to go to doing the change. So changes have costs. But changing the 'when' can significantly impact those costs, and so change the cost/benefit ratio of the change. So let's not just talk about 'if' when it comes to changes, but let's give 'when' prominent consideration too. Noel From jzwiebel@cisco.com Wed Sep 23 13:26: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 06BB43A6A66 for ; Wed, 23 Sep 2009 13:26:25 -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=[AWL=-0.000, 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 6cQoCHwcmHvS for ; Wed, 23 Sep 2009 13:26:24 -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 4395F3A6A5D for ; Wed, 23 Sep 2009 13:26:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgEADYhukqrR7O6/2dsb2JhbACCKCy8QYhPAZAFBYQbimQ X-IronPort-AV: E=Sophos;i="4.44,440,1249257600"; d="scan'208,217";a="191784516" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 23 Sep 2009 20:27:30 +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 n8NKRTjx014827; Wed, 23 Sep 2009 13:27:29 -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 n8NKRTZY019517; Wed, 23 Sep 2009 20:27:29 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, 23 Sep 2009 13:27:29 -0700 Received: from [10.0.1.4] ([10.21.114.147]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 13:27:28 -0700 In-Reply-To: <20090923202037.B22736BE5EC@mercury.lcs.mit.edu> References: <20090923202037.B22736BE5EC@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-105-552533622 Message-Id: <2FC8B195-E1B6-49B2-9DC7-B7F5E21BC7C0@cisco.com> From: John Zwiebel Date: Wed, 23 Sep 2009 10:27:20 -1000 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 23 Sep 2009 20:27:28.0876 (UTC) FILETIME=[4545A2C0:01CA3C8C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1157; t=1253737649; x=1254601649; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[lisp]=20The=20other=20question |Sender:=20; bh=1mE0U6lCmIAc8/gVSDS+4izh+w6UTf5G3lQOa7PkkR8=; b=e/JOi8MFoU+hWbXD+xxio/n0XLahohS7emYQ9QLJRd/b/3+qrB+Zgh5YRW 5H8cVHYcgp3f5xnapkE8zKDwng2PwvvxCxJFf6igwbAdc1sV45Fj5Xlrs+90 CZHvWSXoXK; Authentication-Results: sj-dkim-2; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] The other question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 20:26:25 -0000 --Apple-Mail-105-552533622 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 23, 2009, at 10:20 AM, Noel Chiappa wrote: > So let's not just > talk about 'if' when it comes to changes, but let's give 'when' > prominent > consideration too. +1 --Apple-Mail-105-552533622 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
On Sep 23, 2009, at 10:20 AM, Noel Chiappa wrote:

So let's not just

talk about 'if' when it comes to changes, but let's give 'when' prominent

consideration too.


+1
--Apple-Mail-105-552533622-- From jmh@joelhalpern.com Wed Sep 23 14:46: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 3DC373A6949 for ; Wed, 23 Sep 2009 14:46:45 -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.859, BAYES_00=-2.599, 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 aSCZ6X+uILTc for ; Wed, 23 Sep 2009 14:46:44 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 6ED5C3A6804 for ; Wed, 23 Sep 2009 14:46:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id BF7FB32317B3; Wed, 23 Sep 2009 14:47:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 17AC632317B5; Wed, 23 Sep 2009 14:47:50 -0700 (PDT) Message-ID: <4ABA9785.1060802@joelhalpern.com> Date: Wed, 23 Sep 2009 17:47:49 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Noel Chiappa References: <20090923202037.B22736BE5EC@mercury.lcs.mit.edu> In-Reply-To: <20090923202037.B22736BE5EC@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] The other question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 21:46:45 -0000 Conceptually, I agree. However, there are complications. In general, the longer we put off making a change, the harder it will be for the folks who have to implement it. Bundling several changes together makes very good sense. But, if there is something architectural in the design which will affect future flexibility, then (assuming the WG agrees with that description rather than it just being my delusion about some corner case) it would seem to be necessary to put that sort of change in before RFC publication. The recent discussion of the architectural role of MS/MR devices is one where I do think we need to resolve it before RFC. Testing in the short term probably won't tell us anything, because the issues are all about long term direction and architecture. (To be clear, the resolution may well be that the current approach is right. But I don't think that can be based on "primarily because it is what we already implemented.") At the same time, since it is a long term issue, I have no problem with having an extended discussion over several months, and putting refinements into the same portion of the document (such as Vince's change) so that the interim stuff works better. Yours, Joel Noel Chiappa wrote: > In the process of doing somthing else, I ran across a point that I thought > would probably be useful to point out to the WG as a whole. > > My perception is that the WG is not as good as it could be at paying > attention to the question of _when_ to make changes; it seems to prefer > mostly to focus on _if_ it should make a change. I think that's a big > problem, since playing with that 'when' variable can make a big difference > in the total costs and benefits of the change. > > > The thing is that this WG is in a rather unusual postion, as IETF WG's go > these days, in that it's not the usual 'design before implement' environment. > > There is a sizeable test-bed running this stuff, and we're learning all > sorts of valuable lessons from it, including finding obscure bugs in the > protocol, its interaction with existing infrastructure, etc. LISP will be > running in a complex environment (lots of deployed data-handling > infrastructure, running tunnels, other kinds of boxes, yadda-yadda), and > there's just no substitute for the actual experience the testbed is giving > (and has given us; it's been around for years). > > For a simple protocol, in a simple environment, you might be able to do a > pretty good job with a sheet of paper. In this complex, existing, > environment, experience is critical. > > The downside of a testbed (TANSTAAFL) is that making changes has costs > beyond a new rev of the document. An incompatible change means a flag day > (or days) for the testbed; a large change means that not only do we lose > the test-bed for a while, but also developer attention has to go to doing > the change. > > > So changes have costs. But changing the 'when' can significantly impact those > costs, and so change the cost/benefit ratio of the change. So let's not just > talk about 'if' when it comes to changes, but let's give 'when' prominent > consideration too. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jnc@mercury.lcs.mit.edu Wed Sep 23 15:21: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 BB1EE3A6846 for ; Wed, 23 Sep 2009 15:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 FCwcDCzKeety for ; Wed, 23 Sep 2009 15:21:40 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0EE163A67E3 for ; Wed, 23 Sep 2009 15:21:39 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CAFFD6BE56F; Wed, 23 Sep 2009 18:22:45 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090923222245.CAFFD6BE56F@mercury.lcs.mit.edu> Date: Wed, 23 Sep 2009 18:22:45 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] The other question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 23 Sep 2009 22:21:40 -0000 > From: "Joel M. Halpern" > In general, the longer we put off making a change, the harder it will > be Trust me, I am well aware of that! :-) That's just one more piece of data to go into the 'when' question hopper. > At the same time, since it is a long term issue, I have no problem with > having an extended discussion over several months That's my take too. Changes for architectural reasons tend to be changes whose pay-off is long term - where, almost by definition, you won't lose a lot, in total, if you don't deploy it right away (modulo the issue above). So a noticeable delay in such cases is not necessarily a big problem. > putting refinements into the same portion of the document (such as > Vince's change) so that the interim stuff works better. Just to make sure I understand you: when you say "refinements" above, you mean 'interim refinements', right? Noel From hartmans@mit.edu Thu Sep 24 04:14: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 842233A677C for ; Thu, 24 Sep 2009 04:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 JW8bmdHonHzx for ; Thu, 24 Sep 2009 04:14:11 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 950703A6837 for ; Thu, 24 Sep 2009 04:14:11 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5903E413B; Thu, 24 Sep 2009 07:15:14 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090923170447.DB6076BE5C5@mercury.lcs.mit.edu> From: Sam Hartman Date: Thu, 24 Sep 2009 07:15:14 -0400 In-Reply-To: <20090923170447.DB6076BE5C5@mercury.lcs.mit.edu> (Noel Chiappa's message of "Wed\, 23 Sep 2009 13\:04\:47 -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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 11:14:12 -0000 Speaking as an individual. >>>>> "Noel" == Noel Chiappa writes: Noel> So, with all that in hand, I would like to focus for a second on the first Noel> issue, the encapsulation. Do you have any _technical_ concerns about the Noel> proposed encapsulation change? First, I agree with you that we could treat these as two separate issues. Vince, who has proposed that we do directly has the ability to open a separate issue. You have proposed that we could; if you would like to turn could into do, you are welcome to ask the editors to open a new issue on your behalf. I agree that vince's proposal solves the problem he has. However, I believe that there are two technically better proposals on the table: 1) My fleshing out of Joel's proposal---the long message with changes to map request, an encapsulation procedure and a decapsulation procedure. 2) My proposal that the encapsulation header not include an IP packet, but instead only include some of the fields from an IP packet. ( There has not been a lot of discussion of proposal 2 and it wouldn't surprise me if people didn't see why proposal 2 is better than Vince's. I can describe that if requested. I'd rather focus on proposal 1 because it is so much better in my mind than proposal 2. I think proposal 1 is technically superior to Vince's proposal because it decreases the implementation complexity of the ITR and ETR and because it solves the other part of issue #22. I think solving additional problems is a fine reason to prefer one solution to another. If we explicitly decided that we only want to solve Vince's problem, then his proposal seems like a technically sound way to do that. However, I would object to adopting his proposal now and then later solving the problem of ETRs consuming packets not destined to them. While the problems can be handled separately, it seems that there are solutions that deal with both problems. I understand we're going to have a lot of spec churn, but we should still try to manage it. If we're not ready to handle both of these we could delay until we are. I think it would be fine say to put off both parts off issue #22 until the Atlanta time frame next spring. If I run into additional implementation complexities, I may argue that it is more important than I at first thought. I also don't have a problem solving both now. From jnc@mercury.lcs.mit.edu Thu Sep 24 04:39: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 837203A68DA for ; Thu, 24 Sep 2009 04:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 6Zv1+tWXXVw9 for ; Thu, 24 Sep 2009 04:39:29 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0322C3A696E for ; Thu, 24 Sep 2009 04:39:28 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 694446BE587; Thu, 24 Sep 2009 07:40:36 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090924114036.694446BE587@mercury.lcs.mit.edu> Date: Thu, 24 Sep 2009 07:40:36 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 11:39:34 -0000 > From: Vince Fuller On re-reading this, it strikes me that there's possibly some infelicitous wording here, and it can be read in ways that aren't necessarily what you actually were really thinking. Can I get you to comment on my supposition (below)? > Here's how the LISP co-authors want to resolve the open issue around > the origination and processing of Encapsulated Map Requests by ITRs, > Map-Resolvers, Map-Servers, and ETRs. It strikes me that this could be taken to mean 'this message contains the total sum of what needs to be said about the two separate technical issues raised in this open issue' (#22). The thing is that you go on to talk about a solution to only one of the two issues raised in that tracking issue, i.e. the port number issue: > These changes greatly simplify processing of LISP packets by an ETR: > ... > these changes eliminate any user vs. control message ambiguity for > traffic received by an ETR on port 4341. Furthermore, in a later message: http://www.ietf.org/mail-archive/web/lisp/current/msg01602.html you went on to say: > While I definitely welcome the larger design discussion that you have > opened, I believe it is a bit out of scope for the specific problem > that we are trying to fix with the existing specifications. Can we > agree to fix this problem while we continue discussing the larger issue > of improving the design which seems to indicate you were trying in your fix suggestion to focus on the port number issue, and did not intend to close off discussion of other issues related to Map-Request packet syntax? And in a later message: http://www.ietf.org/mail-archive/web/lisp/current/msg01607.html you said: > a mechanism that requires ETRs to accept and process Map-Requests that > are destined to their owning EID prefixes but not to a specific IP > address configured on a local interface. > ... > it is unrelated to the issue of UDP port 4341 being used for both > control and data packets and should be addressed separately. All of which sounds like you are not averse to discussing these other two issues, provided that it's done in a reasonable way (see below). You also sound like your main focus at this point is asking the same question I tried to ask this morning: does anyone have any technical issues with this proposed solution to the particular technical issues raised by encapsulating LISP control packets in LISP data headers - the reason being that you'd like to get this point settled, so you all can move forward with your testing. Of course, in examing the other two points in this area (of Map-Request packet syntax), the technical reasoning in both areas would need to be carefully examined, and clearly understood by everyone, so that _if_ any change were made, it would be because everyone agreed that there was a good technical reason for doing so. We would also, of course (in line with my point this afternoon) want to carefully consider _when_ to make any such changes, with an eye to scheduling them so that they minimize interference with the ongoing testing efforts. Can you please let me know if I have correctly understood your intent? Thanks.... Noel From mrw@sandstorm.net Thu Sep 24 07:57: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 3DCAD3A69E0 for ; Thu, 24 Sep 2009 07:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-1.127, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_HRDCOR=2.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 sxbprNY59xnR for ; Thu, 24 Sep 2009 07:57:54 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 8B59B3A69DE for ; Thu, 24 Sep 2009 07:57:54 -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 n8OEwjP8016831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Sep 2009 10:58:50 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <95691926-4289-4D95-B200-6AC5E4A1C6B8@sandstorm.net> From: Margaret Wasserman To: John Zwiebel 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, 24 Sep 2009 10:58:45 -0400 References: <20090922152710.4DB176BE553@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 14:57:56 -0000 Hi John, On Sep 23, 2009, at 12:12 AM, John Zwiebel wrote: > On Sep 22, 2009, at 5:47 AM, Margaret Wasserman wrote: > >> True, except you haven't explained why we need this header at all... > > We don't "need" it. There are many ways it could be done. > This was the choice that was made based on experience with the > systems LISP was being built on. > > It is an EXPERIMENT. I think that we may be having some sort of misunderstanding regarding what it means for the LISP WG to publish the LISP specifications as Experimental RFCs. Here is my thinking... There are three ways to get an experimental RFC published: (1) Independent submission to the RFC Editor. In this case, the document would be published as an experimental RFC with limited review by the RFC editor for technical and editorial quality. This would be a non-IETF RFC, and would include an IESG note to that effect. So, if all they wanted to do was get their current specification published as an experimental RFC, so that there would be a stable basis for implementation, this would have been a good choice. (2) AD-Sponsored individual submission. To take this path, the authors would have needed to find an AD who was willing to sponsor the document for publication as an Experimental RFC. It would have gone through AD Review, a 4 week IETF LC (including directorate reviews) and IESG review. When the issues found in those reviews were resolved, it could be published as an IETF Experimental RFC. (3) Form a WG to Refine/Publish the Document. This is the path that was chosen by the authors. In this case, the document becomes a WG document, and will be refined in the WG (based on WG consensus to change it) until the WG has consensus to publish it. At that point, it will go through a 2 week WG LC. It will then be submitted to the IESG and go through AD Review. Because this will be an Experimental RFC from a working group, a 2-week IETF LC is optional. Then it will go to IESG (and directorate) review and be published. The WG path is expected to be the longest of the three paths, because of the need to produce a document that represents the full consensus of the WG, not just of the authors. Given that the LISP authors chose the WG route, it was my understanding that they _wanted_ the LISP RFCs to become WG documents and to be actively developed by the WG. Why else would they have chosen this path? WGs are run in accordance with their charter. Our charter says (with text excerpted to save space): > All proposals > (including LISP) have potentially harmful side-effects to Internet > traffic carried by the involved routers, have parts where deployment > incentives may be lacking, and are NOT RECOMMENDED for deployment beyond > experimental situations at this stage. Many of the proposals have > components (such as the identifier to locator mapping system) where it > is not yet known what kind of design alternative is the best one among > many. > > However, despite these issues it would be valuable to write concrete > protocol specifications and develop implementations that can be used to > understand the characteristics of these designs. The LISP WG is > chartered to work on ... LISP ... with the > given drafts as a starting point. The working group will encourage and > support interoperable LISP implementations as well as defining > requirements for alternate mapping systems. The Working Group will also > develop security profiles for the ALT and/or other mapping systems. > > It is expected that the results of specifying, implementing, and testing > LISP will be fed to the general efforts at the IETF and IRTF (e.g., the > Routing Research Group) that attempts to understand which type of a > solution is optimal. The LISP WG is NOT chartered to develop the final > or standard solution for solving the routing scalability problem. Its > specifications are Experimental and labeled with accurate disclaimers > about their limitations and not fully understood implications for > Internet traffic. This says a few three things to me... (1) We need to add disclaimers to our documents, as described in the charter (please open a separate issue for this). (2) The WG is expected to encourage and support interoperable implementations. To my way of thinking, part of encouraging and supporting interoperable implementations includes modifying the specification to allow implementation on a range of hardware architectures and system types, instead of just reflecting the attributes of the hardware on which it was initially implemented. (3) The WG is expected to write "concrete protocol specifications". To me, this means that our documents should be complete, and represent IETF best practices for good protocol engineering. (4) We are "NOT chartered to develop the final or standard solution". So, it would presumably be okay for there to be open issues in the LISP document (properly labeled and documented) when it is published as an Experimental RFC. Ideally, we'd explore these areas during the experimentation phase, and document our findings in the analysis document. > > IMHO, (note I'm trying to be humble) it is. > > The fact that the ITR sends the control message to the MR first is > just > a simple way of injecting the map-request into the ALT. > > We used to have the ITR actually join the ALT, but then it had to > run BGP over > the ALT. It worked just fine, but the architects thought it could > result in a larger > BGP topology than they wanted. I agree. I understand that this was the history, but there are actually several advantages to having the xTR communicate with the mapping system as a service (rather than joining it). One of the things that the WG is chartered to produce is a set of requirements for other mapping systems (other than the ALT), and I'd like to see us have a sufficiently abstract service interface between the xTRs and the mapping system that it is reasonable to swap out the mapping system, if necessary. While I understand that having the ITR build an ALT packet and tunnel it to the Map Resolver provides some optimization for one current implementation of the Map Resolver, I don't think that is worth the loss of abstraction between the xTRs and the mapping system. It is altogether possible that later implementations of Map Resolvers will be on servers, for example (perhaps side-by-side with a DNS server and a DHCP server?) where the additional encapsulation would have no value at all. >> The fact that that just bashing the address could work points out >> why this type of encapsulation isn't needed at all. The EID for >> the request is already in the Map Request itself, so there isn't >> any need to include it in an encapsulated header. >> > > You -may- be right that it isn't needed. It is just easier to do it > this way. > Its already done and it works. The decision to back up and start over > isn't what I would think would fit into an "experiment" unless there > is > some overwhelming evidence that what already works isn't going to > continue working. It is already done _in one implementation_ and it works. That isn't all that important, IMO... What we should be striving for is something that represents good protocol engineering, meets WG consensus, can work on a wide variety of systems, and is implemented in multiple interoperable implementations. I am not interested in randomly invalidating existing code, but I strong object to valuing existing code in the Cisco implementation as highly as you imply. I believe that anyone who implements a specification _before_ bringing it to an IETF WG should anticipate many rounds of significant changes to their code. Also, I think it is wrong to value the inconvenience of one set (or even a few sets) of early implementors over good protocol engineering, the ability to implement this specification efficiently on a wide variety of systems. >> What Vince has proposed does the exact _opposite_ of isolating the >> xTRs from the mapping system, as they are required to build mapping- >> system-specific requests (using EIDs as destination addresses) and >> then encapsulate them to get them to the mapping system. > > This is extremely simple. Much, much easier than having to be a > member of the ALT. > In any case, its hard for me to imagine how it could be easier for > the ITR to build > the map-request. Seems to me that exactly the same information will > have to be sent > even if it is in a different format. You seem to be comparing the current text to a choice that isn't on the table any longer, having the ITR join the ALT. Instead, you should be comparing two proposals for how ITRs will send Map-Requests: Vince's proposal (with the Map-Request encapsulated in a new type of LISP control message) or Joel's proposal (with the Map- Request unencapsulated). Also, the problem described in issue #22 is not about how hard (or easy) it is for the ITR to build the request, so I don't know why you are focusing on that. The issue is about the trade-off between: - The effort required by the MR to receive the request and send/ forward it onto the ALT. - The effort required by the ETR to receive, process and respond to the request. Vince's proposal makes things easier for the MR -- the MR receives an encapsulated ALT packet, and simply has to strip the outer header and forward the packet on the ALT. With Joel's proposal, the MR would need to look at the contents of the Map-Request, in order to determine where to send it. This requires LISP-specific processing on the MR. So, Vince's proposal requires less processing on MR's, and makes it significantly easier to implement an MR on a currently deployed BGP router with limited software changes. Vince's proposal makes it harder to properly implement an ETR, though. The ETR receives an encapsulated packet to the control port. It needs to do something to decapsulate that packet. While this may seem simple, because it can just strip off the outer headers, it is not that simple to do this in a way that is RFC compliant, because the ETR also needs to do some checks on the inner header (such as checking the inner header IP address(es), IP checksum, UDP checksum and TTL fields) _before_ it processes the packet. The easiest way to do this would be to pass the encapsulated packet back through the IP recieve portion of an IP stack, but that won't work with the packets in Vince's proposal, because the inner header is not addressed to the local stack, so the stack will throw the packet away. So, it necessary to write LISP-specific code (or LISP-specific mods to the stack) to handle the inner IP/UDP headers. Do you see why this is difficult? Are these issues currently handled correctly in the Cisco implementation? With Joel's proposal, the ETR receives an unencapsulated packet that is addressed to itself. >> I also don't think it is realistic that the MR/MS will remain as >> simple as you describe, nor do I believe that it is possible (or >> even desirable) for the MR or the MS to have no LISP-specific code. > > This is an argument without any basis. There are no alternate > proposals that don't have > LISP-specific code. I find it very hard to understand how a LISP > map-request could be > processed by any system that didn't have "LISP-specific code". I was responding to Dino's assertion that the MR/MS could currently be implemented with no LISP-specific code. I will take your response as agreeing with me that Dino's assertion is incorrect. Margaret From dino@cisco.com Thu Sep 24 08:08: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 810243A6887 for ; Thu, 24 Sep 2009 08:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 colq27iWj0mq for ; Thu, 24 Sep 2009 08:08:16 -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 8EDBE3A6842 for ; Thu, 24 Sep 2009 08:08:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGsou0qrR7PD/2dsb2JhbAC/F4hQAY9uBYQb X-IronPort-AV: E=Sophos;i="4.44,445,1249257600"; d="scan'208";a="395320542" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Sep 2009 15:09:25 +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 n8OF9PU8020912; Thu, 24 Sep 2009 08:09:25 -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 n8OF9PCU023056; Thu, 24 Sep 2009 15:09:25 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, 24 Sep 2009 08:09:25 -0700 Received: from [192.168.1.2] ([10.21.79.207]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 08:09:24 -0700 Message-Id: From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <95691926-4289-4D95-B200-6AC5E4A1C6B8@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, 24 Sep 2009 08:09:24 -0700 References: <20090922152710.4DB176BE553@mercury.lcs.mit.edu> <95691926-4289-4D95-B200-6AC5E4A1C6B8@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Sep 2009 15:09:25.0158 (UTC) FILETIME=[00E71C60:01CA3D29] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1744; t=1253804965; x=1254668965; 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=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=zp62WuDaeVTBcq6GSOLmD3WMc+BWXBxBmv6nP2XlJO0=; b=ZfKKgfFtlpKNSRaf4hqSgzVVNPSmVWr7cJZZx3jTHSq9fih/pSFn9BxFhj f6cpu2pylDjHCbLr/SYlyw+6gUO2XT3vfCBhcXO8sACaJeLsrVwzsCbpQdIE zP4Y2z2EzQ; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 15:08:17 -0000 > Vince's proposal makes it harder to properly implement an ETR, > though. The ETR receives an encapsulated packet to the control > port. It needs to do something to decapsulate that packet. While > this may seem simple, because it can just strip off the outer > headers, it is not that simple to do this in a way that is RFC > compliant, because the ETR also needs to do some checks on the inner > header (such as checking the inner header IP address(es), IP > checksum, UDP checksum and TTL fields) _before_ it processes the > packet. The easiest way to do this would be to pass the > encapsulated packet back through the IP recieve portion of an IP > stack, but that won't work with the packets in Vince's proposal, > because the inner header is not addressed to the local stack, so the > stack will throw the packet away. So, it necessary to write LISP- > specific code (or LISP-specific mods to the stack) to handle the > inner IP/UDP headers. Do you see why this is difficult? Are these > issues currently handled correctly in the Cisco implementation? With > Joel's proposal, the ETR receives an unencapsulated packet that is > addressed to itself. Like I already mentioned, the outer header is processed by the protocol stack. The destination is addressed to the ETR. The destination port of 4342 causes the socket layer to deliver the packet to the LISP client. The LISP client then parses the packet. You do not have to take the inner header and give it back to the protocol stack. That makes for a more complicated implementation. The prototype implementation can handle this fine and the code has been running for at least 6 months this way. Dino From mrw@sandstorm.net Thu Sep 24 08:12: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 8A9ED3A68CE for ; Thu, 24 Sep 2009 08:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.032, 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 OHmPGy1607+C for ; Thu, 24 Sep 2009 08:12:57 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id B4BE63A6890 for ; Thu, 24 Sep 2009 08:12: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 n8OFE4Kb017507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 24 Sep 2009 11:14:04 -0400 (EDT) (envelope-from mrw@sandstorm.net) 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 v936) Date: Thu, 24 Sep 2009 11:14:04 -0400 X-Mailer: Apple Mail (2.936) Subject: [lisp] New Issues: Documents need disclaimers (see Charter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 15:12:58 -0000 I stuck a new issue into the middle of my last message to John, but I'm afraid the folks who enter issues will miss it, so here it is... Our charter requires that our documents contain "accurate disclaimers about their limitations and not fully understood implications for Internet traffic." The charter also says that LISP is "NOT RECOMMENDED for deployment beyond experimental situations at this stage." So, we need to include a disclaimer in the LISP documents. I'd suggest that we add a new section after section 1. in all of the WG documents, like this: "2. Disclaimer The LISP protocol and associated specifications are being published as Experimental RFCs, so that the Internet community can have concrete specification to experiment with LISP, and with the more general concept of how ID/Locator separation protocols can improve route scaling in the Internet. LISP is NOT RECOMMENDED for deployment beyond experimental situations at this stage." If we identify specific issues (such as security or operational issues) that would make it inadvisable to deploy list on an operational network in its published form, we can include those issues as additional paragraphs in this section. Thoughts? Margaret From mrw@sandstorm.net Thu Sep 24 08:25: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 A38AB3A695A for ; Thu, 24 Sep 2009 08:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.032, 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 HO8G-ScFjd2k for ; Thu, 24 Sep 2009 08:25:05 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id CF1013A6937 for ; Thu, 24 Sep 2009 08:25:04 -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 n8OFOo5E017950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Sep 2009 11:24:50 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <51E09F9E-82C3-48EF-AAC3-D0B0C666EC61@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 v936) Date: Thu, 24 Sep 2009 11:24:49 -0400 References: <20090922152710.4DB176BE553@mercury.lcs.mit.edu> <95691926-4289-4D95-B200-6AC5E4A1C6B8@sandstorm.net> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 15:25:05 -0000 On Sep 24, 2009, at 11:09 AM, Dino Farinacci wrote: > The prototype implementation can handle this fine and the code has > been running for at least 6 months this way. Do you mean your/Cisco's implementation? Or is "the prototype implementation" something else? Does your implementation perform the following checks on the inner packet: - Check the IP header version - Check the IP header checksum - Check the UDP checksum - Process any IP options/extension headers that might affect processing of this packet - Check the TTL, and return an ICMP error if it is expired Although I realize it is possible to do these checks in my LISP code, I'd personally prefer to have this type of checking and error handling performed by the IP stack, which would be possible with Joel's proposal and not with Vince's. That would make an ETR easier to implement. I think this is similar to your desire to make an MR easier to implement, by allowing it to just decapsulate and send the Map- Request, without having to parse any of the Map-Request fields. Obviously you _know how_ to write code that can parse the Map-Request fields, you would just prefer not to do it in the MR. Margaret From mrw@sandstorm.net Thu Sep 24 08: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 43CF63A6928 for ; Thu, 24 Sep 2009 08:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.031, 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 NB9gGrEuEwS0 for ; Thu, 24 Sep 2009 08:32:12 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 520513A695C for ; Thu, 24 Sep 2009 08:32: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 n8OFWvxV018447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Sep 2009 11:32:57 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Margaret Wasserman In-Reply-To: <51E09F9E-82C3-48EF-AAC3-D0B0C666EC61@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, 24 Sep 2009 11:32:56 -0400 References: <20090922152710.4DB176BE553@mercury.lcs.mit.edu> <95691926-4289-4D95-B200-6AC5E4A1C6B8@sandstorm.net> <51E09F9E-82C3-48EF-AAC3-D0B0C666EC61@sandstorm.net> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 15:32:13 -0000 One more question... What do you do if the inner header indicates that the packet has been fragmented? Margaret On Sep 24, 2009, at 11:24 AM, Margaret Wasserman wrote: > > On Sep 24, 2009, at 11:09 AM, Dino Farinacci wrote: > >> The prototype implementation can handle this fine and the code has >> been running for at least 6 months this way. > > Do you mean your/Cisco's implementation? Or is "the prototype > implementation" something else? > > Does your implementation perform the following checks on the inner > packet: > > - Check the IP header version > - Check the IP header checksum > - Check the UDP checksum > - Process any IP options/extension headers that might affect > processing of this packet > - Check the TTL, and return an ICMP error if it is expired > > Although I realize it is possible to do these checks in my LISP > code, I'd personally prefer to have this type of checking and error > handling performed by the IP stack, which would be possible with > Joel's proposal and not with Vince's. That would make an ETR easier > to implement. > > I think this is similar to your desire to make an MR easier to > implement, by allowing it to just decapsulate and send the Map- > Request, without having to parse any of the Map-Request fields. > Obviously you _know how_ to write code that can parse the Map- > Request fields, you would just prefer not to do it in the MR. > > Margaret > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Thu Sep 24 08:45: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 C69AA3A695A for ; Thu, 24 Sep 2009 08:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, 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 Iw63w2ItwIaw for ; Thu, 24 Sep 2009 08:45: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 A6DE03A6823 for ; Thu, 24 Sep 2009 08:45:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI4xu0qrR7MV/2dsb2JhbAC/EohQAY9zBYIzgWg X-IronPort-AV: E=Sophos;i="4.44,446,1249257600"; d="scan'208";a="246448736" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 24 Sep 2009 15:45:41 +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 n8OFjfLh012650; Thu, 24 Sep 2009 08:45:41 -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 n8OFjdM7017248; Thu, 24 Sep 2009 15:45:41 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, 24 Sep 2009 08:45:40 -0700 Received: from [192.168.1.2] ([10.21.79.207]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 08:45:39 -0700 Message-Id: <8DAA343B-F515-4409-A902-73171DF54D3A@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <51E09F9E-82C3-48EF-AAC3-D0B0C666EC61@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, 24 Sep 2009 08:45:39 -0700 References: <20090922152710.4DB176BE553@mercury.lcs.mit.edu> <95691926-4289-4D95-B200-6AC5E4A1C6B8@sandstorm.net> <51E09F9E-82C3-48EF-AAC3-D0B0C666EC61@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Sep 2009 15:45:40.0139 (UTC) FILETIME=[114ADFB0:01CA3D2E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3183; t=1253807141; x=1254671141; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=20Requests |Sender:=20; bh=oC5zG07UR6J7V0XEJpnTljSQyciFpbKlIIDagQAuPlQ=; b=TXVSescF7+4fTNrsmPzaiwpBXNCPI4rdHLE7we7gDxfCvPnpVVvL4CfH/0 yrOHEqAH1oo3Z36D/sJ0Z/jsmAzdjgWvZVRhHDwfYgP4uBUwZtFZ2xm4F5mU Sy+fg6pmPUlrqIdITVq5ZkmSjTwI2N2KfIPK6fby5fEwspp2JScR0=; 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] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 15:45:06 -0000 > On Sep 24, 2009, at 11:09 AM, Dino Farinacci wrote: > >> The prototype implementation can handle this fine and the code has >> been running for at least 6 months this way. > > Do you mean your/Cisco's implementation? Or is "the prototype > implementation" something else? The implementation written by cisco employees yes. > Does your implementation perform the following checks on the inner > packet: > > - Check the IP header version Yes. > - Check the IP header checksum Yes. > - Check the UDP checksum Yes. > - Process any IP options/extension headers that might affect > processing of this packet Doesn't process options because the Map-Request is sent with no options (and spec'ed that way). So if options are received, we jump over them to get to the UDP header. > - Check the TTL, and return an ICMP error if it is expired Since the inner TTL is copied to the outer TTL and the packet was received by the ETR (i.e. the unencapsulated Map-Request traveled through the ALT before the TTL went to 0) it accepts it. When the packet is received with a TTL of 0, it accepts it (i.e. if the destination EID matches one of the local EID-prefixes). > Although I realize it is possible to do these checks in my LISP > code, I'd personally prefer to have this type of checking and error > handling performed by the IP stack, which would be possible with > Joel's proposal and not with Vince's. That would make an ETR easier > to implement. Well that is fine if you have a preference, but this shouldn't be a show-stopper for the mechanism. Please note all the features we could lose if we do the Joel proposal. I outlined that in a previous email a couple days ago. The Joel proposal doesn't have sufficient detail to evaluate the features I outlined will still be supported. > I think this is similar to your desire to make an MR easier to > implement, by allowing it to just That is a positive point but that isn't my main desire. The main desire is to give the user the ability to use different vendor equipment on the ALT. And let me repeat, putting an EID in the destination field does not make assumptions that ALT is used for the mapping database mechanism. The key for a "table lookup" for any kind of database mechanism is in the IP header. It makes it convenient for the mapping database system to access that key. Please note, the priority here are the features the current design is providing for the network and the dominant point shouldn't be to make easier implementations. Yes, we want the implementations to be easier to implement but not at a cost of losing services. > decapsulate and send the Map-Request, without having to parse any of > the Map-Request fields. Obviously you _know how_ to write code that > can parse the Map-Request fields, you would just prefer not to do it > in the MR. Right, so you are concluding that the differences are minimal from an implementation point of view. But we don't know how the new proposal can deliver the services the current design can provide. Dino From vaf@cisco.com Thu Sep 24 09:48: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 F13773A6A01 for ; Thu, 24 Sep 2009 09:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 iRxsQa5riYzY for ; Thu, 24 Sep 2009 09:48:54 -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 0EE2F3A6A82 for ; Thu, 24 Sep 2009 09:48:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ8/u0qrR7O6/2dsb2JhbAC/PohQAY96BYIlgXaKZQ X-IronPort-AV: E=Sophos;i="4.44,446,1249257600"; d="scan'208";a="207955020" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 24 Sep 2009 16:50:02 +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 n8OGo19T025106; Thu, 24 Sep 2009 09:50:01 -0700 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8OGo1P7018123; Thu, 24 Sep 2009 16:50:01 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 n8OGgTLu020061; Thu, 24 Sep 2009 09:42:29 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n8OGgTaU020058; Thu, 24 Sep 2009 09:42:29 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Thu, 24 Sep 2009 09:42:29 -0700 From: Vince Fuller To: Noel Chiappa Message-ID: <20090924164229.GC17122@vaf-lnx1> References: <20090924114036.694446BE587@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090924114036.694446BE587@mercury.lcs.mit.edu> User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3830; t=1253811001; x=1254675001; c=relaxed/simple; s=sjdkim2002; 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]=20proposed=20fix=20issue=20#22=2 0-=20processing=20of=20Encapsulated=20Map=0A=09Requests |Sender:=20; bh=yyq4L2LDO7fX4BbHXHyiXj9G+Wy1YuwY2civAm37V9c=; b=NRS/HkM5yPl3YAmmGiUzr0AGsPNnU24CwOQe88wK6TrVSe4B1qVgh8jxmJ o58fXIzVqHpZFZ3EkRB4X1xdX2+UTmsh8B7Rw/T0CkJk2LbulnPxT6IoKayc NKMezQgA8S; Authentication-Results: sj-dkim-2; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 16:48:56 -0000 > > Here's how the LISP co-authors want to resolve the open issue around > > the origination and processing of Encapsulated Map Requests by ITRs, > > Map-Resolvers, Map-Servers, and ETRs. > > It strikes me that this could be taken to mean 'this message contains the > total sum of what needs to be said about the two separate technical issues > raised in this open issue' (#22). My mistake. The intention of the proposal from the LISP co-authors is to fix the problem of using UDP port 4341 for both user traffic and LISP control messages (Encapsulated Map Reqeusts). That was a mistake in the original LISP-MS design and creates some obvious implementation difficulties. While LISP implementors did independently discover this problem the LISP co-authors also appreciate the discussion raised on this mailing list. > > While I definitely welcome the larger design discussion that you have > > opened, I believe it is a bit out of scope for the specific problem > > that we are trying to fix with the existing specifications. Can we > > agree to fix this problem while we continue discussing the larger issue > > of improving the design > > which seems to indicate you were trying in your fix suggestion to focus on > the port number issue, and did not intend to close off discussion of other > issues related to Map-Request packet syntax? Correct. Not fixing the port number issue is blocking work on experimenting with multiple, interoperable implementations. > > a mechanism that requires ETRs to accept and process Map-Requests that > > are destined to their owning EID prefixes but not to a specific IP > > address configured on a local interface. > > ... > > it is unrelated to the issue of UDP port 4341 being used for both > > control and data packets and should be addressed separately. > > All of which sounds like you are not averse to discussing these other two > issues, provided that it's done in a reasonable way (see below). You also > sound like your main focus at this point is asking the same question I tried > to ask this morning: does anyone have any technical issues with this proposed > solution to the particular technical issues raised by encapsulating LISP > control packets in LISP data headers - the reason being that you'd like to > get this point settled, so you all can move forward with your testing. Correct. Thank you for your clarifying message. > Of course, in examing the other two points in this area (of Map-Request > packet syntax), the technical reasoning in both areas would need to be > carefully examined, and clearly understood by everyone, so that _if_ any > change were made, it would be because everyone agreed that there was a good > technical reason for doing so. We would also, of course (in line with my > point this afternoon) want to carefully consider _when_ to make any such > changes, with an eye to scheduling them so that they minimize interference > with the ongoing testing efforts. I agree. A major change in Map-Request packet syntax and semantics is going to require a lot more consideration and analysis than a simple change to the UDP port number used with the current design. I ask that the latter not be blocked by a lengthy discussion of the former. Sam's specific suggestion that any decision on either of these issues be delayed until the spring IETF is completely unacceptable. As Dino has emphasized, the work we are doing on LISP is Experimental; we need to be able to make changes and experiment, not stop all progress on interoperable implementation for six months of navel- gazing. > Can you please let me know if I have correctly understood your intent? > Thanks.... Yes. Again, thanks for clarifying. --Vince From mrw@sandstorm.net Thu Sep 24 10:27: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 CE6313A6A5F for ; Thu, 24 Sep 2009 10:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.031, 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 MfuRk6wbJOac for ; Thu, 24 Sep 2009 10:27:41 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 0363A3A6877 for ; Thu, 24 Sep 2009 10:27: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 n8OHSltK024427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 24 Sep 2009 13:28:47 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <18A9FE09-5D81-4A60-AB66-E31297DF083C@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 v936) Date: Thu, 24 Sep 2009 13:28:46 -0400 X-Mailer: Apple Mail (2.936) Subject: [lisp] My Position on Vince's Proposal and Issue #22... X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 17:27:41 -0000 Sam just asked me a question about this situation that made it clear that he didn't know where I stand on Vince's changes vs. additional changes to address issue #22, so I thought I should clarify that... I proposed that we open a new issue #NN: Encapsulated Control and Data Packets Shouldn't Use the Same Port. I think that is clearly a problem, and that Vince's proposal fixes it. Although I prefer Joel's proposal because it resolves both issues #NN and #22, I don't have any major objection to Vince's proposal. So, I wouldn't object to including Vince's proposal in -05 and closing issue #NN. I believe that Vince's proposal is related to, but does not actually address, issue #22. This issue could be resolved by adopting Joel's proposal, or by other means. So, if we include Vince's proposal in -05, then issue #22 should remain open and be resolved (however we end up deciding to resolve it) before we send the draft to the IESG for publication. I am a little bit disturbed by adding a message type (Encapsulated Message) that we may just end-up removing later if the encapsulation goes away, but I don't consider that to be a blocking issue. Margaret From dino@cisco.com Thu Sep 24 11:36: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 B18AE3A6A11 for ; Thu, 24 Sep 2009 11:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 8-R4bQNQjvoz for ; Thu, 24 Sep 2009 11:36:03 -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 C56373A6967 for ; Thu, 24 Sep 2009 11:36:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO9Yu0qrR7PE/2dsb2JhbAC/MYhTAZAKBYQc X-IronPort-AV: E=Sophos;i="4.44,446,1249257600"; d="scan'208";a="192079259" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2009 18:37:05 +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 n8OIb5cB014571; Thu, 24 Sep 2009 11:37:05 -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 n8OIb5rj019983; Thu, 24 Sep 2009 18:37:05 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, 24 Sep 2009 11:37:05 -0700 Received: from dhcp-171-70-235-225.cisco.com ([171.70.235.225]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 11:37:04 -0700 Message-Id: <1CB12E33-6CC5-406B-88F6-30A8EBA03C39@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <18A9FE09-5D81-4A60-AB66-E31297DF083C@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, 24 Sep 2009 11:37:03 -0700 References: <18A9FE09-5D81-4A60-AB66-E31297DF083C@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Sep 2009 18:37:04.0833 (UTC) FILETIME=[0372A310:01CA3D46] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1683; t=1253817425; x=1254681425; 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]=20My=20Position=20on=20Vince's=2 0Proposal=20and=20Issue=20#22... |Sender:=20; bh=ahzEcPvxDYZO9eH7RQZZRGz7DKZPK2gO69issZAb314=; b=HK4pWklX/JuunHwFFfMY0c/YtwOKvW2iBEc8FL+yjTgMtVFhcjd1GOrZJg Q+HuAd7ssnbVsnBJsG34kaXwrbeuvms08kYH5RLqRbxvCIKdaQcyZX3jaGvX 6IQY+yM1M1; 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] My Position on Vince's Proposal and Issue #22... X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 18:36:04 -0000 Thanks Margaret for being open minded. I hope we can reach consensus on #NN. As for what you are distributed about, that encapsulation could be used if the MR was encapsulating for Joel's proposal. Dino On Sep 24, 2009, at 10:28 AM, Margaret Wasserman wrote: > > Sam just asked me a question about this situation that made it clear > that he didn't know where I stand on Vince's changes vs. additional > changes to address issue #22, so I thought I should clarify that... > > I proposed that we open a new issue #NN: Encapsulated Control and > Data Packets Shouldn't Use the Same Port. I think that is clearly a > problem, and that Vince's proposal fixes it. Although I prefer > Joel's proposal because it resolves both issues #NN and #22, I don't > have any major objection to Vince's proposal. So, I wouldn't object > to including Vince's proposal in -05 and closing issue #NN. > > I believe that Vince's proposal is related to, but does not actually > address, issue #22. This issue could be resolved by adopting Joel's > proposal, or by other means. So, if we include Vince's proposal in > -05, then issue #22 should remain open and be resolved (however we > end up deciding to resolve it) before we send the draft to the IESG > for publication. > > I am a little bit disturbed by adding a message type (Encapsulated > Message) that we may just end-up removing later if the encapsulation > goes away, but I don't consider that to be a blocking issue. > > Margaret > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Thu Sep 24 11:55: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 C9A623A68D3 for ; Thu, 24 Sep 2009 11:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 RSdMrlepCQZc for ; Thu, 24 Sep 2009 11:55:33 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id EDA3B3A68A0 for ; Thu, 24 Sep 2009 11:55:32 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1260D6BE59B; Thu, 24 Sep 2009 14:56:40 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090924185641.1260D6BE59B@mercury.lcs.mit.edu> Date: Thu, 24 Sep 2009 14:56:40 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 18:55:33 -0000 > From: Vince Fuller > Not fixing the port number issue is blocking work on experimenting > with multiple, interoperable implementations. Ah, thanks for that info; I think some people were wondering why this needed to get done right away, and that certainly counts as a good reason. >> Of course, in examing the other two points in this area (of >> Map-Request packet syntax), the technical reasoning in both areas >> would need to be carefully examined, and clearly understood by >> everyone, so that _if_ any change were made, it would be because >> everyone agreed that there was a good technical reason for doing so. I would just like to re-emphasize this last point again; I have come to realize, over the last couple of days, that I really don't understand in enough detail why things are they way they are at the moment. It might well be that, once we understand the design rationale for the prior design, that we might decide that it was in fact _still_ the right thing. Or maybe not; I think we all need to understand all the facets a little better. > I agree. A major change in Map-Request packet syntax and semantics > pis going to require a lot more consideration and analysis than a simple > change to the UDP port number used with the current design. Exactly. > I ask that the latter not be blocked by a lengthy discussion of the > former. I think that there is general understanding that, in a process like this, where we have an experimental system, sometimes 'interim fixes' are needed. The concern with interim fixes (and it's general, not limited to this particular one) seems to be that if we do an interim fix to something, that will put us in a place where it works 'well enough', and there will never be the impetus to go back and fix it 'right' - at least, until it's too late. Which I can sympathize with... (Can you say '32 bit IP addresses'? That was an interim fix, too....) So if you all are definitely OK with coming back to look at the larger picture down the road a bit, I think that would relieve the concerns some people have about going ahead with this particular interim fix. Noel From jari.arkko@piuha.net Thu Sep 24 12:26: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 7A9263A6922 for ; Thu, 24 Sep 2009 12:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 9m-uhM1usHI6 for ; Thu, 24 Sep 2009 12:26:32 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8D80C3A68C9 for ; Thu, 24 Sep 2009 12:26:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 50D58D4943; Thu, 24 Sep 2009 22:27:41 +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 Nr1AF8ZlgY1Y; Thu, 24 Sep 2009 22:27:40 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D411DD4922; Thu, 24 Sep 2009 22:27:39 +0300 (EEST) Message-ID: <4ABBC82A.7030106@piuha.net> Date: Thu, 24 Sep 2009 22:27:38 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Sam Hartman References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> <20090921204855.GA7205@1-4-5.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org, Robin Whittle , Noel Chiappa Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 19:26:33 -0000 This working group is not chartered to develop solutions to the IPv4-IPv6 transition problem. We have plenty of other working groups in that space already. Of course, I understand that pretty much any tunneling or translation technique can be used for IPv6 deployment as well. I do not mind if such use case gets mentioned in a list of other potential uses of Lisp. However, the main use case, deployment rationale, etc. needs to stand on its own and talk about routing scalability, traffic engineering, and other things central to Lisp. I also understand that what we develop technology X for may not be what it eventually gets used for; we've been surprised before. Lets see what happens with Lisp. But for the RFCs that come out of this working group, lets focus on the initial main reason why Lisp was developed. Jari From jnc@mercury.lcs.mit.edu Thu Sep 24 12:30: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 C54183A697F for ; Thu, 24 Sep 2009 12:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.295 X-Spam-Level: X-Spam-Status: No, score=-6.295 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, J_CHICKENPOX_41=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 nnulsSvNaLr3 for ; Thu, 24 Sep 2009 12:30:52 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id D2B5E3A6A0B for ; Thu, 24 Sep 2009 12:30:51 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 916F36BE5EB; Thu, 24 Sep 2009 15:31:55 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090924193155.916F36BE5EB@mercury.lcs.mit.edu> Date: Thu, 24 Sep 2009 15:31:55 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] My Position on Vince's Proposal and Issue #22... X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 19:30:57 -0000 > From: Margaret Wasserman > I proposed that we open a new issue #NN: Encapsulated Control and > Data Packets Shouldn't Use the Same Port. I think there's a general sense that this is a good idea? Actually, I would suggest that there are three separate-but-related issues here: i - Encapsulated control packets on the data port ii - Use of a group EID as the destination IP address iii - Encapsulation of Map-Request packets on the ITR-> and ->ETR hops Re-reading #22 again, the text starts out by saying "Two aspects of the MS protocol require that an ETR consume packets not addressed to it." So that doesn't seem to cover iii). I think it might help to have three separate issues; sorry if this seems excessive, but this is all so crazy by now, I think the smaller the pieces, the better. Also, I gather from various offline conversations that both ii) and iii) _are_ a problem for some now, _but_ that there are internal workarounds (albeit kludgy) for them both. Which means there's nothing in any of the other two which people just _cannot_ work around, if I'm understanding things correctly? So is it OK to just do those kludges for the moment, as interim fixes, and later we'll come back and look at the larger issues in a measured, careful way? > I don't have any major objection to Vince's proposal. So, I wouldn't > object to including Vince's proposal in -05 and closing issue #NN. Good, that's what I think makes the most sense. Hopefully, once we're sure there won't be a problem with the interim fix for port number thing causing us to never come back to the others (and that 'once we're sure' could be right away, as soon as everyone digests the latest round of email), we can go right ahead and, as suggested above, "includ[e your] proposal in -05 and clos[e the port] issue". > if we include Vince's proposal in -05, then issue #22 should remain > open and be resolved (however we end up deciding to resolve it) > before we send the draft to the IESG for publication. Exactly; at some point down the road, when we have time to ponder it. Is this OK with everyone? Noel From mrw@sandstorm.net Thu Sep 24 12:49: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 3D24B3A6863 for ; Thu, 24 Sep 2009 12:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.031, 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 0R7mgLhRtP-E for ; Thu, 24 Sep 2009 12:49:13 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 6A6863A67CF for ; Thu, 24 Sep 2009 12:49:13 -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 n8OJo5H6031748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Sep 2009 15:50:09 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <82797CE0-21B0-4788-8000-0E3B1CE96DF0@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090924193155.916F36BE5EB@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: Thu, 24 Sep 2009 15:50:05 -0400 References: <20090924193155.916F36BE5EB@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] My Position on Vince's Proposal and Issue #22... X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 19:49:14 -0000 Hi Noel, On Sep 24, 2009, at 3:31 PM, Noel Chiappa wrote: > > i - Encapsulated control packets on the data port > ii - Use of a group EID as the destination IP address > iii - Encapsulation of Map-Request packets on the ITR-> and ->ETR hops > > I think it might help to have three separate issues; sorry if this > seems > excessive, but this is all so crazy by now, I think the smaller the > pieces, the better. I agree. We should open these three issues separately. I think I also agree with the rest of your reasoning, with the assumption that "when we have time to ponder" the other two issues will be before we send the RFC for publication. Margaret From jnc@mercury.lcs.mit.edu Thu Sep 24 12:58: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 120853A6A0D for ; Thu, 24 Sep 2009 12:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 tXMWcNsd78N7 for ; Thu, 24 Sep 2009 12:58:33 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 638CC3A6A0B for ; Thu, 24 Sep 2009 12:58:33 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 548186BE5C9; Thu, 24 Sep 2009 15:59:42 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090924195942.548186BE5C9@mercury.lcs.mit.edu> Date: Thu, 24 Sep 2009 15:59:42 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] My Position on Vince's Proposal and Issue #22... X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 19:58:34 -0000 > From: Margaret Wasserman > I think I also agree with the rest of your reasoning, with the > assumption that "when we have time to ponder" the other two issues > will be before we send the RFC for publication. Well, I suspect the IESG will bounce it unless we either i) clearly explain why this is the Right Thing, or ii) do something different, so yeah! :-) Noel From hartmans@mit.edu Thu Sep 24 13:01: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 8A0413A6975 for ; Thu, 24 Sep 2009 13:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=-0.108, 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 o7qJ56dWAy8n for ; Thu, 24 Sep 2009 13:01:55 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id D168F3A6A0B for ; Thu, 24 Sep 2009 13:01:55 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 111DB413B; Thu, 24 Sep 2009 16:03:02 -0400 (EDT) To: Dino Farinacci References: <18A9FE09-5D81-4A60-AB66-E31297DF083C@sandstorm.net> <1CB12E33-6CC5-406B-88F6-30A8EBA03C39@cisco.com> From: Sam Hartman Date: Thu, 24 Sep 2009 16:03:02 -0400 In-Reply-To: <1CB12E33-6CC5-406B-88F6-30A8EBA03C39@cisco.com> (Dino Farinacci's message of "Thu\, 24 Sep 2009 11\:37\:03 -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] My Position on Vince's Proposal and Issue #22... X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 20:01:56 -0000 >>>>> "Dino" == Dino Farinacci writes: Dino> Thanks Margaret for being open minded. Dino> I hope we can reach consensus on #NN. I think we've reached rough consensus on #nn assuming it gets opened. I seem to be the only one with an objection. From jnc@mercury.lcs.mit.edu Thu Sep 24 13:10: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 B63C43A6987 for ; Thu, 24 Sep 2009 13:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 D-nVsKUBso8X for ; Thu, 24 Sep 2009 13:10: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 C28943A6946 for ; Thu, 24 Sep 2009 13:10:20 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 405FC6BE5C9; Thu, 24 Sep 2009 16:11:29 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090924201129.405FC6BE5C9@mercury.lcs.mit.edu> Date: Thu, 24 Sep 2009 16:11:29 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] My Position on Vince's Proposal and Issue #22... X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 20:10:21 -0000 > From: Sam Hartman > I think we've reached rough consensus on #nn assuming it gets opened. I think Darrel's going to be doing the paperwork honours, if I understand correctly. Anyway, good! Now I can go have my breakfast! :-) Noel From trac@tools.ietf.org Thu Sep 24 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 7F1673A6946 for ; Thu, 24 Sep 2009 13:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, 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 jv8zCKQcqePz for ; Thu, 24 Sep 2009 13:15:31 -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 918773A6958 for ; Thu, 24 Sep 2009 13:15:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Mquk4-00061K-1s; Thu, 24 Sep 2009 13:16:40 -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, 24 Sep 2009 20:16:39 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/24 Message-ID: <057.9ff186693c7cb938e3dcb5fc65bd8b4c@tools.ietf.org> X-Trac-Ticket-ID: 24 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: darlewis@cisco.com, 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] #24: Encapsulated control packets on the LISP data port 4341 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, 24 Sep 2009 20:15:32 -0000 #24: Encapsulated control packets on the LISP data port 4341 -------------------------------+-------------------------------------------- Reporter: darlewis@cisco.com | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- Problem summary: LISP implementors and lisp@ietf.org list members have independently found a design and implementation issue with the origination and processing of Encapsulated Map-Requests. The LISP team proposes changes to both the base LISP specification (currently, draft-ietf-lisp-04.txt) and to LISP-MS (draft-ietf-lisp-ms-02.txt) to address this. Since LISP Multicast (draft-ietf-lisp-multicast-01.txt) also uses problematic encapsulation for certain control traffic, it will also need to be modified. Background: The current LISP-MS document (draft-ietf-lisp-ms-02) states that an ITR sending a Map-Request to a Map-Resolver sets the destination IP address of the message to the EID it is requesting and the destination UDP port number to 4342 (LISP-CONTROL). The ITR then adds an additional IP+LISP header using the Map-Resolver RLOC as the destination IP address and UDP destination port 4341 (LISP-DATA). The message is sent to a configured Map-Resolver which decapsulates the Map-Request and forwards it on to the ALT. If the destination LISP site is using a Map-Server, the Map-Server receives the Map-Request on the ALT then re-encapsulates the message with an IP+LISP header using the RLOC of the ETR registered for that EID as the destination IP address and UDP destination port 4341 (LISP-DATA). Why the extra encpaulsation from ITR to MR and from MS to ETR? When an ITR is using a Map-Resolver, the ITR is not connected to the ALT and therefore has no way to route control messages destined to an EID. For this reason, the ITR uses the RLOC of a configured Map-Resolver as the destination IP address for Map-Requests; an RLOC, by definition, is routable on the non-LISP part of the Internet. To be forwarded on to the ALT, though, the target EID is also needed as a destination IP address. Adding an extra encpasulation header allows two-stage routing to the destination addresses used in those different contexts. Similarly, since an ETR using a Map-Server is not connected to the ALT, traffic between between Map-Server and ETR must use RLOC-based native forwarding. An ETR thus sends its Map-Register messages using its RLOC as the IP source address and the Map-Server RLOC as the IP destination. Likewise, a Map-Server forwards Map-Requests to an ETR using its RLOC as the IP source address and the ETR RLOC as the IP destination; to do this, it must encapsulate the original Map-Request since the original destination IP address is an EID that is only routable on the ALT. Problem details: As described above, an Encapsulated Map Request currently uses destination UDP port 4341 (LISP-DATA). This creates two potential problems: 1) A packet received by an ETR on port UDP 4341 cannot be immediately determined to be control or data. This means that an ETR must perform significant processing on such a packet before determining whether it needs to either take some control action or forward the packet to a destination host. This could make it difficult to implement ETR functionality on a router that uses specialized forwarding hardware. 2) It is currently possible for an encapsulated user UDP datagram received by an ETR with outer header UDP port 4341 to be misinterpreted as an Encapsulated Map Request. This is because an end system application can use UDP port 4342 as a source port for traffic. Return traffic to an such an application would be received by an ETR with outer header destination port 4341 (LISP-DATA) and inner header destination UDP port 4342; this could be consumed by an ETR and not forwarded correctly. The assignment by the IANA of well-known LISP "service" port numbers will prevent this problem in the future but there may be difficulties with early trials and deployment prior to such an assignment. Solution: 1) Modify the base LISP specification (draft-ietf-lisp-05) to define a new LISP control message type called Encapsulated Control Message. 2) Modify the LISP-MS document (draft-ietf-lisp-ms-03) to specify that Encapsulated Map Requests use the new message type and that they are sent to UDP port 4342 (LISP-CONTROL) instead of 4341 (LISP-DATA). 3) Modify the LISP Multicast document (draft-ietf-lisp-multicast-02.txt) to similarly replace all use of UDP port 4341 with port 4342 for encapsulated unicast PIM Join/Prune messages. These changes greatly simplify processing of LISP packets by an ETR: all traffic received on UDP port 4341 is decapsulated and forwarded to an end system while all traffic received on port 4342 is processed by the ETR itself. Furthermore, these changes eliminate any user vs. control message ambiguity for traffic received by an ETR on port 4341. -- Ticket URL: lisp LISP WG document issues From hartmans@mit.edu Thu Sep 24 13:28: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 3E1993A68FC for ; Thu, 24 Sep 2009 13:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 PjnmEIFKionp for ; Thu, 24 Sep 2009 13:28: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 6FD5F3A689D for ; Thu, 24 Sep 2009 13:28:57 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 90E1B413B; Thu, 24 Sep 2009 16:30:04 -0400 (EDT) To: trac@localhost.amsl.com References: <057.9ff186693c7cb938e3dcb5fc65bd8b4c@tools.ietf.org> From: Sam Hartman Date: Thu, 24 Sep 2009 16:30:04 -0400 In-Reply-To: <057.9ff186693c7cb938e3dcb5fc65bd8b4c@tools.ietf.org> (lisp issue tracker's message of "Thu\, 24 Sep 2009 20\:16\:39 -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 Cc: lisp@ietf.org Subject: Re: [lisp] #24: Encapsulated control packets on the LISP data port 4341 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 20:28:59 -0000 There appears to be rough consensus for this technical direction as a solution to #24. Issue #22 will remain open. I'll give what comments I can in a day or two on where we stand with a consensus on that issue. I've seen text for this in the lisp-05 draft so presumably the WG will get a chance to review that shortly. From hartmans@mit.edu Thu Sep 24 13:32: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 BA6633A6958 for ; Thu, 24 Sep 2009 13:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 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 48Z+dgyoS0Hl for ; Thu, 24 Sep 2009 13:32: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 043813A688C for ; Thu, 24 Sep 2009 13:32:33 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BE63B413B; Thu, 24 Sep 2009 16:33:36 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Thu, 24 Sep 2009 16:33: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 Subject: [lisp] #2: Consensus in favor of replacing IPsec with a MAC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 20:32:34 -0000 There appears to be consensus on the technical direction of replacing IPsec with a packet level MAC. The issue of key management will remain open; I'll go take my long message about key management and copy it into a new issue. I raised a couple of concerns about this direction; those concerns were not objections. I'll note that both Noel and I have asked for us to look at replay detection for this protocol. Noel would like to see a way where we can make that change without another packet format change later. That would be nice if it can happen. I think we'll want to review the text for this change. From dino@cisco.com Thu Sep 24 15:26: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 447C73A6968 for ; Thu, 24 Sep 2009 15:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 PNYCziDIlI+d for ; Thu, 24 Sep 2009 15:26: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 670233A6839 for ; Thu, 24 Sep 2009 15:26:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANaOu0qrR7MV/2dsb2JhbAC+BohTAZAHBYQc X-IronPort-AV: E=Sophos;i="4.44,447,1249257600"; d="scan'208";a="192129159" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2009 22:27:49 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8OMRn0g024285 for ; Thu, 24 Sep 2009 15:27:49 -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 n8OMRmDr006570 for ; Thu, 24 Sep 2009 22:27:48 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, 24 Sep 2009 15:27:48 -0700 Received: from dhcp-171-70-235-225.cisco.com ([171.70.235.225]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 15:27:48 -0700 Message-Id: From: Dino Farinacci 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 v936) Date: Thu, 24 Sep 2009 15:27:48 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Sep 2009 22:27:48.0592 (UTC) FILETIME=[3EF89F00:01CA3D66] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=827; t=1253831269; x=1254695269; 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:=20Preparing=20changes=20for=20-05 |Sender:=20; bh=kzYnryvslkdo3rSs0ZR4E/hDS2qUxu3b54QHJIDHc7A=; b=hSbIsl9+Yxrd0QMZfzE0gPjHPBi2y045843DgtloP36eHy5NnyOrxwucHL 7IR7TSKPGnV+K1aZL3mW6tzjtyRemUEMXEk73NM71tgQEC85LH6MgBFYXpxW Cj7yGMKJxb7ZIKnYQhRNnmETB812Vwv1FbMAfHnC7n2+8VD0aJ+Kw=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [lisp] Preparing changes for -05 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 24 Sep 2009 22:26:40 -0000 Folks, while we are converging and preparing changes for the -05 draft, the LISP-CONS coauthors felt that the type codes (values 8 through 11) defined here should be removed: 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' Is there any objections to this? Dino From mrw@sandstorm.net Fri Sep 25 06:19: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 864E83A6852 for ; Fri, 25 Sep 2009 06:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.031, 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 rlie29lfmkD7 for ; Fri, 25 Sep 2009 06:19:17 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 256EF3A6829 for ; Fri, 25 Sep 2009 06:19:15 -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 n8PDKC8e083420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Sep 2009 09:20:12 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: 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 v936) Date: Fri, 25 Sep 2009 09:14:49 -0400 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Preparing changes for -05 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 25 Sep 2009 13:19:17 -0000 On Sep 24, 2009, at 6:27 PM, Dino Farinacci wrote: > Folks, while we are converging and preparing changes for the -05 > draft, the LISP-CONS coauthors felt that the type codes (values 8 > through 11) defined here should be removed: I agree that they should be removed, because the corresponding messages are not defined in this document. Margaret From dino@cisco.com Fri Sep 25 10:00: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 700E93A68DD for ; Fri, 25 Sep 2009 10:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hUy-vdvgiqJ for ; Fri, 25 Sep 2009 10:00:46 -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 CD20B3A68D2 for ; Fri, 25 Sep 2009 10:00:45 -0700 (PDT) X-Files: rfcdiff-lisp-04-to-05.html, draft-ietf-lisp-05.txt : 158151, 161765 X-IronPort-AV: E=Sophos;i="4.44,452,1249257600"; d="txt'?html'217?scan'217,208,217";a="247048096" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 25 Sep 2009 17:01:57 +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 n8PH1utT016684 for ; Fri, 25 Sep 2009 10:01:56 -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 n8PH1uIH011449 for ; Fri, 25 Sep 2009 17:01:56 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, 25 Sep 2009 10:01:56 -0700 Received: from dhcp-171-70-235-225.cisco.com ([171.70.235.225]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 10:01:48 -0700 Message-Id: <3D19B2AF-6434-4CE4-88EA-A4414EFCD582@cisco.com> From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-91-713000382 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 25 Sep 2009 10:01:47 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Sep 2009 17:01:49.0863 (UTC) FILETIME=[DF792B70:01CA3E01] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=336937; t=1253898117; x=1254762117; 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:=20Proposed=20change=20to=20draft-ietf-lisp-05.txt |Sender:=20; bh=omVemyVEln3bVSROG0/GOX0PbmjBSCk6Jly7HFdP86g=; b=HbN3Um0SUnLxXJYzMoUdcJu2GPjoLuGLcqMX5wqWnzXxjU8D6dBGNpCyaE OKKD+oB1eyhWmERblHClbkPWHFZ1avWrzhEMWersi8/tdxj4jwhOvUrP1Q/v CXzip4AkfU2JTpTb0KlkID61WLxn+FdUDZo3dX+V9bSui4iU5OZvU=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [lisp] Proposed change to draft-ietf-lisp-05.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: Fri, 25 Sep 2009 17:00:46 -0000 --Apple-Mail-91-713000382 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit See the changes proposed for the -05 spec. The changes include: B.1. Changes to draft-ietf-lisp-05.txt o Posted October 2009. o Added this Document Change Log appendix. o Added section indicating that encapsulated Map-Requests must use destination UDP port 4342. o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- data in Map-Register payload. o Added Jari to acknowledgment section. o State the source-EID is set to 0 when using Map-Requests to refresh or RLOC-probe. o Make more clear what source-RLOC should be for a Map-Request. o The LISP-CONS authors thought that the Type definitions for CONS should be removed from this specification. Bullets 3 and 4 address tracker items #24 and #2. To focus your review I have included the text below, as well as attached diffs. For #24, here is the main text changed: ---- 6.1.7. Encapsualted Control Message Format An Encapsulated Control Message is used as the service interface between ITRs, ETRs, and the mapping database system described in [LISP-MS]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ / | Source Port = xxxx | Dest Port = 4342 | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ LH |Type=8 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ / | Source Port = xxxx | Dest Port = yyyy | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ Packet header descriptions: OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the source and destination header address fields. UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero. LH: Type 8 is defined to be a "LISP Encapsulated Control Message" and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the reserved field. IH: The inner IPv4 or IPv6 header which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format the destination address in this header is an EID. UDP: The inner UDP header where the port assignments depends on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is randomly assigned and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum LCM: The format is one of the control message formats described in this section. ---- And for #2, here is the main text changed: ---- 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 UDP with a destination UDP port of 4342 and a randomly selected UDP source port number. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ ~ Authentication Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ R | Locator Count | EID mask-len | ACT |A| 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. Key ID: A configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. Authentication Data Length: The length in bytes of the Authentication Data field that follows this field. The length of the the Authentication Data field is dependent on the Message Authentication Code (MAC) algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Authentication Data: The message digest used from the output of the Message Authentication Code (MAC) algorithm. The entire Map- Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] is recommended. Nonce: This 8-byte 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. ---- Would like to say thanks for the discussion. I don't know how long the review cycle will be for this but the chairs will decide on consensus for these changes. Thanks, Dino/Dave/Darrel/Vince --Apple-Mail-91-713000382 Content-Disposition: attachment; filename=rfcdiff-lisp-04-to-05.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-04-to-05.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-04.txt draft-ietf-lisp-05.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: March 20, 28, 2010                                         D. Lewis
                                                           cisco Systems
                                                      September 16, 24, 2009

                 Locator/ID Separation Protocol (LISP)
                         draft-ietf-lisp-04.txt
           (PROPOSED) draft-ietf-lisp-05.txt (NOT POSTED YET)

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 March 20, 28, 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 . . . . . . . . . 22
       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 30
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 32 33
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 33 34
       6.1.7.  Encapsualted Control Message Format  . . . . . . . . . 36
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 36 38
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 37 39
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 39 42
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41 43
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 41 44
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 42 44
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 43 45
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 44 46
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 46 48
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 47 49
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 48 50
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 48 50
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 49 51
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 50 52
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 51 53
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 51 53
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 51 53
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 53 55
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 53 55
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 55
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 55
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 55 57
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 55 57
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 57 59
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 58 60
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 59 61
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 64
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 62 64
     14.2. Informative References . . . . . . . . . . . . . . . . . . 63 65
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 66 68
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 69
     B.1.  Changes to draft-ietf-lisp-05.txt  . . . . . . . . . . . . 69
     B.2.  Changes to draft-ietf-lisp-04.txt  . . . . . . . . . . . . 69
     B.3.  Changes to draft-ietf-lisp-03.txt  . . . . . . . . . . . . 71
     B.4.  Changes to draft-ietf-lisp-02.txt  . . . . . . . . . . . . 71
     B.5.  Changes to draft-ietf-lisp-01.txt  . . . . . . . . . . . . 72
     B.6.  Changes to draft-ietf-lisp-00.txt  . . . . . . . . . . . . 72
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 73

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 statically 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 prepends 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
      statically 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 prepends 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   |N|L|E|  rflags |                 Nonce                         |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       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   |N|L|E|  rflags |                 Nonce                         |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       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

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

   Outer 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 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 SHOULD be transmitted as zero by an ITR for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
      packet with a zero UDP checksum is received by an ETR, the ETR
      MUST accept the packet for decapsulation.  When an ITR transmits a
      non-zero value for the UDP checksum, it MUST send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.  The handling of UDP checksums for all tunneling
      protocols, including LISP, is under active discussion within the
      IETF.  When that discussion concludes, any necessary changes will
      be made to align LISP with the outcome of the broader discussion.

   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.

   N: this is the nonce-present bit.  When this bit is set to 1, the
      low-order 24-bits of the first 32-bits of the LISP header contains
      a Nonce.  See section Section 6.3.1 for details.

   L: this is the Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are in use.

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1.  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.

   rflags:  this 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
      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.  When the E-bit is clear but the N-bit
      is set, an ITR is either echoing a previously requested echo-nonce
      or providing a random nonce.  See section Section 6.3.1 for more
      details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator Status Bits are numbered from 0 to n-1 from the least
      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 outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

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

   When doing Re-encapsulated Tunneling:

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

   o  The new outer 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 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
       LISP Encapsulated Control 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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.  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 Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  An 8-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.  The
      security of the LISP mapping protocol depends critically on the
      strength of the nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   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.  When
      Map-Requests are used for refreshing a map-cache entry or for
      RLOC-probing, the value 0 is used.

   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 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.  The
   source address is either an IPv4 or IPv6 RLOC address depending if
   the Map-Request is using an IPv4 versus IPv6 header, respectively.
   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
   4342 with a LISP type value set to "Encapsulated Control Message",
   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.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request, it may
   originate a "verifying Map-Request", addressed to the original ITR.
   If the ETR has a map-cache entry that matches the "piggybacked" EID
   and the RLOC is in the locator-set for the entry, then it may send
   the "verifying Map-Request" to the original Map-Request source.  If
   not, then it MUST send it to the "piggybacked" EID.  Doing this
   forces the "verifying Map-Request" to go through the mapping database
   system to reach the authoritative source of information about that
   EID, guarding against RLOC-spoofing in in the "piggybacked" 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|E|            Reserved               | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      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.  See
      section Section 6.3.2 for more details.

   E: Indicates that the ETR which sends this Map-Reply message is
      advertising that the site 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 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request is echoed in this Nonce field of 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.

   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.

   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 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 of 4342 and a
   randomly selected UDP source 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 [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 [RFC4302] 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                 | Next Header   |  Payload Len  |          RESERVED             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Security Parameters Index (SPI)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Sequence Number Field Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Key ID             |
       +  Authentication Data (variable)                 |
       | Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      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.

   Key ID:  A configured ID to find the configured Message
      Authentication Code (MAC) algorithm and key value used for the
      authentication function.

   Authentication Data Length:  The length in bytes of the
      Authentication Data field that follows this field.  The length of
      the the Authentication Data field is dependent on the Message
      Authentication Code (MAC) algorithm used.  The length field allows
      a device that doesn't know the MAC algorithm to correctly parse
      the packet.

   Authentication Data:  The message digest used from the output of the
      Message Authentication Code (MAC) algorithm.  The entire Map-
      Register payload is authenticated with this field preset to 0.
      After the MAC is computed, it is placed in this field.
      Implementations of this specification MUST include support for
      HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634]
      is recommended.

   Nonce:  This 8-byte 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

6.1.7.  Encapsualted Control Message Format

   An Encapsulated Control Message is achieved by
   manipulating used as the Priority service interface
   between ITRs, ETRs, and Weight fields the mapping database system described in EID-to-RLOC Map-Reply
   messages.  Alternatively,
   [LISP-MS].

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   OH  |                      (uses RLOC information may be gleaned from
   received tunneled packets addresses)                    |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4342        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LH  |Type=8 |                   Reserved                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or EID-to-RLOC Map-Request messages. IPv6 Header                     |
   IH  |                  (uses RLOC or EID addresses)                 |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = yyyy        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LCM |                      LISP Control Message                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet header descriptions:

   OH:   The following enumerates different scenarios for choosing RLOCs outer IPv4 or IPv6 header which uses RLOC addresses in the
      source and destination header address fields.

   UDP:   The outer UDP header with destination port 4342.  The source
      port is randomly allocated.  The checksum field MUST be non-zero.

   LH:   Type 8 is defined to be a "LISP Encapsulated Control Message"
      and what follows is either an IPv4 or IPv6 header as encoded by
      the controls that are available:

   o  Server-side returns one RLOC.  Client-side first 4 bits after the reserved field.

   IH:   The inner IPv4 or IPv6 header which can only use either RLOC or EID
      addresses in the header address fields.  When a Map-Request is
      encapsulated in this packet format the destination address in this
      header is an EID.

   UDP:   The inner UDP header where the port assignments depends on the
      control packet being encapsulated.  When the control packet is a
      Map-Request or Map-Register, the source port is randomly assigned
      and the destination port is 4342.  When the control packet is a
      Map-Reply, the source port is 4342 and the destination port is
      assigned from the source port of the invoking Map-Request.  Port
      number 4341 MUST NOT be assigned to either port.  The checksum
      field MUST be non-zero.

   LCM:   The format is one of the control message formats described in
      this 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, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply or that stored in the
   mapping database system provide reachability information for RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the Routing Locator Reachability Algorithms described in the
   next section.

6.3.  Routing Locator Reachability

   Several mechanisms for determining RLOC reachability are currently
   defined:

   1.  An ETR may examine the Loc-Status-Bits in the LISP header of an
       encapsulated data packet received from an ITR.  If the ETR is
       also acting as an ITR and has traffic to return to the original
       ITR site, it can use this status information to help select an
       RLOC.

   2.  An ITR may receive an ICMP Network or ICMP Host Unreachable
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  An ITR which participates in the global routing system can
       determine that an RLOC is down if no BGP RIB route exists that
       matches the RLOC IP address.

   4.  An ITR may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR attempts to use
       interworking [INTERWORK] and LISP-encapsulated data is sent to a
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  When an ETR receives an encapsulated packet from an ITR, the
       source RLOC from the outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability by examining the Loc-
   Status-Bits from the LISP encapsulated data packet, an ETR will
   receive up to date status from an encapsulating ITR about
   reachability for all ETRs at the site.  CE-based ITRs at the source
   site can determine reachability relative to each other using the site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route into the site IGP.

   o  If an ITR fails or if the upstream link to its PE fails, its
      default route will either time-out or be withdrawn.

   Each ITR can thus observe the presence or lack of a default route
   originated by the others to determine the Locator Status Bits it sets
   for them.

   RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1.  The
   Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit.  For example, if an RLOC
   listed in the 3rd position of the Map-Reply goes down (ordinal value
   2), then all ITRs at the site will clear the 3rd least significant
   bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will check for any change in
   the Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to an RLOC that is indicated as
   down.  It will only resume using that RLOC if the corresponding Loc-
   Status-Bit returns to a value of 1.  Loc-Status-Bits are associated
   with a locator-set per EID-prefix.  Therefore, when a locator becomes
   unreachable, the 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 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-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 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 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 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 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.

   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 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 obtain those benefits, especially if the
   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-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-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-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-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 a Map-Request message.  An ITR
   or PTR will send a Map-Request when they receive an SMR message.
   Both the SMR sender and the 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 ETRs at the site
       begin to send Map-Requests with the SMR bit set for each locator
       in each map-cache entry the ETR caches.

   2.  A remote xTR which receives the SMR message will schedule sending
       a Map-Request message to the source locator address of the SMR
       message.  A newly allocated random nonce is selected and the EID-
       prefix uses is the one copied from the SMR 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-status-bits are reflective of the new mapping for packets
       going to the remote site.  The ETR then stops sending 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 more secure to reach an authoritative ETR,
   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 24-bit Nonce field in the LISP encapsulation header and a
   64-bit Nonce field in the LISP control message.  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.  Interoperable implementations have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   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.  Two are the Echo-Noncing and
        RLOC-Probing algorithms which are documented in this
        specification.  The third is called TCP-counts 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.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, 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.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

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

   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 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.

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

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-02.txt (work in progress),
              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.

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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, Sam Hartman, Michael Hofling, and Pedro Marques. Marques, and Jari
   Arkko.

   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.

Appendix B.  Document Change Log

B.1.  Changes to draft-ietf-lisp-05.txt

   o  Posted October 2009.

   o  Added this Document Change Log appendix.

   o  Added section indicating that encapsulated Map-Requests must use
      destination UDP port 4342.

   o  Don't use AH in Map-Registers.  Put key-id, auth-length, and auth-
      data in Map-Register payload.

   o  Added Jari to acknowledgment section.

   o  State the source-EID is set to 0 when using Map-Requests to
      refresh or RLOC-probe.

   o  Make more clear what source-RLOC should be for a Map-Request.

   o  The LISP-CONS authors thought that the Type definitions for CONS
      should be removed from this specification.

B.2.  Changes to draft-ietf-lisp-04.txt

   o  Posted September 2009.

   o  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?

   o  Add Fred Templin in ack section.

   o  Add Margaret and Sam to the ack section for their great comments.

   o  Say more about LAGs in the UDP section per Sam Hartman's comment.

   o  Sam wants to use MAY instead of SHOULD for ignoring checksums 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."

   o  Margaret wants a reference to
      http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt.

   o  Fix description in Map-Request section.  Where we describe Map-
      Reply Record, change "R-bit" to "M-bit".

   o  Add the mobility bit to Map-Replies.  So PTRs don't probe so often
      for MNs but often enough to get mapping updates.

   o  Indicate SHA1 can be used as well for Map-Registers.

   o  More Fred comments on MTU handling.

   o  Isidor comment about specing better periodic Map-Registers.  Will
      be fixed in draft-ietf-lisp-ms-02.txt.

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

   o  Add section on RLOC-probing per working group feedback.

   o  Change "loc-reach-bits" to "loc-status-bits" per comment from
      Noel.

   o  Remove SMR-bit from data-plane.  Dino prefers to have it in the
      control plane only.

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

   o  Add a N-bit to the data header suggested by Noel.  Then the nonce
      field could be used when N is not 1.

   o  Clarify that when E-bit is 0, the nonce field can be an echoed
      nonce or a random nonce.  Comment from Jesper.

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

   o  Indicate that a verifying Map-Request, for accepting mapping data,
      should be sent over the the ALT (or to the EID).

   o  Reference IPsec RFC 4302.  Comment from Sam and Brian Weis.

   o  Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
      noncing.  Comment by Pedro and Dino.

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

B.3.  Changes to draft-ietf-lisp-03.txt

   o  Posted July 2009.

   o  Removed loc-reach-bits longword from control packets per Damien
      comment.

   o  Clarifications in MTU text from Roque.

   o  Added text to indicate that the locator-set be sorted by locator
      address from Isidor.

   o  Clarification text from JohnZ in Echo-Nonce section.

B.4.  Changes to draft-ietf-lisp-02.txt

   o  Posted July 2009.

   o  Encapsulation packet format change to add E-bit and make loc-
      reach-bits 32-bits in length.

   o  Added Echo-Nonce Algorithm section.

   o  Clarification how ECN bits are copied.

   o  Moved S-bit in Map-Request.

   o  Added P-bit in Map-Request and Map-Reply messages to anticipate
      RLOC-Probe Algorithm.

   o  Added to Mobility section to reference draft-meyer-lisp-mn-00.txt.

B.5.  Changes to draft-ietf-lisp-01.txt

   o  Posted 2 days after draft-ietf-lisp-00.txt in May 2009.

   o  Defined LEID to be a "LISP EID".

   o  Indicate encapsulation use IPv4 DF=0.

   o  Added negative Map-Reply messages with drop, native-forward, and
      send-map-request actions.

   o  Added Proxy-Map-Reply bit to Map-Register.

B.6.  Changes to draft-ietf-lisp-00.txt

   o  Posted May 2009.

   o  Rename of draft-farinacci-lisp-12.txt.

   o  Acknowledgment to RRG.

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-91-713000382 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-91-713000382 Content-Disposition: attachment; filename=draft-ietf-lisp-05.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-05.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: March 28, 2010 D. Lewis cisco Systems September 24, 2009 Locator/ID Separation Protocol (LISP) (PROPOSED) draft-ietf-lisp-05.txt (NOT POSTED YET) 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 March 28, 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. Farinacci, et al. Expires March 28, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 . . . . . . . . . 22 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 . . . . . . . . . . . . . . . 30 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 33 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 34 6.1.7. Encapsualted Control Message Format . . . . . . . . . 36 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 38 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 39 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 42 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 43 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 44 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 44 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 45 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 46 7. Router Performance Considerations . . . . . . . . . . . . . . 48 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 49 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 50 Farinacci, et al. Expires March 28, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 50 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 51 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 52 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 53 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 53 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 53 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 55 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 55 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 55 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 55 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 57 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 57 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 59 12. Security Considerations . . . . . . . . . . . . . . . . . . . 60 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 61 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 14.1. Normative References . . . . . . . . . . . . . . . . . . . 64 14.2. Informative References . . . . . . . . . . . . . . . . . . 65 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 68 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 69 B.1. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 69 B.2. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 69 B.3. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 71 B.4. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 71 B.5. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 72 B.6. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 Farinacci, et al. Expires March 28, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 28, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 28, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 28, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 28, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 statically 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 prepends 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 statically configured. Farinacci, et al. Expires March 28, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 prepends 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 Farinacci, et al. Expires March 28, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 28, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | | Farinacci, et al. Expires March 28, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer 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 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 SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion. 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 Farinacci, et al. Expires March 28, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 headers are used. The UDP header length is 8 bytes. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See section Section 6.3.1 for details. L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. E: this is the echo-nonce-request bit. When this bit is set to 1, the N bit must be 1. 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. rflags: this 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 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. When the E-bit is clear but the N-bit is set, an ITR is either echoing a previously requested echo-nonce or providing a random nonce. See section Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least 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 outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Farinacci, et al. Expires March 28, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 Type of Service field (with one caveat, see below). When doing Re-encapsulated Tunneling: o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer 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. Farinacci, et al. Expires March 28, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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. Farinacci, et al. Expires March 28, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet with DF bit set to 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. Farinacci, et al. Expires March 28, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires March 28, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 | | + 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. Farinacci, et al. Expires March 28, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Encapsulated Control Message: 8 b'1000' 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=3D1 |A|M|P|S| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . 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: Farinacci, et al. Expires March 28, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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 Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. 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. When Map-Requests are used for refreshing a map-cache entry or for RLOC-probing, the value 0 is used. Originating ITR RLOC Address: Used to give the ETR the option of returning a Map-Reply in the address-family of this locator. Farinacci, et al. Expires March 28, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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. The source address is either an IPv4 or IPv6 RLOC address depending if the Map-Request is using an IPv4 versus IPv6 header, respectively. 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 4342 with a LISP type value set to "Encapsulated Control Message", 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]. Farinacci, et al. Expires March 28, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request, it may originate a "verifying Map-Request", addressed to the original ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map-Request" to the original Map-Request source. If not, then it MUST send it to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" mapping data. Farinacci, et al. Expires March 28, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| 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. See section Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is advertising that the site 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. Farinacci, et al. Expires March 28, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of 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. 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. 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. Farinacci, et al. Expires March 28, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 28, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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- Farinacci, et al. Expires March 28, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 UDP with a destination UDP port of 4342 and a randomly selected UDP source port number. The Map-Register message format is: Farinacci, et al. Expires March 28, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D3 |P| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| 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. Key ID: A configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. Farinacci, et al. Expires March 28, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 Authentication Data Length: The length in bytes of the Authentication Data field that follows this field. The length of the the Authentication Data field is dependent on the Message Authentication Code (MAC) algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Authentication Data: The message digest used from the output of the Message Authentication Code (MAC) algorithm. The entire Map- Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] is recommended. Nonce: This 8-byte 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.1.7. Encapsualted Control Message Format An Encapsulated Control Message is used as the service interface between ITRs, ETRs, and the mapping database system described in [LISP-MS]. Farinacci, et al. Expires March 28, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4342 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=3D8 | Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D yyyy = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet header descriptions: OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the source and destination header address fields. UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero. LH: Type 8 is defined to be a "LISP Encapsulated Control Message" and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the reserved field. IH: The inner IPv4 or IPv6 header which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format the destination address in this header is an EID. UDP: The inner UDP header where the port assignments depends on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is randomly assigned and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum Farinacci, et al. Expires March 28, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 field MUST be non-zero. LCM: The format is one of the control message formats described in this 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 Farinacci, et al. Expires March 28, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a Farinacci, et al. Expires March 28, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the 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. Farinacci, et al. Expires March 28, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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-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 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 Farinacci, et al. Expires March 28, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 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 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. 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 Farinacci, et al. Expires March 28, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 obtain those benefits, especially if the 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. Farinacci, et al. Expires March 28, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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- Farinacci, et al. Expires March 28, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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-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-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-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. Farinacci, et al. Expires March 28, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the 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 ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- prefix uses is the one copied from the SMR message. 3. The remote xTR retransmits the Map-Request slowly until it gets a Map-Reply while continuing to use the cached mapping. Farinacci, et al. Expires March 28, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending 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 more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. Farinacci, et al. Expires March 28, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 28, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, Farinacci, et al. Expires March 28, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 28, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 28, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 28, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 28, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. 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. Farinacci, et al. Expires March 28, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Interoperable implementations have been available since the beginning of 2009. We are trying to converge on a packet format so implementations can converge on the -04 and later drafts. 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. Farinacci, et al. Expires March 28, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 28, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts 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. Farinacci, et al. Expires March 28, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, 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. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. Farinacci, et al. Expires March 28, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 [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. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 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] Farinacci, et al. Expires March 28, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-02.txt (work in progress), 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. Farinacci, et al. Expires March 28, 2010 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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. Farinacci, et al. Expires March 28, 2010 [Page 67] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, and Jari Arkko. 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. Farinacci, et al. Expires March 28, 2010 [Page 68] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-05.txt o Posted October 2009. o Added this Document Change Log appendix. o Added section indicating that encapsulated Map-Requests must use destination UDP port 4342. o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- data in Map-Register payload. o Added Jari to acknowledgment section. o State the source-EID is set to 0 when using Map-Requests to refresh or RLOC-probe. o Make more clear what source-RLOC should be for a Map-Request. o The LISP-CONS authors thought that the Type definitions for CONS should be removed from this specification. B.2. Changes to draft-ietf-lisp-04.txt o Posted September 2009. o 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? o Add Fred Templin in ack section. o Add Margaret and Sam to the ack section for their great comments. o Say more about LAGs in the UDP section per Sam Hartman's comment. o Sam wants to use MAY instead of SHOULD for ignoring checksums on ETR. =46rom 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 Farinacci, et al. Expires March 28, 2010 [Page 69] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 sure it permits 0 checksums." o Margaret wants a reference to http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt. o Fix description in Map-Request section. Where we describe Map- Reply Record, change "R-bit" to "M-bit". o Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs but often enough to get mapping updates. o Indicate SHA1 can be used as well for Map-Registers. o More Fred comments on MTU handling. o Isidor comment about specing better periodic Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. o 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." o Add section on RLOC-probing per working group feedback. o Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. o Remove SMR-bit from data-plane. Dino prefers to have it in the control plane only. o 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. o Add a N-bit to the data header suggested by Noel. Then the nonce field could be used when N is not 1. o Clarify that when E-bit is 0, the nonce field can be an echoed nonce or a random nonce. Comment from Jesper. o 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 Farinacci, et al. Expires March 28, 2010 [Page 70] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 map-cache corruption by a 3rd party. Comment from Pedro. o Indicate that a verifying Map-Request, for accepting mapping data, should be sent over the the ALT (or to the EID). o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- noncing. Comment by Pedro and Dino. o 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. B.3. Changes to draft-ietf-lisp-03.txt o Posted July 2009. o Removed loc-reach-bits longword from control packets per Damien comment. o Clarifications in MTU text from Roque. o Added text to indicate that the locator-set be sorted by locator address from Isidor. o Clarification text from JohnZ in Echo-Nonce section. B.4. Changes to draft-ietf-lisp-02.txt o Posted July 2009. o Encapsulation packet format change to add E-bit and make loc- reach-bits 32-bits in length. o Added Echo-Nonce Algorithm section. o Clarification how ECN bits are copied. o Moved S-bit in Map-Request. o Added P-bit in Map-Request and Map-Reply messages to anticipate RLOC-Probe Algorithm. o Added to Mobility section to reference draft-meyer-lisp-mn-00.txt. Farinacci, et al. Expires March 28, 2010 [Page 71] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 B.5. Changes to draft-ietf-lisp-01.txt o Posted 2 days after draft-ietf-lisp-00.txt in May 2009. o Defined LEID to be a "LISP EID". o Indicate encapsulation use IPv4 DF=3D0. o Added negative Map-Reply messages with drop, native-forward, and send-map-request actions. o Added Proxy-Map-Reply bit to Map-Register. B.6. Changes to draft-ietf-lisp-00.txt o Posted May 2009. o Rename of draft-farinacci-lisp-12.txt. o Acknowledgment to RRG. Farinacci, et al. Expires March 28, 2010 [Page 72] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 28, 2010 [Page 73] =0C --Apple-Mail-91-713000382 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-91-713000382-- From darlewis@cisco.com Fri Sep 25 12:00: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 4FC033A6A88 for ; Fri, 25 Sep 2009 12:00:48 -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 UC-xBx+TktPK for ; Fri, 25 Sep 2009 12:00:47 -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 1A6A63A6A8C for ; Fri, 25 Sep 2009 12:00:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANKvvEqrR7MV/2dsb2JhbAC+T4hTAY97BYQegV2JDA X-IronPort-AV: E=Sophos;i="4.44,452,1249257600"; d="scan'208";a="396255670" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Sep 2009 19:01:46 +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 n8PJ1keL012188; Fri, 25 Sep 2009 12:01: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 n8PJ1jXs023027; Fri, 25 Sep 2009 19:01:46 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); Fri, 25 Sep 2009 12:01:09 -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, 25 Sep 2009 12:01:09 -0700 Message-ID: In-Reply-To: <4ABBC82A.7030106@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP Interworking: Proxy Egress Tunnel Routers Thread-Index: Aco9TRfJIX2H3SIEQW6/lSfeOVkTUgAvXdng References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> <20090921204855.GA7205@1-4-5.net> <4ABBC82A.7030106@piuha.net> From: "Darrel Lewis (darlewis)" To: "Jari Arkko" , "Sam Hartman" X-OriginalArrivalTime: 25 Sep 2009 19:01:09.0920 (UTC) FILETIME=[8B332A00:01CA3E12] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3839; t=1253905306; x=1254769306; 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]=20LISP=20Interworking=3A=20=20Pr oxy=20Egress=20Tunnel=20Routers |Sender:=20; bh=oYeZoJQMBBsYcfCbutO1CP0jj0LSt75D8JHwdgTSZJ8=; b=aZ5r++64S+0x6QOdHXXtXuSrjOcFRKGI+uSuc7fGE/B7DDMX/JGzD5BSg7 00EP12IoE5QMJNmujsoZPSoSblkFdRx9nV0XtkRk1VURS1JrI72afQZAwfkj iFdRmcmsOpc8nd++qItLg5jT/bE/5Al3EshETUS21M9TcnGMr/Mww=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Noel Chiappa , lisp@ietf.org, Robin Whittle Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 25 Sep 2009 19:00:48 -0000 Jari,=20 > Of course, I understand that pretty much any tunneling or translation=20 > technique can be used for IPv6 deployment as well. I do not=20 > mind if such=20 > use case gets mentioned in a list of other potential uses of Lisp.=20 > However, the main use case, deployment rationale, etc. needs=20 > to stand on=20 > its own and talk about routing scalability, traffic engineering, and=20 > other things central to Lisp.=20 Thanks for your note, I have a few comments that follow about the intended scope of LISP Interworking. I don't see a conflict with what you've written, but I want to try to clarify my position on LISP Interworking for the WG.=20 A central design goal of LISP is that it be practical, that is, work within the existing, deployed, Internet. Today that Internet has a mixture of IPv4 only, dual stack, and IPv6 only hosts and networks. It also is comprised of a myriad of access technologies, security mechanisms, that LISP xTR must integrate with in order to be deployable. LISP attempts to solve the routing scalability problem for both IPv4 and IPv6, and therefore LISP sites must interwork with non-LISP sites of both IP protocols. A central benefit of network based Interworking is how it enables the benefits of LISP for the site which has deployed LISP: On ingress, using Proxy Ingress Tunnel Routers, this is primarily the enablement of LISP's Ingress Traffic Engineering features. One result of this is that LISP sites relying on Proxy Ingress Tunnel Routers will see all ingress traffic LISP encapsulated - and therefore see this benefit of LISP immediately. I might add, a second order benefit is that if the Proxy Ingress Tunnel Router's RLOCs are connected the a Dual Stack IPv4/IPv6 network, the connectivity from the Proxy Ingress Tunnel Router to the site's ETR does not have to be Dual Stack. Proxy Ingress Tunnel Routers also are a primary tool to encourage sites not to Inject EIDs into the Internet routing system. They in effect make EID's routable without direct injection (and inevitable degradation) of the EID space by individual sites. For a site using Proxy Egress Tunnel Routers on egress there are fewer LISP specific benefits. This is because LISP does not attempt to enhance Egress Traffic Engineering (instead utilizing the site's existing egress IP routing mechanics). The primary use cases for Proxy Egress Tunnel routers are actually only to address practical deployment concerns. These secondary issues include working around limitations to the installed access networks' implementation of BCP 38 filtering, and working around the lack of support found in access networks for dual stack IPv4 and IPv6. So this means that not every LISP-Site will need a Proxy Egress Tunnel Router, but we know from our experimentations to date that it will help some of LISP sites, and this instigated the ideas and proposed text found in this thread. Note that both of these network based approaches are not required if LISP-NAT (currently specified only for IPv4)is used. LISP NAT instead uses routable EIDs that fall within the Provider Assigned address space. But a LISP site using LISP-NAT misses out in the advantages of ingress TE above, and will obviously not be IPv6 capable. =20 >I also understand that what we develop=20 > technology X for may not be what it eventually gets used for;=20 > we've been=20 > surprised before. Lets see what happens with Lisp. But for=20 > the RFCs that=20 > come out of this working group, lets focus on the initial main reason=20 > why Lisp was developed. >=20 Understood, and I think we are. My opinion is that Proxy Egress Tunnel routers are an interesting option that I think will assist in LISP sites to communicate with non-LISP sites. -Darrel From darlewis@cisco.com Fri Sep 25 12:14: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 CEB963A693F for ; Fri, 25 Sep 2009 12:14:43 -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 KfI-NleKbLGa for ; Fri, 25 Sep 2009 12:14:42 -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 D34783A6407 for ; Fri, 25 Sep 2009 12:14:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEy0vEqrR7PE/2dsb2JhbAC+RYhTAY98BYQegV0 X-IronPort-AV: E=Sophos;i="4.44,452,1249257600"; d="scan'208";a="208423146" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 25 Sep 2009 19:15:54 +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 n8PJFsea009349; Fri, 25 Sep 2009 12:15:54 -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 n8PJFqbT008006; Fri, 25 Sep 2009 19:15:54 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); Fri, 25 Sep 2009 12:15:38 -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, 25 Sep 2009 12:15:38 -0700 Message-ID: In-Reply-To: <4AB8583E.5010002@firstpr.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP-NAT - explanation and support? Thread-Index: Aco7QJwGV44x58NZSUagsRYqr8QIugC0ilzQ References: <4AB8583E.5010002@firstpr.com.au> From: "Darrel Lewis (darlewis)" To: "Robin Whittle" , X-OriginalArrivalTime: 25 Sep 2009 19:15:38.0788 (UTC) FILETIME=[9115E640:01CA3E14] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1659; t=1253906154; x=1254770154; c=relaxed/simple; s=sjdkim4002; 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]=20LISP-NAT=20-=20explanation=20a nd=20support? |Sender:=20; bh=WSNdgQLWE85PskJP73ExrsWtIlj5JdFd05S+DjJJNP8=; b=DMFRbTADLtCoTdQm7yydZiVQAQdRZyEZDu72LCloCchaOTcm3+fPdgQ7KU IxMF1m2OBL+SPzGSUBBLTX0F48jaiLCOz9HYOwEdt5Se+8PiIK+d8E10Idwz hYtyvGqO0g; Authentication-Results: sj-dkim-4; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [lisp] LISP-NAT - explanation and support? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 25 Sep 2009 19:14:43 -0000 Robin, >=20 > Short version: Can anyone explain exactly how LISP-NAT is > supposed to work, what it is useful for (especially > in terms of what it can do which other approaches > can't) and what its limitations are? >=20 > Does anyone argue that LISP-NAT will actually > be useful enough to be adopted? >=20 The LISP Interworking draft explains how LISP-NAT works, and why it is useful. LISP-NAT can be used in conjunction with Proxy Ingress Tunnel Routers, or on its own to enable hosts at a LISP site to exchange packets with hosts at a non-LISP site. Sites using LISP-NAT can on their own decide their hosts from Non-Routable) EID space, while communicating with non-LISP sites via its outside Routable (LISP-R) EIDs. Thus it can be an alternative to using network based Interworking infrastructure. For an interesting discussion of the limitations of NAT in general, you might read: http://tools.ietf.org/id/draft-vogt-address-translation-harmfulness-03.t xt which seems to cover most of the caveats of using NAT. You mentioned in an earlier email that you doubted whether LISP-NAT can be made to actually work, but we have existence proof in the existing LISP network that it can be implemented successfully. I also don't want to be drawn into a debate about the pro's and cons of NAT, except to say that it exists, and is popular for IPv4. Since NAT exists, and can be applied to solve the Interworking problem, the authors decided to include it in the Interworking specification and to experiment with it. -Darrel From mrw@sandstorm.net Fri Sep 25 12:56: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 C738A3A68AA for ; Fri, 25 Sep 2009 12:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.030, 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 XVgx0MwThMdd for ; Fri, 25 Sep 2009 12:56:39 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 58B8A3A6845 for ; Fri, 25 Sep 2009 12:56:37 -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 n8PJvRlY008122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Sep 2009 15:57:28 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <8F75FB29-FC8E-4C3C-A91A-15A10E917936@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <3D19B2AF-6434-4CE4-88EA-A4414EFCD582@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: Fri, 25 Sep 2009 15:57:27 -0400 References: <3D19B2AF-6434-4CE4-88EA-A4414EFCD582@cisco.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Fri, 25 Sep 2009 19:56:39 -0000 Hi DIno, Thanks for putting this summary together, it was very helpful to me in understanding what you plan to change. A have a few questions/comments about the proposed changes: > An Encapsulated Control Message is used as the service interface > between ITRs, ETRs, and the mapping database system described in > [LISP-MS]. If I understood correctly, only the Map-Request would be encapsulated this way, right? The Map-Register and Map-Reply packets would not, right? So, saying that this is the service interface between ITRs, ETRs and the mapping database system would seem to be an overstatement. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > / | IPv4 or IPv6 > Header | > OH | (uses RLOC > addresses) | > \ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > / | Source Port = xxxx | Dest Port = > 4342 | > UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > \ | UDP Length | UDP > Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > LH |Type=8 | > Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > / | IPv4 or IPv6 > Header | > IH | (uses RLOC or EID > addresses) | > \ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > / | Source Port = xxxx | Dest Port = > yyyy | > UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ I thought that the inner UDP destination port would also be 4342, as the next thing up is also a LISP control message. > \ | UDP Length | UDP > Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > LCM | LISP Control > Message | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > UDP: The inner UDP header where the port assignments depends on > the > control packet being encapsulated. When the control packet is a > Map-Request or Map-Register, the source port is randomly assigned > and the destination port is 4342. When the control packet is a > Map-Reply, the source port is 4342 and the destination port is > assigned from the source port of the invoking Map-Request. Port > number 4341 MUST NOT be assigned to either port. The checksum > As indicated above, I believe that this particular encapsulation diagram will only be used for Map-Register, so much of this text should be reworked. I also think it will always have a UDP destination port of 4342, right? > LCM: The format is one of the control message formats described in > this section. Is it worth stating that you can't have an Encapsulated Control Message inside an Encapsulated Control Message? [...] > > Authentication Data Length: The length in bytes of the > Authentication Data field that follows this field. The length of > the the Authentication Data field is dependent on the Message > Authentication Code (MAC) algorithm used. The length field > allows > a device that doesn't know the MAC algorithm to correctly parse > the packet. > > Authentication Data: The message digest used from the output of the > Message Authentication Code (MAC) algorithm. The entire Map- > Register payload is authenticated with this field preset to 0. > After the MAC is computed, it is placed in this field. > Implementations of this specification MUST include support for > HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 > [RFC4634] > is recommended. Is it really sufficient to hash only the Map-Register payload? Or do you need to hash (at least some fields of) the protocol headers, as well? I think, for example, that we may return the answer to the source RLOC in the outer header, right? Are there any other fields in the outer header that may need to be checked to ensure that the Map- Reply is being sent to the right place, or that this Map-Request was really sent by who we think it was? > Nonce: This 8-byte Nonce field is set to 0 in Map-Register > messages. Why is this set to 0? Wouldn't this still be useful to determine that a reply was actually in response to our request? Why include the field in the Map-Register message if it will always be 0? Margaret From jnc@mercury.lcs.mit.edu Fri Sep 25 14: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 34C653A6908 for ; Fri, 25 Sep 2009 14:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 j57Hi1CCaF0o for ; Fri, 25 Sep 2009 14:09:31 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 3BABD3A68C9 for ; Fri, 25 Sep 2009 14:09:31 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 5CC356BE572; Fri, 25 Sep 2009 17:10:41 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090925211041.5CC356BE572@mercury.lcs.mit.edu> Date: Fri, 25 Sep 2009 17:10:41 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Fri, 25 Sep 2009 21:09:32 -0000 > From: Margaret Wasserman > saying that this is the service interface between ITRs, ETRs and the > mapping database system would seem to be an overstatement. Well, a _bit_ of an overstatement, but yes... :-) > Is it really sufficient to hash only the Map-Register payload? Or do > you need to hash (at least some fields of) the protocol headers, as > well? Interesting question; I don't think so, because all the information in the mapping entry is contained inside the LISP portion of the Map-Register, and is therefore protected by the hash. I can't think of any information from the outer headers that would be used in any way (except the ETRs RLOC, and that would only be used to kind the correct key anyway). > I think, for example, that we may return the answer to the source RLOC > in the outer header, right? Err, what answer? Map-Registers are not acknowledged. > Are there any other fields in the outer header that may need to be > checked to ensure that the Map-Reply is being sent to the right place, > or that this Map-Request was really sent by who we think it was? I'm confused. The new authentication stuff only appears in Map-Reqister messages, not Map-Request/Map-Reply messages, AFAIK. >> Nonce: This 8-byte Nonce field is set to 0 in Map-Register >> messages. > Why is this set to 0? ... Why include the field in the Map-Register > message if it will always be 0? Ummm, I think I might be the cause of that - unless it's there because there's a desire to make all the control packets look similar (i.e. include a nonce field). When the issue of replay protection was raised, since replay is generally an on-path attack, I was trying to add a 'hook' to the Map-Register packet that would allow us to add replay protection _later_, without changing the packet format. (I.e. defer adding the _mechanism_ to deal with that attack till later, since it's an unlikely attack; but at the same time, putting a field in now would avoid interoperability problems - or using another opcode for a new format Map-Register - later. I.e. a cheap thing to do now - since we're chaning the packet format _anyway_ - to avoid a painful change later.) I had worked out a mechanism using a nonce, so perhaps that's what this is? But that's something of a guess! > Wouldn't this still be useful to determine that a reply was actually in > response to our request? ?? Map-Registers are not acknowledged. Noel From jmh@joelhalpern.com Fri Sep 25 14:15: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 EB9D63A6914 for ; Fri, 25 Sep 2009 14:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 REtND1gtVpC5 for ; Fri, 25 Sep 2009 14:15:33 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 21C793A6873 for ; Fri, 25 Sep 2009 14:15:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4981743058E; Fri, 25 Sep 2009 14:16:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 94EC9430586; Fri, 25 Sep 2009 14:16:39 -0700 (PDT) Message-ID: <4ABD3335.5060100@joelhalpern.com> Date: Fri, 25 Sep 2009 17:16:37 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Noel Chiappa References: <20090925211041.5CC356BE572@mercury.lcs.mit.edu> In-Reply-To: <20090925211041.5CC356BE572@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Fri, 25 Sep 2009 21:15:34 -0000 I want to be a bit careful here. For me, the wording on the service interface is more than a bit overstated, but as long as we treat it as interim, I'm fine with it. I suspect that one of the issues driving things is a differing view of the service being provided. But I need to have more discussions with various folks before I can defend that proposition. Joel Noel Chiappa wrote: > > From: Margaret Wasserman > > > saying that this is the service interface between ITRs, ETRs and the > > mapping database system would seem to be an overstatement. > > Well, a _bit_ of an overstatement, but yes... :-) > > > > Is it really sufficient to hash only the Map-Register payload? Or do > > you need to hash (at least some fields of) the protocol headers, as > > well? > > Interesting question; I don't think so, because all the information in the > mapping entry is contained inside the LISP portion of the Map-Register, and > is therefore protected by the hash. I can't think of any information from the > outer headers that would be used in any way (except the ETRs RLOC, and that > would only be used to kind the correct key anyway). > > > I think, for example, that we may return the answer to the source RLOC > > in the outer header, right? > > Err, what answer? Map-Registers are not acknowledged. > > > Are there any other fields in the outer header that may need to be > > checked to ensure that the Map-Reply is being sent to the right place, > > or that this Map-Request was really sent by who we think it was? > > I'm confused. The new authentication stuff only appears in Map-Reqister > messages, not Map-Request/Map-Reply messages, AFAIK. > > > >> Nonce: This 8-byte Nonce field is set to 0 in Map-Register > >> messages. > > > Why is this set to 0? ... Why include the field in the Map-Register > > message if it will always be 0? > > Ummm, I think I might be the cause of that - unless it's there because > there's a desire to make all the control packets look similar (i.e. include a > nonce field). > > When the issue of replay protection was raised, since replay is generally an > on-path attack, I was trying to add a 'hook' to the Map-Register packet that > would allow us to add replay protection _later_, without changing the packet > format. (I.e. defer adding the _mechanism_ to deal with that attack till > later, since it's an unlikely attack; but at the same time, putting a field > in now would avoid interoperability problems - or using another opcode for a > new format Map-Register - later. I.e. a cheap thing to do now - since we're > chaning the packet format _anyway_ - to avoid a painful change later.) I had > worked out a mechanism using a nonce, so perhaps that's what this is? > > But that's something of a guess! > > > Wouldn't this still be useful to determine that a reply was actually in > > response to our request? > > ?? Map-Registers are not acknowledged. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From mrw@sandstorm.net Fri Sep 25 15:09: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 C32243A68C9 for ; Fri, 25 Sep 2009 15:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.097, 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 KkG8iVHIf1KM for ; Fri, 25 Sep 2009 15:09:48 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id E3B8E3A6883 for ; Fri, 25 Sep 2009 15:09:47 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8PMAZ15013238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Sep 2009 18:10:36 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <8B1C4A45-653B-4A62-B10E-3102A8AA3225@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090925211041.5CC356BE572@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, 25 Sep 2009 18:10:34 -0400 References: <20090925211041.5CC356BE572@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Fri, 25 Sep 2009 22:09:48 -0000 On Sep 25, 2009, at 5:10 PM, Noel Chiappa wrote: > >> I think, for example, that we may return the answer to the source >> RLOC >> in the outer header, right? > > Err, what answer? Map-Registers are not acknowledged. Oh, right. Sorry. Please ignore my other comment about where the reply will be sent, as well... > >> Why is this set to 0? ... Why include the field in the Map-Register >> message if it will always be 0? > > Ummm, I think I might be the cause of that - unless it's there because > there's a desire to make all the control packets look similar (i.e. > include a > nonce field). > > When the issue of replay protection was raised, since replay is > generally an > on-path attack, I was trying to add a 'hook' to the Map-Register > packet that > would allow us to add replay protection _later_, without changing > the packet > format. (I.e. defer adding the _mechanism_ to deal with that attack > till > later, since it's an unlikely attack; but at the same time, putting > a field > in now would avoid interoperability problems - or using another > opcode for a > new format Map-Register - later. I.e. a cheap thing to do now - > since we're > chaning the packet format _anyway_ - to avoid a painful change > later.) I had > worked out a mechanism using a nonce, so perhaps that's what this is? > > But that's something of a guess! I'm not sure that I agree with setting aside this big block in the message to add replay protection later, but that isn't a blocking issue for me. If we are setting aside this field for later use, though, it should be labeled "reserved for later use", not "nonce". Margaret From mrw@sandstorm.net Fri Sep 25 15:15: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 84D933A698F for ; Fri, 25 Sep 2009 15:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.092, 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 15Z3CK9IAHEg for ; Fri, 25 Sep 2009 15:15:07 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id AA1553A6882 for ; Fri, 25 Sep 2009 15:15:07 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8PMGHnU013446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Sep 2009 18:16:17 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: "Joel M. Halpern" In-Reply-To: <4ABD3335.5060100@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: Fri, 25 Sep 2009 18:16:16 -0400 References: <20090925211041.5CC356BE572@mercury.lcs.mit.edu> <4ABD3335.5060100@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Fri, 25 Sep 2009 22:15:08 -0000 On Sep 25, 2009, at 5:16 PM, Joel M. Halpern wrote: > I want to be a bit careful here. > For me, the wording on the service interface is more than a bit > overstated, but as long as we treat it as interim, I'm fine with it. > I suspect that one of the issues driving things is a differing view > of the service being provided. But I need to have more discussions > with various folks before I can defend that proposition. My issue is not with the question of whether this is a service interface or not... My issue is that it says that this encapsulation is "the service interface", as in the only service interface, between the mapping system and the xTRs. However, I think that this encapsulation only applies to the Map-Request. The Map-Register and Map-Reply don't use it. Right? There is other wording that also implies that the Map- Register and Map-Reply will be encapsulated, and I want to confirm that they won't. Margaret From jnc@mercury.lcs.mit.edu Fri Sep 25 15:30: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 A6B7B3A67DB for ; Fri, 25 Sep 2009 15:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 EqN-LBcpY3cb for ; Fri, 25 Sep 2009 15:30:27 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 514F43A6882 for ; Fri, 25 Sep 2009 15:30:27 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3BF776BE572; Fri, 25 Sep 2009 18:31:38 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090925223138.3BF776BE572@mercury.lcs.mit.edu> Date: Fri, 25 Sep 2009 18:31:38 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Fri, 25 Sep 2009 22:30:28 -0000 > From: Margaret Wasserman > I think that this encapsulation only applies to the Map-Request. The > Map-Register and Map-Reply don't use it. Right? Well, I wouldn't call it 'encapsulation' - it's authentication field(s) added to Map-Request packets, and yes, AFAIK, the Map-Register and Map-Reply don't use it. > There is other wording that also implies that the Map- Register and > Map-Reply will be encapsulated, and I want to confirm that they won't. They will be 'encapsulated' (as in, wrapped inside another IP/UDP/LISP header), but they will not have these authentication fields (AFAIK). Was that what you were asking? Noel From jnc@mercury.lcs.mit.edu Fri Sep 25 15:42: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 253AE3A685D for ; Fri, 25 Sep 2009 15:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 qAmUMqT1XYjS for ; Fri, 25 Sep 2009 15:42:02 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 392B13A659A for ; Fri, 25 Sep 2009 15:42:02 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 669F76BE572; Fri, 25 Sep 2009 18:43:13 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090925224313.669F76BE572@mercury.lcs.mit.edu> Date: Fri, 25 Sep 2009 18:43:13 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Fri, 25 Sep 2009 22:42:03 -0000 > From: Margaret Wasserman > Oh, right. Sorry. De nada. We all get confused sometimes - I got horribly confused about the encapsulation stuff the other day! :-) > I'm not sure that I agree with setting aside this big block in the > message Umm, it is a control message, sent once a minute (on average). Are a few blank bytes there really an issue? BTW, ever looked at the HTML in a typical web page these days? :-) Darn things are completely enormous, filled with all sorts of lengthy JavaScript rubbish to do all sorts of totally useless flashy effects that Web programmers probably get paid enormous sums of money to add. Now _there_ is a _much_ bigger waste of space! > If we are setting aside this field for later use, though, it should be > labeled "reserved for later use", not "nonce". This is an interim rough working draft - I'm sure we'll find lots of little cleanup things to deal with before it stabilizes - if any of this text is still around in anything like this form by then. So I think we can let this sort of stuff slide until later? Noel From mrw@sandstorm.net Fri Sep 25 16:37: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 A78F83A6809 for ; Fri, 25 Sep 2009 16:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.088, 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 m12BLRib5p7j for ; Fri, 25 Sep 2009 16:37:05 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id D11DC3A6804 for ; Fri, 25 Sep 2009 16:37:04 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8PNc2qi016043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Sep 2009 19:38:03 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <298678EB-C3CE-4934-A776-BE9084C4EAED@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090925223138.3BF776BE572@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, 25 Sep 2009 19:38:02 -0400 References: <20090925223138.3BF776BE572@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Fri, 25 Sep 2009 23:37:05 -0000 On Sep 25, 2009, at 6:31 PM, Noel Chiappa wrote: > >> There is other wording that also implies that the Map- Register and >> Map-Reply will be encapsulated, and I want to confirm that they >> won't. > > They will be 'encapsulated' (as in, wrapped inside another IP/UDP/LISP > header), but they will not have these authentication fields (AFAIK). > Was > that what you were asking? No, that's not what I was asking... Vince's proposal indicated that we would change the encapsulation of the Map-Request (which was encapsulated in a LISP Data packet in the -04 draft) to use an outer header with port 4342 (instead of 4241) and a LISP Control message (instead of the LISP Data header) with a type of "Encapsulated Control Packet". Vince's proposal didn't say anything about encapsulating the Map- Register and Map-Reply messages in the new "Encapsulated Control Message" format. The Map-Register and Map-Reply are not encapsulated in the -04 draft, they are just sent as normal UDP/IP packets, and I don't think we agreed to change that. Did I miss something? Margaret From jnc@mercury.lcs.mit.edu Fri Sep 25 17:37: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 427EA3A6875 for ; Fri, 25 Sep 2009 17:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 otGzVw6usRII for ; Fri, 25 Sep 2009 17:37: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 963DC3A683E for ; Fri, 25 Sep 2009 17:37:09 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B87CB6BE572; Fri, 25 Sep 2009 20:38:20 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090926003820.B87CB6BE572@mercury.lcs.mit.edu> Date: Fri, 25 Sep 2009 20:38:20 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Sat, 26 Sep 2009 00:37:10 -0000 > From: Margaret Wasserman > No, that's not what I was asking... Ah, sorry, my turn to be confused... :-) > Vince's proposal indicated that we would change the encapsulation of > the Map-Request ... > .. didn't say anything about encapsulating the Map-Register and > Map-Reply messages in the new "Encapsulated Control Message" format. > ... they are just sent as normal UDP/IP packets, and I don't think we > agreed to change that. That is my understanding. > Did I miss something? No, not as far as I know. Just the Map-Request encapsulation was changed. Noel From rw@firstpr.com.au Sat Sep 26 01:35: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 A7AB33A6805 for ; Sat, 26 Sep 2009 01:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnmdBFIJbYPL for ; Sat, 26 Sep 2009 01:35:45 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 2E1883A67F0 for ; Sat, 26 Sep 2009 01:35:44 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 7D942175BEB; Sat, 26 Sep 2009 18:36:54 +1000 (EST) Message-ID: <4ABDD2AC.505@firstpr.com.au> Date: Sat, 26 Sep 2009 18:37:00 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: lisp@ietf.org References: <4AB8583E.5010002@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] LISP-NAT - explanation and support? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 26 Sep 2009 08:35:46 -0000 Hi Darrel, You wrote: >> Short version: Can anyone explain exactly how LISP-NAT is >> supposed to work, what it is useful for (especially >> in terms of what it can do which other approaches >> can't) and what its limitations are? >> >> Does anyone argue that LISP-NAT will actually >> be useful enough to be adopted? > > The LISP Interworking draft explains how LISP-NAT works, and why it is > useful. The current draft (2009-05-26): http://tools.ietf.org/html/draft-ietf-lisp-interworking-00 is the same as (2009-01-27): http://tools.ietf.org/html/draft-lewis-lisp-interworking-02 which is the same as (2008-07-10): http://tools.ietf.org/html/draft-lewis-lisp-interworking-01 Regarding LISP-NAT, all the above are only substantially different from the original version: http://tools.ietf.org/html/draft-lewis-lisp-interworking-00 2007-12-05 due to the addition of para 6.5. which remains the same today (including a typo "hbe"). To my understanding PTRs are both necessary and sufficient to solve the problem of getting packets addressed to EID addresses sent by hosts in networks which lack ITRs ("non-LISP sites") to the ETR of the destination network. Without this, no-one would want to adopt LISP-mapped EID address space. What does LISP-NAT add to PTRs in any realistic widespread adoption scenario? There is nothing in 6.5 which helps me understand why anyone would want to use LISP-NAT when there are PTRs covering their EID address space. Since the purpose of LISP is to reduce the number of routes in the DFZ, I assume that when LISP is introduced, all EIDs will be encompassed by a DFZ route advertised by one, or ideally many, widely distributed, PTRs. This single route covers the EID requirements of many LISP-using end-user networks, so the key goal of scalable routing is achieved. Does LISP-NAT have any role in a real world-wide adoption of LISP? Is there any explanation of how this would work, with examples? > LISP-NAT can be used in conjunction with Proxy Ingress Tunnel > Routers, or on its own to enable hosts at a LISP site to exchange > packets with hosts at a non-LISP site. Sites using LISP-NAT can on > their own decide their hosts from Non-Routable) EID space, while > communicating with non-LISP sites via its outside Routable (LISP-R) > EIDs. Thus it can be an alternative to using network based Interworking > infrastructure. I don't see why anyone would want to adopt LISP on this basis. > For an interesting discussion of the limitations of NAT in general, you > might read: > http://tools.ietf.org/id/draft-vogt-address-translation-harmfulness-03.t > xt which seems to cover most of the caveats of using NAT. > > You mentioned in an earlier email that you doubted whether LISP-NAT can > be made to actually work, but we have existence proof in the existing > LISP network that it can be implemented successfully. I also don't want > to be drawn into a debate about the pro's and cons of NAT, except to say > that it exists, and is popular for IPv4. Since NAT exists, and can be > applied to solve the Interworking problem, the authors decided to > include it in the Interworking specification and to experiment with it. OK - do you expect LISP to be voluntarily adopted by anyone if their EID space is not supported by PTRs? If so, how would such adoption help with scalable routing? "scalable" doesn't appear in these I-Ds. I first wrote a critique of LISP-NAT in December 2007: http://psg.com/lists/rrg/2007/msg00674.html As I wrote then, as far as I know: LISP-NAT provides no multihoming, portability etc. benefits, for the packets coming from the host in the site with no ITR - while PTRs provide all these the benefits. How can LISP-NAT enable a host in a non-LISP network to send packets to a host using an EID address, unless the communication is initiated by the host with the EID address? - Robin From luigi@net.t-labs.tu-berlin.de Sat Sep 26 04:20: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 1C6443A67BE for ; Sat, 26 Sep 2009 04:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.134, 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 w68m3IOjzhKj for ; Sat, 26 Sep 2009 04:20:45 -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 ABE2F3A683C for ; Sat, 26 Sep 2009 04:20:44 -0700 (PDT) Received: from dyn100.net.t-labs.tu-berlin.de (dyn100.net.t-labs.tu-berlin.de [130.149.220.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id BEED5700D28C; Sat, 26 Sep 2009 13:21:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/mixed; boundary=Apple-Mail-4-779008358 From: Luigi Iannone In-Reply-To: Date: Sat, 26 Sep 2009 13:21:55 +0200 Message-Id: References: <4AB9B6BE.6070006@cisco.com> To: Sam Hartman X-Mailer: Apple Mail (2.1076) Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] Call for interest in working on security X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 26 Sep 2009 11:20:48 -0000 --Apple-Mail-4-779008358 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Hi Sam, Upon request on the WG chairs a couple of IETFs ago we already started =20= to work on security (see attachment). Roque Gagliano also was interested in contributing to the attached =20 draft. The idea of the draft was to try to list all possible threats of the =20 loc/ID split paradigm, and then look how the LISP architecture deals =20= with each of them, pointing out if LISP is sufficiently secure, or if =20= some work has to be done on some specific cases. Seems that you are not happy with the advances since you started =20 something completely new on the security topic. Get a look to the draft and let me know if you find something useful =20 or you think we can merge the efforts. Coming back to you page, I really think that we should analyze the =20 mapping system from the inside. What I mean is that we do not need to =20= analyze the ALT, or whatever mapping system you like, the most =20 appropriate approach is IMO to give a set "guidelines/requirements" (I =20= do not have a better word right now) for designing a mapping system. Discussing if ALT provides the same level of security like BGP is IMHO =20= a waste of time. What level of security a mapping system has to guarantee/provide/=20 comply with? This is the kind of question we should answer. Then in the spec of each mapping system should be described how the =20 proposal fulfills the requirements of the security doc. Ciao Luigi On Sep 23, 2009, at 12:40 , Sam Hartman wrote: > I really appreciate your thoughtful comments. > > I'll admit that I am personally interested in the non-alt parts of > LISP security. My perhaps naive assumption is that something like > SIDR can be applied and that I'd like to get a better handle on the > surrounding landscape before I think in detail about that. > > However thinking about how the alt differed from traditional > BGP--particularly in terms of the implications of high aggrigation on > security--is something I had not done. > > One other comment: >>>>>> "Eliot" =3D=3D Eliot Lear writes: > Eliot> I will make the following two general assertions, as =20 > relates to your comment > Eliot> about key management: > > Eliot> =E2=80=A2 the problem is operationally difficult when = there =20 > are large numbers of > Eliot> signers and/or long trust chains. > Eliot> =E2=80=A2 a small number of signers requires concentration = of =20 > trust far beyond the > Eliot> point of what exists today (perhaps by 3 orders of =20 > magnitude or more), > Eliot> leading to potential continuity problems. > > Eliot> These were the trade-offs I explored with NERD. > > > These are interesting. However I don't think I have talked about key > management for anything involving signers at all so far. I've talked > about key management for map register, but there explicitly talked > about a solution with no public key ops. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-4-779008358 Content-Disposition: attachment; filename=draft-saucez-lisp-security-00.txt Content-Type: text/plain; name="draft-saucez-lisp-security-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Saucez Internet-Draft L. Iannone Intended status: Standards Track O. Bonaventure Expires: January 8, 2010 July 7, 2009 Notes on LISP Security Threats and Requirements draft-saucez-lisp-security-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 8, 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 Saucez, et al. Expires January 8, 2010 [Page 1] =0C Internet-Draft LISP Security July 2009 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 The present document is just a preliminary collection of notes about LISP security threats and requirements. Its purpose is to start a discussion on the subject among people that have shown interest in working on the matter. Saucez, et al. Expires January 8, 2010 [Page 2] =0C Internet-Draft LISP Security July 2009 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 4. Data-plane threats . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Security of the data stream . . . . . . . . . . . . . . . 5 4.2. LISP-encapsulated packet spoofing . . . . . . . . . . . . 5 4.3. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. LISP-Cache threats . . . . . . . . . . . . . . . . . . . . 6 4.4.1. LISP-Cache poisoning . . . . . . . . . . . . . . . . . 6 4.4.2. LISP-Cache overflow . . . . . . . . . . . . . . . . . 7 4.5. LISP-Database threats . . . . . . . . . . . . . . . . . . 8 4.6. DoS threats . . . . . . . . . . . . . . . . . . . . . . . 8 4.6.1. SMR bit . . . . . . . . . . . . . . . . . . . . . . . 8 4.6.2. Reachability Bits . . . . . . . . . . . . . . . . . . 8 4.6.3. Versioning . . . . . . . . . . . . . . . . . . . . . . 9 4.6.4. Gleaning . . . . . . . . . . . . . . . . . . . . . . . 9 4.6.5. Rate Limitation . . . . . . . . . . . . . . . . . . . 10 4.6.6. Mapping System and Filtering . . . . . . . . . . . . . 10 4.7. Other Attacks . . . . . . . . . . . . . . . . . . . . . . 11 4.7.1. Time-shifted attacks . . . . . . . . . . . . . . . . . 11 4.7.2. Amplification attacks . . . . . . . . . . . . . . . . 11 5. Control-plane threats . . . . . . . . . . . . . . . . . . . . 11 5.1. Control-plane Requirements . . . . . . . . . . . . . . . . 12 5.2. LISP-Database coherence . . . . . . . . . . . . . . . . . 12 5.3. LISP Map Server . . . . . . . . . . . . . . . . . . . . . 12 6. Interaction between Data- and Control-plane . . . . . . . . . 13 6.1. Data-plane side effects on the control-plane . . . . . . . 13 6.2. Control-plane side effects on the data-plane . . . . . . . 13 6.3. Data-plane threats leveraging on the control-plane . . . . 13 6.4. Control-plane threats leveraging on the data-plane . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Saucez, et al. Expires January 8, 2010 [Page 3] =0C Internet-Draft LISP Security July 2009 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction The Locator/ID Separation Protocol (LISP) is defined in draft-ietf-lisp-01.txt [I-D.ietf-lisp]. The present document aims at identifying threats in the current LISP specification and possibly list a set of requirements or mechanism needed to increase its security. A preliminary security analysis on LISP has been conducted by M. Bagnulo in [I-D.bagnulo-lisp-threat]. This document is split in two main parts; one concerning the Data- plane and one concerning the Control-Plane. The LISP data-plane consists of LISP packet encapsulation, decapsulation, and forwarding and includes the LISP-Cache and LISP- Database data structures needed to perform such operations. The present document will try to analyze the possible threats of the data-plane. The LISP control-plane consists in the mapping distribution system, which can be one of the mapping distribution protocols proposed so far (e.g., [I-D.ietf-lisp-ms], [I-D.ietf-lisp-alt], [I-D.meyer-lisp-cons], and [I-D.lear-lisp-nerd] ), and the set of Map-Request and Map-Reply messages. The present document will not analyze all possible threats of each specific mapping distribution protocol. Rather, this document will try to find a common set of requirements that every present and future mapping distribution protocol should satisfy in order to reduce as much as possible threats related to the LISP control-plane. 3. Definition of Terms To be Done. 4. Data-plane threats This section contains some threats and attacks related to the LISP data-plane. By LISP data-plane it is intended the operations of encapsulation, decapsulation, and forwarding as well as the content of the LISP-Cache and LISP-Database as specified in the original LISP Saucez, et al. Expires January 8, 2010 [Page 4] =0C Internet-Draft LISP Security July 2009 document ([I-D.ietf-lisp]). 4.1. Security of the data stream In some context it could be necessary to secure the data stream that is LISP encapsulated. This can be achieved with two different approaches: o Securing messages. In this approach a field needs to be added to the LISP header in order to secure the content. o Securing the transport protocol. An example of this approach is the use of IPSEC to secure the content of the original, non LISP- encapsulated, packet. What is the approach suitable in the LISP context? 4.2. LISP-encapsulated packet spoofing Like any other type of packet in the Internet, LISP encapsulated packets can also be spoofed. Generally the term "spoofed packet" indicates a packet containing a source IP address which is not the one of the actual originator of the packet. Since LISP uses encapsulation, this translates in two types of spoofing: o EID Spoofing: The originator of the packet put in it a spoofed EID. The packet will be normally encapsulated by the ITR of the site. o RLOC Spoofing: The originator of the packet generates directly a LISP-encapsulated packet with a spoofed source RLOC. Note that the two types of spoofing are not mutually exclusive, rather all combinations are possible and can be used to perform several kind of attacks. The work done in the SAVI WG ([SAVI]) can be useful in mitigating spoofing. It is worth to notice that in the context of LISP, there is also the possibility to spoof part of the content of the LISP-specific header in order to perform some attacks. The various possibilities are listed in the following sections, while describing the possible attacks. Saucez, et al. Expires January 8, 2010 [Page 5] =0C Internet-Draft LISP Security July 2009 4.3. Nonce The "Nonce" gives some basic security support by acting as a "session cookie", similar to what is used in L2TP ([I-D.ietf-l2tpext-l2tp-base]). The use of the Nonce to mitigate some of the possible attacks is described in the following sections. There should be an explicit discussion on the limits of the Nonce? 4.4. LISP-Cache threats A key component of the overall LISP architecture is the LISP-Cache. The LISP-Cache is the data structure that stores the bindings between EID and RLOC (namely the "mappings") to be used later on. Attacks against this data structure can happen either when the mappings are first installed in the cache (see also Section 5) or by corrupting (poisoning) the mappings already present in the cache. 4.4.1. LISP-Cache poisoning The content of the LISP-Cache can be poisoned by spoofing LISP encapsulated packets. Example of LISP-Cache poisoning are: Fake mapping: The cache contains entirely fake mappings that do not originate from an authoritative mapping server. This can be achieved either through the gleaning as described in Section 4.6.4 or by attacking the control-plane as described in Section 5. EID Poisoning: The EID-Prefix in a specific mapping is not owned by the originator of the entry. Similarly to the previous case, this can be achieved either through the gleaning as described in Section 4.6.4 or by attacking the control-plane as described in Section 5. EID redirection/RLOC poisoning: The EID-Prefix in the mapping is not binded to (located by) the set of RLOCs present in the mapping. This can result in traffic redirected elsewhere, eavesdropped, or even blackholed. Note that not necessarily all RLOCs are fake/spoofed. The attack works also if only part of the RLOCs, the highest priority ones, are compromised. Again, this can be achieved either through the gleaning as described in Section 4.6.4 or by attacking the control-plane as described in Section 5. Saucez, et al. Expires January 8, 2010 [Page 6] =0C Internet-Draft LISP Security July 2009 Reachability poisoning: The reachability information stored in the mapping could be poisoned, redirecting the traffic to a subset of the RLOCs (or even stopping it if reachability bits are all set to 0). If reachability information is not verified through the control-plane this attack can be simply achieved by sending a spoofed packet with swapped or all reachability bits reset. The same result can be obtained by attacking the control-plane as described in Section 5. Traffic Engineering information poisoning: The LISP protocol defines two attributes associated to each RLOC in order to perform inbound Traffic Engineering: namely priority and weight. By injecting fake TE attributes, the attacker is able to break load balancing policies and concentrate all the traffic on one single RLOC or put more load on a RLOC than what is expected, creating congestion. Corrupting the TE attributes can be achieved by attacking the control-plane as described in Section 5. Mapping TTL poisoning: The LISP protocol associate a Time-To-Live to each mapping that, ones expired, allows to delete a mapping from the LISP-Cache (or forces a Map-Request/Map-Reply exchange to refresh it if still needed). By injecting fake TTL values, an attacker can either shrink the Cache (using very short TTL), thus creating an excess of cache miss causing a DoS on the mapping system, or it can increase the size of the cache by putting very high TTL values, up to a cache overflow (see Section 4.4.2). Corrupting the TTL can be achieved by attacking the control-plane as described in Section 5. If the above listed attacks succeed, the attacker has the means of controlling the traffic. 4.4.2. LISP-Cache overflow Depending on how the LISP-cache is managed (e.g., LRU vs. LFU) and depending on its size, an attacker can try to fill the cache with fake mappings. Once the cache is full, some mapping will be replaced by new fake ones, causing traffic disruption. This can be achieved either through the gleaning as described in Section 4.6.4 or by attacking the control-plane as described in Section 5. Another way to generate a LISP-Cache overflow is by injecting mapping with a fake and very large TTL value. In this case the cache will keep a large amount of mappings ending with a completely full cache. This type of attack is also performed through the control-plane. Saucez, et al. Expires January 8, 2010 [Page 7] =0C Internet-Draft LISP Security July 2009 4.5. LISP-Database threats The LISP-Database data structure is meant to contain the mappings that are "owned" locally, i.e., the mappings that are used for selecting the source RLOC when encapsulating, and binding the EID- Prefix downstream the xTR and the RLOCs present on the xTR. The simplest way to fill the LISP-Database is by configuration on each single xTR. This secure the data structure as much as the xTR itself is robust to intrusions. Nevertheless, part of the information contained in the mappings that are in the LISP-Database are subject to change in time, e.g., reachability information, TE attributes, etc. The way mappings are updated can open security breaches allowing attackers to poison or corrupt the LISP-Database in a way similar to the LISP-Cache. These attacks are more related to the control-plane and will be discussed in Section 5. 4.6. DoS threats This section tries to list all possible DoS attacks and suggests, when possible, mechanisms that help in mitigating the threat. 4.6.1. SMR bit This DoS attack is based on sending a burst of packets with the SMR bit set. In turn, this will trigger a burst of Map-Request, thus finally the target of the attack is the control-plane. Several counter-measures can be introduced to mitigate its effects: o Ignore SMR bit if nonce does not change. o In the case of versioning, ignore SMR bit if version number has not changed. o Rate limitation can be used to reduce the number of issued Map- Request packets. 4.6.2. Reachability Bits Reachability bits should be used only as a hint, meaning that upon reception of a packet having Reach-Bits different from what stored in the mapping present in the LISP-Cache, a Map-Request is issued in order to have confirmation of the change. However, with this behavior, an attacker can send a burst of packets with different reach-bits in order to trigger a burst of Map-Request packets, thus again attacking the control-plane. Several counter-measures can be Saucez, et al. Expires January 8, 2010 [Page 8] =0C Internet-Draft LISP Security July 2009 introduced to mitigate its effects: o Ignore Reach-Bits if nonce does not change. o In the case of versioning, ignore Reach-bits if version number has not changed. o Rate limitation can be used to reduce the number of issued Map- Request packets. 4.6.3. Versioning If versioning is used, upon reception of a packet having a different version number, compared to the one stored in the mapping present in the LISP-Cache, a Map-Request is issued in order to have confirmation of the change. An attacker can send a burst of packets with different version numbers in order to trigger a burst of Map-Request packets, thus again attacking the control-plane. Several counter- measures can be introduced to mitigate its effects: o Random version numbers can be ignored. Map-Request is sent only if the new version number is the successor of the one stored in the LISP-Cache. Further, since the LISP header transports both source version number and destination version number in order to trigger a Map-Request an attacker as to correctly set the two version numbers, limiting the range of possible attackers only to the ones able to eavesdrop the traffic (Man-In-The-Middle attack). Further details about how to filter packets with wrong version numbers can be found in [I-D.iannone-lisp-mapping-versioning] o For the few packets that unlawfully trigger Map-Requests, Rate limitation can be used. 4.6.4. Gleaning Gleaning is used to install in the LISP-Cache a partial mapping created by gleaning the source EID and source RLOC from the first packet of a flow. The mapping is considered "partial" because it just associate an EID (/32) to one single RLOC, not the EID-Prefix the EID belongs to with the complete set of RLOCs. Gleaning can be used to perform several different attacks: o LISP-Cache poisoning: an attacker can use gleaning to install fake mappings in the LISP-Cache (by spoofing the EID). See LISP-Cache poisoning in Section 4.4.1. o LISP-Cache overflow: an attacker can use gleaning to install a large number of mappings in the LISP-Cache until filling it up. Saucez, et al. Expires January 8, 2010 [Page 9] =0C Internet-Draft LISP Security July 2009 See LISP-Cache overflow in Section 4.4.2. Since the mapping installed in the LISP-Cache is not for a EID-Prefix but for a full /32 address, by sending a burst of packet for several different spoofed EIDs, an attacker could end up filling the Cache. o Map-Request burst: if for each mapping installed by a gleaning a Map-Request is issued to retrieve the full mapping, an attacker can send a burst of different packets generating a burst of Map- Request. Note that in this case, if Map-Request rate limitation is done on a per-EID basis, the attacker can easily bypass the rate limitation by putting different EID in the packets causing the gleaning. Possible counter-measure to mitigate this issue: o The LISP-Cache poisoning and overflow issues can be solved by filtering spoofed EIDs on the ITR (see Section 4.2). o To reduce the Map-Request burst an approach is to send a Map- Request only if a certain amount of traffic has been sent using the gleaned entry, as suggested in [Saucez09]. 4.6.5. Rate Limitation The Rate-Limitation policy, used to reduce the effects of some types of DoS attacks can be itself used for a DoS attack. An attacker can send some fake packets in order to generate a burst of Map-Request packets that will be rate limited. When a legitimate packet generates a legitimate Map-Request, this will be delayed or dropped due to rate limitation, causing an increased latency. o Any solution for this? 4.6.6. Mapping System and Filtering The use of some form of filtering can help in avoid or at least mitigate some types of attacks. On ITRs, packets should be encapsulated only if the source EID is effectively part of the EID-Prefix downstream the ITR. Further, still on ITRs, packets should be encapsulated only if a mapping obtained from the mapping system is present in the LIP-Cache. On ETRs, packets should be decapsulated only if the destination EID is effectively part of the EID-Prefix downstream the ETR. Further, still on ETRs, packets should be decapsulated only if a mapping for the source EID is present in the LISP-Cache and has been obtained through the mapping system (not gleaned). Saucez, et al. Expires January 8, 2010 [Page 10] =0C Internet-Draft LISP Security July 2009 Note that this filtering, since complete mappings need to be installed in both ITRs and ETRs, can introduce a higher connection setup latency and hence potentially more packets drops due to the lack of mappings in the LISP-Cache. 4.7. Other Attacks 4.7.1. Time-shifted attacks A time-shifted attack is an attack where the attacker is temporarily on the path between two communicating hosts. While it is on-path, the attacker sends specially crafted packets or modifies packets exchanged by the communicating hosts in order to disturb the flow of packets (e.g. by performing a man in the middle attack). An important issue for time shifted attacks is the duration of the attack once the attacker has left the path between the two communicating hosts. 4.7.2. Amplification attacks An amplification attack occurs when an attacker sends a small packet with a spoofed source to a host or router that replies by sending a longer packet to the spoofed source. To reduce the impact of such attacks, protocol designers try to avoid sending a long response after having received a small packet from a potentially spoofed source. 5. Control-plane threats As pointed out in the previous sections, a good share of attacks can be avoided by securing the LISP control plane. Here the focus is not to analyze the security threats of any specific mapping distribution protocol. Rather, the focus is to find a common set of requirements that existing or future mapping distribution protocols have to fulfill in order provide a sufficient level of security. The LISP Map Server protocol will instead be analyzed since it is not related to any specific mapping distribution protocol. Work and experience performed in the DNSSEC [RFC4033] and SIDR [SIDR] can be useful here. Saucez, et al. Expires January 8, 2010 [Page 11] =0C Internet-Draft LISP Security July 2009 5.1. Control-plane Requirements o Authenticate the origin of a message. o Identify the origin of a message. o Prove that the mapping is generated by the owner of the EID or a third party allowed to generate such a mapping. o Inject mappings in the mapping system only if the EID is allowed to be in the mapping system. o Prove that the RLOCs associate to a mapping belong to the xTRs owning the mapping's EID. o Low message overhead. o Low traffic overhead. o Low time overhead (avoid multiple RTTs). o Other? 5.2. LISP-Database coherence The mappings present on the LISP-Database of the different xTRs of a site should always be coherent. An attacker should not be able to install different mappings for different xTRs. A simple approach is to have a central authority in the site that pushes all the mappings in the xTRs. When a xTR decides to change something it informs the central authority, which will push the information to the other xTRs. Each xTR is authoritative on the reachability of its locator. An xTR is not allowed to send updates to the central entity only if it is one of its RLOC. The central authority knows the configuration which RLOC is owned by which xTR. All of this does not prevent from securing the exchanges between the xTRs and the central authority in order to avoid spoofing attacks. 5.3. LISP Map Server The LISP Map Server is a fundamental building block of the whole LISP architecture, providing an additional level of indirection allowing Saucez, et al. Expires January 8, 2010 [Page 12] =0C Internet-Draft LISP Security July 2009 to run mapping distribution protocols on machines different from xTRs. =46rom this point of view it can be considered a security improvement since xTR are not directly involved in the mapping distribution system. Things to look closer: o Threats concerning messages. o DoS attacks. o Threats concerning LISP Map Server with caching. o Others? 6. Interaction between Data- and Control-plane It is clear that attacks targeting the data-plane can have side- effects on the control-plane and vice-versa. Furthermore, attacks to the control-plane can be performed leveraging on the data-plane and vice-versa. An analysis of the possible threats has been performed in the previous sections. Here we just characterize them following the above mentioned classification. 6.1. Data-plane side effects on the control-plane To be done. 6.2. Control-plane side effects on the data-plane To be done. 6.3. Data-plane threats leveraging on the control-plane To be done. 6.4. Control-plane threats leveraging on the data-plane To be done. 7. IANA Considerations This document makes no request of the IANA. Saucez, et al. Expires January 8, 2010 [Page 13] =0C Internet-Draft LISP Security July 2009 8. Security Considerations Security considerations are the core of this document and do not need to be further discussed in this section. 9. Acknowledgments This work has been partially supported by the INFSO-ICT-216372 TRILOGY Project (www.trilogy-project.org). 10. Normative References [I-D.bagnulo-lisp-threat] Bagnulo, M., "Preliminary LISP Threat Analysis", draft-bagnulo-lisp-threat-01 (work in progress), July 2007. [I-D.iannone-lisp-mapping-versioning] Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Versioning", draft-iannone-lisp-mapping-versioning-00 (work in progress), March 2009. [I-D.ietf-l2tpext-l2tp-base] Lau, J., "Layer Two Tunneling Protocol (Version 3)", draft-ietf-l2tpext-l2tp-base-15 (work in progress), December 2004. [I-D.ietf-lisp] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-01 (work in progress), May 2009. [I-D.ietf-lisp-alt] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-01 (work in progress), May 2009. [I-D.ietf-lisp-ms] Fuller, V. and D. Farinacci, "LISP Map Server", draft-ietf-lisp-ms-01 (work in progress), May 2009. [I-D.lear-lisp-nerd] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-04 (work in progress), April 2008. [I-D.meyer-lisp-cons] Saucez, et al. Expires January 8, 2010 [Page 14] =0C Internet-Draft LISP Security July 2009 Brim, S., "LISP-CONS: A Content distribution Overlay Network Service for LISP", draft-meyer-lisp-cons-04 (work in progress), April 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [SAVI] IETF, "Source Address Validation Improvements Working Group", . [SIDR] IETF, "Secure Inter-Domain Routing Working Group", . [Saucez09] Saucez, D. and L. Iannone, "How to mitigate the effect of scans on mapping systems", Submitted to the Trilogy Summer School on Future Internet. Authors' Addresses Damien Saucez Luigi Iannone Olivier Bonaventure Saucez, et al. Expires January 8, 2010 [Page 15] =0C --Apple-Mail-4-779008358-- From luigi@net.t-labs.tu-berlin.de Sat Sep 26 06:12: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 E5EB03A6833 for ; Sat, 26 Sep 2009 06:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=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 Fvn45ZA8+0-A for ; Sat, 26 Sep 2009 06:12:46 -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 AE45C3A67C1 for ; Sat, 26 Sep 2009 06:12:45 -0700 (PDT) Received: from dyn100.net.t-labs.tu-berlin.de (dyn100.net.t-labs.tu-berlin.de [130.149.220.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id A649B700D293 for ; Sat, 26 Sep 2009 15:13:56 +0200 (CEST) From: Luigi Iannone Content-Type: multipart/alternative; boundary=Apple-Mail-5-785729427 Date: Sat, 26 Sep 2009 15:13:56 +0200 Message-Id: <0F04DDD8-A0DB-4ECD-A513-F4D6DC942F1A@net.t-labs.tu-berlin.de> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [lisp] Clarification on issue #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: Sat, 26 Sep 2009 13:12:47 -0000 --Apple-Mail-5-785729427 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, The current description of issue #16 Map Versioning Discussion is a bit misleading. The current one is: 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. After the discussion on the mailinglist (also concerning the R-bit) I think that a more exact description would be: New proposed one: draft-iannone-lisp-mapping-versioning-00 proposes introducing the optional possibility for LISP header to transport map version numbers. Luigi will provide a new version of the draft which will include both discussion from the mailinglist as well as the discussion with all LISP developers. This means that all the details of the map versioning support will be detailed in the versioning draft and not in the main LISP specs. After publication of the new map versioning draft, the WG will discuss its technical validity and how to proceed with the work. Would be possible to change the description on the issue tracker? Luigi --Apple-Mail-5-785729427 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

The current = description of issue #16 Map Versioning Discussion is a bit = misleading.

The current one = is:

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.

After the = discussion on the mailinglist (also concerning the R-bit) I think that a = more exact description would be:

New proposed = one:

draft-iannone-lisp-mapping-versioning-00 proposes = introducing the optional possibility for LISP header to transport map = version numbers. Luigi will provide a new version of the draft which = will include both discussion from the mailinglist as well as the = discussion with all LISP developers. This means that all the details of = the map versioning support will be detailed in the versioning draft and = not in the main LISP specs.
After publication = of the new map versioning draft, the WG will discuss its technical = validity and how to proceed with the = work.


Would be possible to change the = description on the issue tracker?


Luigi

= --Apple-Mail-5-785729427-- From lear@cisco.com Sat Sep 26 07:25: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 883AE3A684E for ; Sat, 26 Sep 2009 07:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.235 X-Spam-Level: X-Spam-Status: No, score=-10.235 tagged_above=-999 required=5 tests=[AWL=0.364, 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 PcZMljq9ratl for ; Sat, 26 Sep 2009 07:25:04 -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 329473A6358 for ; Sat, 26 Sep 2009 07:25:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAAANnBvUqQ/uCLe2dsb2JhbACBUJkyAQEWJAahXohTAY8yBYQe X-IronPort-AV: E=Sophos;i="4.44,456,1249257600"; d="scan'208";a="50308869" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Sep 2009 14:26: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 n8QEQGat001400; Sat, 26 Sep 2009 16:26:16 +0200 Received: from elear-mac.local (ams3-vpn-dhcp4167.cisco.com [10.61.80.70]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8QEQFkD022662; Sat, 26 Sep 2009 14:26:16 GMT Message-ID: <4ABE2487.5000302@cisco.com> Date: Sat, 26 Sep 2009 16:26:15 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Luigi Iannone References: <4AB9B6BE.6070006@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=829; t=1253975176; x=1254839176; 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]=20Call=20for=20interest=20in=20w orking=20on=20security |Sender:=20; bh=QY6S+XEgvEUZ92MqtI32cpAjscOdtg7tFQkTGov4Qc8=; b=nqLeBFcUKeIAQ4ViKrg/SRQdNgwlTnQHniLnPrOtadmpjIQiproGzUAQOB yPOzuR4fi3ouAy4/1moL2yJGv62nda3EYHvBBwkCFkRmBTHYj0CzKZ7BaIcL 60pbjA5Wr7; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] Call for interest in working on security X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 26 Sep 2009 14:25:05 -0000 Luigi, > > Discussing if ALT provides the same level of security like BGP is IMHO > a waste of time. > > What level of security a mapping system has to > guarantee/provide/comply with? > This is the kind of question we should answer. I think both questions are valid. We need to answer the former before letting something loose out on the network. In order to do that there needs to be some comparison. That having been said, I would imagine that the comparison is made easier by answering your 2nd question, because quite frankly it has GOT to be possible to do better than what is out there today. The question I've always hit against is whether you can do so in a way that doesn't concentrate operational risk into a few components, something that is somewhat antithetical to most L3 dogma. Eliot From luigi@net.t-labs.tu-berlin.de Sat Sep 26 11: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 2D9E83A6928 for ; Sat, 26 Sep 2009 11:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 dNktY-kJsIlv for ; Sat, 26 Sep 2009 11:14:57 -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 649AE3A68C2 for ; Sat, 26 Sep 2009 11:14:57 -0700 (PDT) Received: from [192.168.2.101] (p4FC25398.dip.t-dialin.net [79.194.83.152]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id C29CC700D293; Sat, 26 Sep 2009 20:16:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Luigi Iannone In-Reply-To: <4ABE2487.5000302@cisco.com> Date: Sat, 26 Sep 2009 20:16:06 +0200 Content-Transfer-Encoding: 7bit Message-Id: <80FD669A-E5F7-4084-84E3-D104670EC11E@net.t-labs.tu-berlin.de> References: <4AB9B6BE.6070006@cisco.com> <4ABE2487.5000302@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1076) Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] Call for interest in working on security X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 26 Sep 2009 18:14:58 -0000 Eliot, I agree with you, let me just add a clarification On Sep 26, 2009, at 16:26 , Eliot Lear wrote: > Luigi, > >> >> Discussing if ALT provides the same level of security like BGP is >> IMHO >> a waste of time. My point here was that the security of ALT should be discussed in the ALT spec, not in the general security document. If we start talking about ALT in the general security framework we will focus on ALT and will miss the bigger picture. Luigi >> >> What level of security a mapping system has to >> guarantee/provide/comply with? >> This is the kind of question we should answer. > > I think both questions are valid. We need to answer the former before > letting something loose out on the network. In order to do that there > needs to be some comparison. That having been said, I would imagine > that the comparison is made easier by answering your 2nd question, > because quite frankly it has GOT to be possible to do better than what > is out there today. The question I've always hit against is whether > you > can do so in a way that doesn't concentrate operational risk into a > few > components, something that is somewhat antithetical to most L3 dogma. > > Eliot From mrw@sandstorm.net Sat Sep 26 18:31: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 247F63A68C4 for ; Sat, 26 Sep 2009 18:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.083, 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 qGDqrhSM80xa for ; Sat, 26 Sep 2009 18:31:56 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 6175D3A6875 for ; Sat, 26 Sep 2009 18:31:56 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8R1WsrH080596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 26 Sep 2009 21:32:55 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <6DA213EB-0F77-470B-BDF9-A49D6AB5D4FB@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090926003820.B87CB6BE572@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: Sat, 26 Sep 2009 21:32:55 -0400 References: <20090926003820.B87CB6BE572@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Sun, 27 Sep 2009 01:31:57 -0000 On Sep 25, 2009, at 8:38 PM, Noel Chiappa wrote: > > No, not as far as I know. Just the Map-Request encapsulation was > changed. The proposed text that Dino sent is not consistent with this... It implies that the encapsulated format will be used for all communication between the xTRs and the mapping system at the top. In the later text, in the description of the UDP ports for the inner header, it talks about what they will be set to for Map-Replies and Map-Registers. Margaret From mrw@sandstorm.net Sat Sep 26 18:33: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 F1B9B3A68C5 for ; Sat, 26 Sep 2009 18:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.080, 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 Ypf5zD3hRyvH for ; Sat, 26 Sep 2009 18:33:16 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 3CD3B3A690D for ; Sat, 26 Sep 2009 18:33:16 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8R1YSwL080711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 26 Sep 2009 21:34:28 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Margaret Wasserman In-Reply-To: <6DA213EB-0F77-470B-BDF9-A49D6AB5D4FB@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: Sat, 26 Sep 2009 21:34:28 -0400 References: <20090926003820.B87CB6BE572@mercury.lcs.mit.edu> <6DA213EB-0F77-470B-BDF9-A49D6AB5D4FB@sandstorm.net> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Sun, 27 Sep 2009 01:33:17 -0000 On Sep 26, 2009, at 9:32 PM, Margaret Wasserman wrote: > > On Sep 25, 2009, at 8:38 PM, Noel Chiappa wrote: >> >> No, not as far as I know. Just the Map-Request encapsulation was >> changed. > > The proposed text that Dino sent is not consistent with this... It > implies that the encapsulated format will be used for all > communication between the xTRs and the mapping system at the top. > In the later text, in the description of the UDP ports for the inner > header, it talks about what they will be set to for Map-Replies and > Map-Registers. s/Map-Replies and Map-Registers/Map_Requests, Map-Replies and Map- Registers Margaret From dino@cisco.com Sat Sep 26 21:07: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 B5B4A3A68D0 for ; Sat, 26 Sep 2009 21:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 2pn4K6V0q3QM for ; Sat, 26 Sep 2009 21:07:21 -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 6EE9A3A681D for ; Sat, 26 Sep 2009 21:07:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHeCvkqrR7MV/2dsb2JhbAC8IohTAY5RBYQegV0 X-IronPort-AV: E=Sophos;i="4.44,459,1249257600"; d="scan'208";a="397001562" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Sep 2009 04:08:36 +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 n8R48a9v019314; Sat, 26 Sep 2009 21:08:36 -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 n8R48a5Q003264; Sun, 27 Sep 2009 04:08:36 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); Sat, 26 Sep 2009 21:08:35 -0700 Received: from [192.168.1.2] ([10.21.76.235]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Sep 2009 21:08:31 -0700 Message-Id: <2A7D106B-D5A0-4338-BB45-39DE9E6FB048@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <8F75FB29-FC8E-4C3C-A91A-15A10E917936@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: Sat, 26 Sep 2009 21:08:30 -0700 References: <3D19B2AF-6434-4CE4-88EA-A4414EFCD582@cisco.com> <8F75FB29-FC8E-4C3C-A91A-15A10E917936@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Sep 2009 04:08:32.0077 (UTC) FILETIME=[2D105FD0:01CA3F28] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6837; t=1254024516; x=1254888516; 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]=20Proposed=20change=20to=20draft -ietf-lisp-05.txt |Sender:=20; bh=q3Ihn4CqtWnqiCTb6emVa5FW5sPqdAvfhpS4qNFFSY4=; b=Wj5U+4IwENK2b01/jueZMiqKih9JHrBrjliGtNMTt/Aji4qjEleLFbrxMf 6IAJcyV+tNs/f54efFdBnr5Qg1Py4cMlldPFpXht5RLXJCcpt1S40oghP6va gmGK4iSfkIZS9A7IKRUb+iIchR1SvF7ULapdYxPSZ+6oJczuXfO8M=; 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] Proposed change to draft-ietf-lisp-05.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: Sun, 27 Sep 2009 04:07:22 -0000 > > Hi DIno, > > Thanks for putting this summary together, it was very helpful to me > in understanding what you plan to change. Thanks. > A have a few questions/comments about the proposed changes: > >> An Encapsulated Control Message is used as the service interface >> between ITRs, ETRs, and the mapping database system described in >> [LISP-MS]. > > If I understood correctly, only the Map-Request would be encapsulated > this way, right? The Map-Register and Map-Reply packets would not, Right. > right? So, saying that this is the service interface between ITRs, > ETRs > and the mapping database system would seem to be an overstatement. Why is that? > >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> / | IPv4 or IPv6 >> Header | >> OH | (uses RLOC >> addresses) | >> \ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> / | Source Port = xxxx | Dest Port = >> 4342 | >> UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> \ | UDP Length | UDP >> Checksum | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> LH |Type=8 | >> Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> / | IPv4 or IPv6 >> Header | >> IH | (uses RLOC or EID >> addresses) | >> \ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> / | Source Port = xxxx | Dest Port = >> yyyy | >> UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ > > I thought that the inner UDP destination port would also be 4342, as > the next > thing up is also a LISP control message. I kept it unspecified because a Map-Reply or Map-Register *could* be encapsulated as well. At least the packet format could allow it even though the text doesn't indicate that anywhere. That is, only a Map- Request can be encapsulated and that *is* specified. > >> \ | UDP Length | UDP >> Checksum | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> LCM | LISP Control >> Message | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> >> UDP: The inner UDP header where the port assignments depends on >> the >> control packet being encapsulated. When the control packet is a >> Map-Request or Map-Register, the source port is randomly assigned >> and the destination port is 4342. When the control packet is a >> Map-Reply, the source port is 4342 and the destination port is >> assigned from the source port of the invoking Map-Request. Port >> number 4341 MUST NOT be assigned to either port. The checksum >> > > As indicated above, I believe that this particular encapsulation > diagram will > only be used for Map-Register, so much of this text should be > reworked. I > also think it will always have a UDP destination port of 4342, right? This *could* be a feature. I'd like to keep it there. The code should be able to decode any control packet type that is encapsulated. >> LCM: The format is one of the control message formats described in >> this section. > > Is it worth stating that you can't have an Encapsulated Control > Message > inside an Encapsulated Control Message? No, I don't think so. If it is necessary to have another level of indirection, you may want to do so. We (cisco) have seen many protocols designed where a service provider would deploy the protocol and a virtualized user would want to implement the same service. So encapsulating control messages that are just messages for the underlying LISP may be a useful feature. But I'm not willing to specify it at this point. There is no reason to create a "Map-Request Encapsulated Control Message" and then later create another one for say any new control packet we introduce (or for Map-Replies or Map-Requests). > [...] >> >> Authentication Data Length: The length in bytes of the >> Authentication Data field that follows this field. The length of >> the the Authentication Data field is dependent on the Message >> Authentication Code (MAC) algorithm used. The length field >> allows >> a device that doesn't know the MAC algorithm to correctly parse >> the packet. >> >> Authentication Data: The message digest used from the output of the >> Message Authentication Code (MAC) algorithm. The entire Map- >> Register payload is authenticated with this field preset to 0. >> After the MAC is computed, it is placed in this field. >> Implementations of this specification MUST include support for >> HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 >> [RFC4634] >> is recommended. > > Is it really sufficient to hash only the Map-Register payload? Or > do you need to hash (at least some fields of) the protocol headers, > as well? I think, for example, that we may return the answer to the What is being authenticated is the EID-prefix data. And if you sent different EID-prefixes from different ETRs of the same site to different Map-Servers, you could use different keys and therefore compute different MACs. > source RLOC in the outer header, right? Are there any other fields > in the outer header that may need to be checked to ensure that the > Map-Reply is being sent to the right place, or that this Map-Request > was really sent by who we think it was? I don't think so. >> Nonce: This 8-byte Nonce field is set to 0 in Map-Register >> messages. > > Why is this set to 0? Wouldn't this still be useful to determine > that a reply was actually in response to our request? Why include > the field in the Map-Register message if it will always be 0? Because it is not used. I think I'll remove the nonce from the Map- Register. Is that okay with everyone? Since the Map-Register is a one- way packet, the map-server can't do anything with it. > Margaret Dino From dino@cisco.com Sat Sep 26 21:11: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 263833A68D7 for ; Sat, 26 Sep 2009 21:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 o58-9Ihth5Dk for ; Sat, 26 Sep 2009 21:11:07 -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 3E53E3A68A6 for ; Sat, 26 Sep 2009 21:11:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKODvkqrR7PD/2dsb2JhbAC8I4hTAY5PBYQe X-IronPort-AV: E=Sophos;i="4.44,459,1249257600"; d="scan'208";a="397002771" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Sep 2009 04:12:19 +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 n8R4CJiD005537; Sat, 26 Sep 2009 21:12:19 -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 n8R4CJ3t020869; Sun, 27 Sep 2009 04:12:19 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); Sat, 26 Sep 2009 21:12:18 -0700 Received: from [192.168.1.2] ([10.21.76.235]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Sep 2009 21:12:18 -0700 Message-Id: From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <298678EB-C3CE-4934-A776-BE9084C4EAED@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: Sat, 26 Sep 2009 21:12:18 -0700 References: <20090925223138.3BF776BE572@mercury.lcs.mit.edu> <298678EB-C3CE-4934-A776-BE9084C4EAED@sandstorm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Sep 2009 04:12:18.0658 (UTC) FILETIME=[B41DE420:01CA3F28] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=634; t=1254024739; x=1254888739; 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=20change=20to=20draft -ietf-lisp-05.txt |Sender:=20; bh=WHyJwYdanKUApbaNoWsMW5ekaLyYTDUOs7JEWw1YITI=; b=S1QYqEfmkDCoD9augSQP+vGy5djOfS1Ae9skFsqgydQqOUcye5tVh/wo3H aDZIpZeHh0xlR/o5PpK5+0oFiuYgfzGVDZgU5SwfrhdM8/cYbaM4H5tKSHGs 0vvZmCBxfP; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Sun, 27 Sep 2009 04:11:08 -0000 > Vince's proposal didn't say anything about encapsulating the Map- > Register and Map-Reply messages in the new "Encapsulated Control > Message" format. The Map-Register and Map-Reply are not > encapsulated in the -04 draft, they are just sent as normal UDP/IP > packets, and I don't think we agreed to change that. > > Did I miss something? The encoding is flexible. The spec indicates that Map-Requests which are sent to a map-resolver are encapsulated in the "Encapsulated Control Message". Map-Requests that are sent by an ITR that is attached to the ALT, does not encapsulate the Map-Request. Dino From dino@cisco.com Sat Sep 26 21:15: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 AA1043A690C for ; Sat, 26 Sep 2009 21:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFsiy0ce1-ZP for ; Sat, 26 Sep 2009 21:15:23 -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 1DCB53A659C for ; Sat, 26 Sep 2009 21:15:23 -0700 (PDT) X-Files: rfcdiff-lisp-04-to-05.html, draft-ietf-lisp-05.txt : 301054, 161470 X-IronPort-AV: E=Sophos;i="4.44,459,1249257600"; d="txt'?html'217?scan'217,208,217";a="247481161" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 27 Sep 2009 04:16:36 +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 n8R4GadN006587 for ; Sat, 26 Sep 2009 21:16:36 -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 n8R4Gac7006140 for ; Sun, 27 Sep 2009 04:16:36 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); Sat, 26 Sep 2009 21:16:35 -0700 Received: from [192.168.1.2] ([10.21.76.235]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Sep 2009 21:16:34 -0700 Message-Id: <3F58E153-7FCA-4445-9733-82CF0D59B4DA@cisco.com> From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-104-839887824 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 26 Sep 2009 21:16:34 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Sep 2009 04:16:34.0985 (UTC) FILETIME=[4CE64990:01CA3F29] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=472823; t=1254024996; x=1254888996; 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:=20Proposed=20change=20to=20draft-ietf-lisp-05.txt =20---=2009/26/09=20Sat=20Night |Sender:=20; bh=ONwFQ4x4taBW4VJZknwL4CPXQe9L29A6yjMiTTaHYRM=; b=Xj6gIW7JVKTgE4fVp5v05n0Np1xa/OSOMoylMyesiSeUrdtuSmO7OnTD/e 8hTJ1yF31gFKNE859ugN0TFO2mKzWtPKKgsbJIWDfqCQ+vZIjfI0TDPTTaQn Ck0p+XDpEs; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [lisp] Proposed change to draft-ietf-lisp-05.txt --- 09/26/09 Sat Night X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 27 Sep 2009 04:15:23 -0000 --Apple-Mail-104-839887824 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I added some clarifications based on comments. The current change set includes: B.1. Changes to draft-ietf-lisp-05.txt o Posted October 2009. o Added this Document Change Log appendix. o Added section indicating that encapsulated Map-Requests must use destination UDP port 4342. o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- data in Map-Register payload. o Added Jari to acknowledgment section. o State the source-EID is set to 0 when using Map-Requests to refresh or RLOC-probe. o Make more clear what source-RLOC should be for a Map-Request. o The LISP-CONS authors thought that the Type definitions for CONS should be removed from this specification. o Removed nonce from Map-Register message, it wasn't used so no need for it. o Clarify what to do for unspecified Action bits for negative Map- Replies. Since No Action is a drop, make value 0 Drop. The last 2 bullets were added. Dino --Apple-Mail-104-839887824 Content-Disposition: attachment; filename=rfcdiff-lisp-04-to-05.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-04-to-05.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-04.txt draft-ietf-lisp-05.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: March 20, 30, 2010                                         D. Lewis
                                                           cisco Systems
                                                      September 16, 26, 2009

                 Locator/ID Separation Protocol (LISP)
                         draft-ietf-lisp-04.txt
           (PROPOSED) draft-ietf-lisp-05.txt (NOT POSTED YET)

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 March 20, 30, 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 . . . . . . . . . 22
       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 30
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 32 33
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 33 34
       6.1.7.  Encapsualted Control Message Format  . . . . . . . . . 35
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 36 37
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 37 38
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 39 41
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41 42
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 41 43
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 42 43
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 43 44
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 44 45
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 46 47
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 47 48
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 48 49
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 48 49
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 49 50
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 50 51
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 51 52
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 51 52
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 51 52
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 53 54
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 53 54
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 54
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 54
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 55 56
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 55 56
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 57 58
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 58 59
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 59 60
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 63
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 62 63
     14.2. Informative References . . . . . . . . . . . . . . . . . . 63 64
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 66 67
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 68
     B.1.  Changes to draft-ietf-lisp-05.txt  . . . . . . . . . . . . 68
     B.2.  Changes to draft-ietf-lisp-04.txt  . . . . . . . . . . . . 68
     B.3.  Changes to draft-ietf-lisp-03.txt  . . . . . . . . . . . . 70
     B.4.  Changes to draft-ietf-lisp-02.txt  . . . . . . . . . . . . 70
     B.5.  Changes to draft-ietf-lisp-01.txt  . . . . . . . . . . . . 71
     B.6.  Changes to draft-ietf-lisp-00.txt  . . . . . . . . . . . . 71
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 72

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 statically 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 prepends 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
      statically 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 prepends 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   |N|L|E|  rflags |                 Nonce                         |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       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   |N|L|E|  rflags |                 Nonce                         |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       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

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

   Outer 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 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 SHOULD be transmitted as zero by an ITR for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
      packet with a zero UDP checksum is received by an ETR, the ETR
      MUST accept the packet for decapsulation.  When an ITR transmits a
      non-zero value for the UDP checksum, it MUST send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.  The handling of UDP checksums for all tunneling
      protocols, including LISP, is under active discussion within the
      IETF.  When that discussion concludes, any necessary changes will
      be made to align LISP with the outcome of the broader discussion.

   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.

   N: this is the nonce-present bit.  When this bit is set to 1, the
      low-order 24-bits of the first 32-bits of the LISP header contains
      a Nonce.  See section Section 6.3.1 for details.

   L: this is the Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are in use.

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1.  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.

   rflags:  this 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
      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.  When the E-bit is clear but the N-bit
      is set, an ITR is either echoing a previously requested echo-nonce
      or providing a random nonce.  See section Section 6.3.1 for more
      details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator Status Bits are numbered from 0 to n-1 from the least
      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 outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

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

   When doing Re-encapsulated Tunneling:

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

   o  The new outer 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 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
       LISP Encapsulated Control 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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.  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 Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  An 8-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.  The
      security of the LISP mapping protocol depends critically on the
      strength of the nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   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.  When
      Map-Requests are used for refreshing a map-cache entry or for
      RLOC-probing, the value 0 is used.

   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 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.  The
   source address is either an IPv4 or IPv6 RLOC address depending if
   the Map-Request is using an IPv4 versus IPv6 header, respectively.
   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
   4342 with a LISP type value set to "Encapsulated Control Message",
   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.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request, it may
   originate a "verifying Map-Request", addressed to the original ITR.
   If the ETR has a map-cache entry that matches the "piggybacked" EID
   and the RLOC is in the locator-set for the entry, then it may send
   the "verifying Map-Request" to the original Map-Request source.  If
   not, then it MUST send it to the "piggybacked" EID.  Doing this
   forces the "verifying Map-Request" to go through the mapping database
   system to reach the authoritative source of information about that
   EID, guarding against RLOC-spoofing in in the "piggybacked" 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|E|            Reserved               | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      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.  See
      section Section 6.3.2 for more details.

   E: Indicates that the ETR which sends this Map-Reply message is
      advertising that the site 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 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request is echoed in this Nonce field of 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.

   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.  Unassigned values should
      cause a map-cache entry to be created and, when packets match this
      negative cache entry, they will be dropped.  The current assigned
      values are:

      (0) No action:  No action Drop:  The packet is being conveyed by the sender of the
         Map-Reply message. dropped silently.

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

      (2) Drop:  The packet is dropped silently.

      (3) Send-Map-Request: 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.

   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 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 of 4342 and a
   randomly selected UDP source 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 [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 [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 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            Key ID             |                         . . . Nonce  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      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:  This 8-byte Nonce field is set

   Key ID:  A configured ID to 0 in Map-Register messages. find the configured Message
      Authentication Code (MAC) algorithm and key value used for the
      authentication function.

   Authentication Data Length:  The definition length in bytes of the rest
      Authentication Data field that follows this field.  The length 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 Authentication Data field is achieved by
   manipulating dependent on 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. Message
      Authentication Code (MAC) algorithm used.  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 length field allows
      a subset of the list has
      the same best priority.  Client can only use device that doesn't know the subset list
      according MAC algorithm to correctly parse
      the weighting assigned by the server-side.  In this
      case, packet.

   Authentication Data:  The message digest used from the server-side controls both output of the subset list and load-
      splitting across its members.
      Message Authentication Code (MAC) algorithm.  The client-side can use RLOCs
      outside of entire Map-
      Register payload is authenticated with this field preset to 0.
      After the subset list if MAC is computed, it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255).  Some
      sharing placed in this field.
      Implementations of control exists: the server-side determines the
      destination RLOC list this specification MUST include support for
      HMAC-SHA-1-96 [RFC2404] and load distribution while the client-side
      has the option support for HMAC-SHA-128-256 [RFC4634]
      is recommended.

   The definition of using alternatives to this list if RLOCs in the
      list are unreachable.

   o  Server-side sets weight rest of 0 for the RLOC subset list.  In this
      case, the client-side Map-Register can choose how the traffic load is spread
      across be found in the subset list.
   Map-Reply section.

6.1.7.  Encapsualted Control Message Format

   An Encapsulated Control Message is shared by the server-side
      determining used as the list service interface
   between ITRs, ETRs, 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 mapping database system described in
   [LISP-MS].

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   OH  |                      (uses RLOC
      reachability and preferability.  Server-side ETR gleaning of the
      client-side ITR addresses)                    |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4342        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LH  |Type=8 |                   Reserved                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   IH  |                  (uses RLOC is done by caching the inner header source or EID and the addresses)                 |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = yyyy        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LCM |                      LISP Control Message                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet header descriptions:

   OH:   The outer IPv4 or IPv6 header source which uses RLOC of received packets.  The
      client-side ITR controls how traffic is returned addresses in the
      source and can alternate
      using an destination header address fields.

   UDP:   The outer UDP header with destination port 4342.  The source RLOC, which then can
      port is randomly allocated.  The checksum field MUST be added to the
      list the server-side ETR uses non-zero.

   LH:   Type 8 is defined to return traffic.  Since no
      Priority be a "LISP Encapsulated Control Message"
      and what follows is either an IPv4 or Weights are provided using this method, IPv6 header as encoded by
      the server-
      side ETR must assume each client-side ITR first 4 bits after the reserved field.

   IH:   The inner IPv4 or IPv6 header which can use either RLOC uses or EID
      addresses in the same best
      Priority with header address fields.  When a Weight of zero.  In addition, since EID-prefix
      encoding cannot be conveyed Map-Request is
      encapsulated in data packets, this packet format the EID-to-RLOC cache destination address in this
      header is an EID.

   UDP:   The inner UDP header where the port assignments depends on tunnel routers can grow to be very large.

   o  A "gleaned" map-cache entry, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification
      control packet being encapsulated.  When the control packet is performed by
      sending a
      Map-Request to or Map-Register, the source EID (the inner header IP
      source address) of port is randomly assigned
      and the received encapsulated packet.  A reply to
      this "verifying Map-Request" destination port is used to fully populate 4342.  When the map-
      cache entry for control packet is a
      Map-Reply, the "gleaned" EID and source port is stored 4342 and used for the
      time indicated destination port is
      assigned from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix port of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply or that stored in the
   mapping database system provide reachability information for RLOCs.
   Such reachability needs invoking Map-Request.  Port
      number 4341 MUST NOT be assigned to either port.  The checksum
      field MUST be determined separately, using non-zero.

   LCM:   The format is one or
   more of the Routing Locator Reachability Algorithms control message formats described in the
   next
      this section.

6.3.

6.2.  Routing Locator Reachability

   Several mechanisms for determining RLOC reachability are currently
   defined:

   1.  An ETR Selection

   Both client-side and server-side may examine the Loc-Status-Bits in need control over the LISP header selection
   of an
       encapsulated data packet received from an ITR.  If the ETR RLOCs for conversations between them.  This control is
       also acting as an ITR and has traffic to return to achieved by
   manipulating the original
       ITR site, it can use this status Priority and Weight fields in EID-to-RLOC Map-Reply
   messages.  Alternatively, RLOC information to help select an
       RLOC.

   2.  An ITR may receive an ICMP Network be gleaned from
   received tunneled packets or ICMP Host Unreachable
       message EID-to-RLOC Map-Request messages.

   The following enumerates different scenarios for an RLOC it is using.  This indicates 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 is
       likely down.

   3.  An ITR which participates in where a subset of the global routing system list has
      the same best priority.  Client can
       determine that an RLOC is down if no BGP RIB route exists that
       matches only use the RLOC IP address.

   4.  An ITR may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR attempts subset list
      according to use
       interworking [INTERWORK] the weighting assigned by the server-side.  In this
      case, the server-side controls both the subset list and LISP-encapsulated data load-
      splitting across its members.  The client-side can use RLOCs
      outside of the subset list if it determines that the subset list
      is sent to a
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in response unreachable (unless RLOCs are set to a
       previously sent Map-Request.  The RLOC source Priority of 255).  Some
      sharing of control exists: the Map-Reply is
       likely up since server-side determines the ETR was able to send
      destination RLOC list and load distribution while the Map-Reply client-side
      has the option of using alternatives to this list if RLOCs in the
       ITR.

   6.  When an ETR receives an encapsulated packet from an ITR,
      list are unreachable.

   o  Server-side sets weight of 0 for the
       source RLOC from subset list.  In this
      case, the outer header of client-side can choose how the packet traffic load is likely up.

   7.  An ITR/ETR pair can use spread
      across the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability subset list.  Control is shared by examining the Loc-
   Status-Bits from server-side
      determining the LISP encapsulated data packet, an ETR will
   receive up to date status from an encapsulating ITR about
   reachability for all ETRs at list and the site.  CE-based ITRs at client determining load distribution.
      Again, the source
   site client can determine reachability relative to each other using use alternative RLOCs if the site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route into the site IGP. server-provided
      list of RLOCs are unreachable.

   o  If an ITR fails or if  Either side (more likely on the upstream link server-side ETR) decides not to its PE fails, its
      default route will either time-out or be withdrawn.

   Each ITR can thus observe the presence or lack of
      send a default route
   originated by the others to determine Map-Request.  For example, if the Locator Status Bits server-side ETR does not
      send Map-Requests, it sets
   for them. gleans RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1.  The
   Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit.  For example, if an RLOC
   listed in client-side ITR,
      giving the 3rd position client-side ITR responsibility for bidirectional RLOC
      reachability and preferability.  Server-side ETR gleaning of the Map-Reply goes down (ordinal value
   2), then all ITRs at
      client-side ITR RLOC is done by caching the site will clear inner header source
      EID and the 3rd least significant
   bit (xxxx x0xx) 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 Loc-Status-Bits field for
      list the packets they
   encapsulate.

   When an server-side ETR decapsulates a packet, it will check for any change in
   the Loc-Status-Bits field.  When a bit goes from 1 uses to 0, return traffic.  Since no
      Priority or Weights are provided using this method, the server-
      side ETR will
   refrain from encapsulating packets to an RLOC that is indicated as
   down.  It will only resume using that must assume each client-side ITR RLOC if uses the corresponding Loc-
   Status-Bit returns to a value of 1.  Loc-Status-Bits are associated same best
      Priority with a locator-set per EID-prefix.  Therefore, when a locator becomes
   unreachable, the Loc-Status-Bit that corresponds to that locator's
   position in the list returned by the last Map-Reply will Weight of zero.  In addition, since EID-prefix
      encoding cannot be set to
   zero for that particular EID-prefix.

   When ITRs at the site are not deployed conveyed in CE routers, data packets, the IGP EID-to-RLOC cache
      on tunnel routers can
   still be used grow to determine be very large.

   o  A "gleaned" map-cache entry, one learned from the reachability source RLOC of Locators provided they
   are injected into the IGP.  This is typically done when a /32 address
      received encapsulated packet, is configured on only stored and used for a loopback interface.

   When ITRs receive ICMP Network or Host Unreachable messages as few
      seconds, pending verification.  Verification is performed by
      sending a
   method Map-Request to determine unreachability, they will refrain from using
   Locators which are described in Locator lists the source EID (the inner header IP
      source address) of Map-Replies.
   However, using the received encapsulated packet.  A reply to
      this approach "verifying Map-Request" 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 used to fully populate the map-
      cache entry for the
   host that originated "gleaned" EID and is stored and used for the data packet
      time indicated from the ITR encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if
   a locator address from TTL field of a locator-set in received Map-Reply.  When a mapping
      verified map-cache 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-Status-Bits indicate the locator is up.  In this case, the path
   from the ITR to the ETR stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that is assigned matches 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
      EID-prefix of the Locator has been determined.
   Obviously, sending such probes increases the number of control verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply 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 R-bit for
   active traffic; this the locator record is set to 1.  Neither
   the same as if it were listed information contained in a Map-Reply
   with priority 255.

   The ITR can test or that stored in the
   mapping database system provide reachability information for RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the unreachable Routing Locator by
   sending periodic Requests.  Both Requests and Replies MUST be rate-
   limited. Reachability Algorithms described in the
   next section.

6.3.  Routing Locator reachability testing is never done with data
   packets since that increases the risk of packet loss Reachability

   Several mechanisms for end-to-end
   sessions.

   When an determining RLOC reachability are currently
   defined:

   1.  An ETR decapsulates a packet, it knows that it is reachable from may examine the encapsulating ITR because that is how Loc-Status-Bits in the LISP header of an
       encapsulated data packet arrived.  In
   most cases, received from an ITR.  If the ETR can is
       also reach the acting as an ITR but cannot assume this and has traffic to
   be true due return to the possibility of path asymmetry.  In the presence of
   unidirectional traffic flow from an original
       ITR site, it can use this status information to help select an ETR, the
       RLOC.

   2.  An ITR should not
   use the lack of return traffic as may receive an indication ICMP Network or ICMP Host Unreachable
       message for an RLOC it is using.  This indicates that the ETR is
   unreachable.  Instead, it must use an alternate mechanisms to
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When there RLOC is bidirectional data flow between a pair of locators, a
   simple mechanism called "nonce echoing"
       likely down.

   3.  An ITR which participates in the global routing system can be used to
       determine
   reachability between that an RLOC is down if no BGP RIB route exists that
       matches the RLOC IP address.

   4.  An ITR and ETR.  When may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR wants attempts to solicit a
   nonce echo, it sets the N and E bits use
       interworking [INTERWORK] and places a 24-bit nonce in the
   LISP header of the next encapsulated LISP-encapsulated data packet.

   When this packet is received by the ETR, sent to a
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in response to a
       previously sent Map-Request.  The RLOC source of the encapsulated packet Map-Reply is
   forwarded as normal.  When
       likely up since the ETR next sends a data packet was able to send the
   ITR, it includes the nonce received earlier with the N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the path Map-Reply to
   and from the
       ITR.

   6.  When an ETR is up.

   The ITR will set the E-bit and N-bit for every receives an encapsulated packet it sends while
   in echo-nonce-request state.  The time from an ITR, the ITR waits to process
       source RLOC from the
   echoed nonce before it determines outer header of the path is unreachable packet is variable
   and a choice left for likely up.

   7.  An ITR/ETR pair can use the implementation.

   If Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability by examining the ITR is receiving packets Loc-
   Status-Bits from the LISP encapsulated data packet, an ETR but does not see will
   receive up to date status from an encapsulating ITR about
   reachability for all ETRs at the
   nonce echoed while being in echo-nonce-request state, then site.  CE-based ITRs at the path source
   site can determine reachability relative to the ETR is unreachable.  This decision may be overridden by each other
   locator reachability algorithms.  Once using the site
   IGP as follows:

   o  Under normal circumstances, each ITR determines will advertise a default
      route into the path to site IGP.

   o  If an ITR fails or if the ETR is down it can switch upstream link to another locator for that EID-prefix.

   Note that "ITR" and "ETR" are relative terms here.  Both devices must its PE fails, its
      default route will either time-out or be implementing both ITR and ETR functionality for the echo nonce
   mechanism to operate.

   The withdrawn.

   Each ITR and ETR may both go into echo-nonce-request state at can thus observe the same
   time.  The number of packets sent presence or lack of a default route
   originated by the time during which echo nonce
   requests others to determine the Locator Status Bits it sets
   for them.

   RLOCs listed in a Map-Reply are sent is an implementation specific setting.  However,
   when an ITR is numbered with ordinals 0 to n-1.  The
   Loc-Status-Bits in echo-nonce-request state, it can echo a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the ETR's
   nonce least significant bit.  For example, if an RLOC
   listed in the next set 3rd position of packets that it encapsulates and the Map-Reply goes down (ordinal value
   2), then
   subsequently, continue sending echo-nonce-request packets.

   This mechanism does not completely solve all ITRs at the forward path
   reachability problem as traffic may be unidirectional.  That is, site will clear the 3rd least significant
   bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR receiving traffic at decapsulates a site may not may not be packet, it will check for any change in
   the same device as
   an ITR which transmits traffic Loc-Status-Bits field.  When a bit goes from that site or 1 to 0, the site ETR will
   refrain from encapsulating packets to site
   traffic is unidirectional so there an RLOC that is no ITR returning traffic.

   The echo-nonce algorithm is bilateral.  That is, indicated as
   down.  It will only resume using that RLOC if one side sets the
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing corresponding Loc-
   Status-Bit returns to a value of the nonce does not occur and the requesting side may
   regard the 1.  Loc-Status-Bits are associated
   with a locator-set per EID-prefix.  Therefore, when a locator unreachable erroneously.  An ITR should only set becomes
   unreachable, the E-bit Loc-Status-Bit that corresponds to that locator's
   position in a encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed list returned by the E-bit in the Map-
   Reply message.

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

6.3.2.  RLOC Probing Algorithm

   RLOC Probing is a method that an ITR or PTR particular EID-prefix.

   When ITRs at the site are not deployed in CE routers, the IGP can use
   still be used 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 Locators provided they
   are used for RLOC Probing.

   RLOC probing injected into the IGP.  This is typically done in the control-plane when a /32 address
   is configured on a timer basis where an
   ITR loopback interface.

   When ITRs receive ICMP Network or PTR will originate Host Unreachable messages as a Map-Request destined
   method to a locator address determine unreachability, they will refrain 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 using
   Locators which are described in the Map-Request Locator lists of Map-Replies.
   However, using this approach is the EID-prefix unreliable because many network
   operators turn off generation of the map-cache entry
   cached by the ITR or PTR.  The ICMP Unreachable messages.

   If an ITR does receive an ICMP Network or PTR may include a mapping data
   record for Host Unreachable message,
   it MAY originate its own database mapping information.

   When an ETR receives a Map-Request ICMP Unreachable 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 destined for the EID-prefix contained in the Map-Request.  This provides
   host that originated the opportunity for data packet the ITR or PTR, which sent encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the RLOC-probe BGP RIB to get
   mapping updates see if there were changes to the ETR's database
   a locator address from a locator-set in a mapping
   entries.

   There are advantages entry matches a
   prefix.  If it does not find one and disadvantages of RLOC Probing.  The greatest
   benefit of RLOC Probing BGP is that running in the Default
   Free Zone (DFZ), it can handle many failure scenarios
   allowing the ITR decide to determine when not use the locator even though the
   Loc-Status-Bits indicate the path to a specific locator is
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator up.  In this case, the path
   from the cached
   locator.  RLOC Probing ITR to the ETR that is assigned the locator is not
   available.  More details are in [LOC-ID-ARCH].

   Optionally, an ITR can also provide RTT estimates between send 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 Map-Request to a Locator and if a Map-
   Reply is in returned, reachability of the Locator has been determined.
   Obviously, sending such probes increases the number of control
   messages required and the
   amount of bandwidth used to obtain those benefits, especially if the
   requirement originated by tunnel routers for failure detection times active flows, so Locators
   are very small.

   Continued research and testing will attempt assumed to characterize be reachable when they are advertised.

   This assumption does create a dependency: Locator unreachability is
   detected by the
   tradeoffs receipt of failure detection times versus message overhead.

6.4.  Routing Locator Hashing ICMP Host Unreachable messages.  When an ETR provides an EID-to-RLOC mapping in a Map-Reply message
   Locator has been determined to
   a requesting ITR, the locator-set be unreachable, it is not used for
   active traffic; this is the EID-prefix may contain
   different priority values for each locator address.  When more than
   one best same as if it were listed in a Map-Reply
   with priority locator exists, the 255.

   The ITR can decide how to load
   share traffic against test the corresponding locators.

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

   1.  Either a source
   sending periodic Requests.  Both Requests and destination address hash can Replies MUST 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 rate-
   limited.  Locator reachability testing is never done with data
   packets since that increases the IP protocol number field or IPv6 next-
       protocol fields risk of a packet a host originates from within a LISP
       site. loss for end-to-end
   sessions.

   When an ETR decapsulates a packet is not a TCP, UDP, or SCTP packet, the
       source and destination addresses only it knows that it is reachable from
   the header are used to
       compute the hash.

   2.  Take the hash value and divide it by encapsulating ITR because that is how the number of locators
       stored in packet arrived.  In
   most cases, the locator-set for ETR can also reach the EID-to-RLOC mapping.

   3.  The remainder will ITR but cannot assume this to
   be yield a value of 0 true due to "number the possibility of locators
       minus 1".  Use path asymmetry.  In the remainder presence of
   unidirectional traffic flow from an ITR to select an ETR, the locator in ITR should not
   use the
       locator-set.

   Note lack of return traffic as an indication that when a packet is LISP encapsulated, the source port number
   in the outer UDP header needs ETR is
   unreachable.  Instead, it must use an alternate mechanisms to be set.  Selecting
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When there is bidirectional data flow between a random value
   allows core routers which are attached to Link Aggregation Groups
   (LAGs) to load-split the encapsulated packets across member links pair of
   such LAGs.  Otherwise, core routers would see locators, a single flow, since
   packets have
   simple mechanism called "nonce echoing" can be used to determine
   reachability between an ITR and ETR.  When an ITR wants to solicit a source address
   nonce echo, it sets the N and E bits and places a 24-bit nonce in the
   LISP header of the ITR, for packets which are
   originated next encapsulated data packet.

   When this packet is received by different EIDs at the source site.  A suggested setting
   for ETR, the source port number computed by an ITR encapsulated packet is a 5-tuple hash
   function on the inner header,
   forwarded as described above.

   Many core router implementations use normal.  When the ETR next sends a 5-tuple hash to decide how to
   balance data packet load across members of a LAG.  The 5-tuple hash to the
   ITR, it includes the source and destination addresses of nonce received earlier with the packet N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the
   source path to
   and destination ports when from the protocol number in ETR is up.

   The ITR will set the E-bit and N-bit for every packet it sends while
   in echo-nonce-request state.  The time the ITR waits to process the
   echoed nonce before it determines the path is TCP or UDP.  For this reason, UDP encoding unreachable is used variable
   and a choice left 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, implementation.

   If the only way an ITR can get a more up-to-
   date mapping is to re-request the mapping.  However, receiving packets from the ITRs do ETR but does not
   know when see the mappings change and
   nonce echoed while being in echo-nonce-request state, then the ETRs do not keep track of who
   requested its mappings.  For scalability reasons, we want to maintain
   this approach but need path
   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 unreachable.  This decision may be overridden by other
   locator reachability algorithms.  Once the ITR determines the path to
   the end of a locator-set, it ETR is
   easy down it can switch to update mappings.  We assume new mappings will maintain the
   same another locator ordering as 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 old mapping but just have new locators
   appended echo nonce
   mechanism to operate.

   The ITR and ETR may both go into echo-nonce-request state at the end same
   time.  The number of packets sent or 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 during which echo nonce
   requests are sent is an ITR has only implementation specific setting.  However,
   when an old mapping but detects bits set ITR is in the loc-status-bits that correspond to locators beyond the list it
   has cached, echo-nonce-request state, it simply ignores them.

   When a locator record is removed from a locator-set, ITRs that have can echo the mapping cached will not use ETR's
   nonce in the removed locator because the xTRs
   will next set the loc-status-bit to 0.  So even if the locator is in the
   list, of packets that it will 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 used.  For new mapping requests, unidirectional.  That is, the xTRs can
   set
   ETR receiving traffic at a site may not may not be the locator address to 0 as well same device as setting the corresponding
   loc-status-bit to 0.  This forces ITRs with old
   an ITR which transmits traffic from that site or new mappings to
   avoid using the removed locator.

   If many changes occur site to a mapping over a long period of time, site
   traffic is unidirectional so there is no ITR returning traffic.

   The echo-nonce algorithm is bilateral.  That is, if one
   will find empty record slots in the middle of side sets the locator-set
   E-bit and new
   records appended to the locator-set.  At some point, it would be
   useful to compact other side is not enabled for echo-noncing, then the locator-set so
   echoing of the loc-status-bit settings can
   be efficiently packed.

   We propose here two approaches for locator-set compaction, one
   operational nonce does not occur and the other a protocol mechanism.  The operational
   approach uses requesting side may
   regard the locator unreachable erroneously.  An ITR should only set
   the E-bit in a clock sweep method.  The protocol approach uses encapsulated data packet when it knows the
   concept of Solicit-Map-Requests.

6.5.1.  Clock Sweep

   The clock sweep approach uses planning ETR is
   enabled for echo-noncing.  This is conveyed by the E-bit in advance and the use of
   count-down TTLs to time out mappings Map-
   Reply message.

   Note that have already been cached.
   The default setting 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 EID-to-RLOC mapping TTL is 24 hours.  So
   there example of control-plane probing.

6.3.2.  RLOC Probing Algorithm

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

   RLOC probing is used:

   1.  24 hours before done in the control-plane on a mapping change 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 take effect, a network
       administrator configures Map-Server or on the ETRs at a site to start
   ALT like one would when soliciting mapping data.  The EID record
   encoded in the clock
       sweep window.

   2.  During Map-Request is the clock sweep window, ETRs continue to send 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
       messages with the current (unchanged) mapping records. P-bit set.  The TTL
       for these mappings source address of the
   Map-Reply 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 from the ETRs continue to send Map-Reply messages
       with destination address of the current (unchanged) mapping records with Map-Request and
   the TTL destination address of the Map-Reply is set to
       1 minute.

   4.  At from the end source
   address of the 1 hour window, the ETRs will send Map-Request.  The Map-Reply
       messages with the new (changed) should contain mapping records.  So any active
       caches can get
   data for the new mapping contents right away if not cached,
       or EID-prefix contained in 1 minute if they had the mapping cached.

6.5.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way Map-Request.  This provides
   the opportunity for xTRs, at the site
   where mappings change, to control ITR or PTR, which sent the rate they receive requests for
   Map-Reply messages.  SMRs are also used RLOC-probe to tell remote ITRs get
   mapping updates if there were changes 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 ETR's database mapping
   entries.  So an xTR will solicit Map-Requests from sites it is
   currently sending encapsulated data to,

   There are advantages and only from those sites. disadvantages of RLOC Probing.  The xTRs greatest
   benefit of RLOC Probing is that it can locally decide handle many failure scenarios
   allowing the algorithm for how often and ITR to determine when the path to how
   many sites it sends SMR messages.

   An SMR message is simply a bit set in a Map-Request message.  An ITR specific locator is
   reachable or PTR will send has become unreachable, thus providing a Map-Request when they receive an SMR message.
   Both the SMR sender and robust
   mechanism for switching to using another locator from the Map-Request responder must rate-limited
   these messages.

   The following procedure shows how a SMR exchange occurs when cached
   locator.  RLOC Probing can also provide RTT estimates between a site
   is doing locator-set compaction pair
   of locators which can be useful for an EID-to-RLOC mapping:

   1.  When the database mappings network management purposes as
   well as for selecting low delay paths.  The major disadvantage of
   RLOC Probing is in an ETR change, the ETRs at number of control messages required and the site
       begin
   amount of bandwidth used to send Map-Requests with obtain those benefits, especially if the SMR bit set
   requirement for each locator
       in each map-cache entry the ETR caches.

   2.  A remote xTR which receives failure detection times are very small.

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

6.4.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Request Map-Reply message to
   a requesting ITR, the source locator address of the SMR
       message.  A newly allocated random nonce is selected and the EID-
       prefix uses is locator-set for the EID-prefix may contain
   different priority values for each locator address.  When more than
   one copied from the SMR message.

   3.  The remote xTR retransmits best priority locator exists, the Map-Request slowly until it gets a
       Map-Reply while continuing ITR can decide how to use load
   share traffic against the cached mapping.

   4. corresponding locators.

   The ETRs at the site with the changed mapping will reply following hash algorithm may be used by an ITR to select a
   locator for a packet destined to an EID for the
       Map-Request with EID-to-RLOC mapping:

   1.  Either a Map-Reply message provided source and destination address hash can be used or the Map-Request
       nonce matches
       traditional 5-tuple hash which includes the nonce from source and
       destination addresses, source and destination TCP, UDP, or SCTP
       port numbers and the SMR.  The Map-Reply messages
       SHOULD be rate limited.  This IP protocol number field or IPv6 next-
       protocol fields of a packet a host originates from within a LISP
       site.  When a packet is important to avoid Map-Reply
       implosion.

   5.  The ETRs, at the site with not a TCP, UDP, or SCTP packet, the changed mapping, records
       source and destination addresses only from the fact
       that header are used to
       compute the site that sent hash.

   2.  Take the Map-Request has received hash value and divide it by the new
       mapping data number of locators
       stored in the mapping cache entry locator-set for the remote site so
       the loc-status-bits are reflective EID-to-RLOC mapping.

   3.  The remainder will be yield a value of 0 to "number of locators
       minus 1".  Use the new mapping for packets
       going remainder to select the remote site.  The ETR then stops sending SMR
       messages.

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

   To avoid map-cache entry corruption by a third-party,
       locator-set.

   Note that when 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 packet is more secure to reach an authoritative ETR,
   it will deliver the Map-Request to LISP encapsulated, the authoritative source of port number
   in the
   mapping data.

7.  Router Performance Considerations

   LISP is designed outer UDP header needs 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 set.  Selecting a random value
   allows core routers which are required,
   they should be limited to re-programming existing hardware rather
   than requiring expensive design changes attached to hard-coded algorithms in
   silicon.

   A few implementation techniques can be used Link Aggregation Groups
   (LAGs) to incrementally
   implement LISP:

   o  When a tunnel encapsulated packet is received by an ETR, the outer
      destination address may not be 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 router.  This
      makes it challenging ITR, for the control plane to get packets from the
      hardware.  This may be mitigated which are
   originated by creating special FIB entries
      for the EID-prefixes of different EIDs served by at the ETR (those source site.  A suggested setting
   for which the router provides source port number computed by an RLOC translation).  These FIB entries are
      marked with ITR is a flag indicating that control plane processing should
      be performed. 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 forwarding logic 5-tuple hash
   includes the source and destination addresses of testing for particular IP the packet and the
   source and destination ports when the protocol number value in the packet
   is not necessary.  No changes to existing,
      deployed hardware should be needed 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 support this.

   o  On retrieve and
   store EID-to-RLOC mappings, the only way an ITR, prepending ITR can get a new IP header is as simple as adding more
      bytes up-to-
   date mapping is to a MAC rewrite string re-request the mapping.  However, the ITRs do not
   know when the mappings change and prepending the string as part 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 outgoing encapsulation procedure.  Many routers sites that support
      GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already
      support this action.

   o are currently communicating with
   the ETR site using such mappings.

   When a received packet's outer destination address contains an EID
      which locator record is not intended added to be forwarded on the routable topology
      (i.e.  LISP 1.5), the source address end of a data packet or the
      router interface with which the source locator-set, it 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
   easy to find EID-to-RLOC update mappings.

8.  Deployment Scenarios

   This section will explore how and where ITRs and ETRs can be deployed
   and  We assume new mappings will discuss maintain the pros and cons of each deployment scenario.
   There are two basic deployment trade-offs
   same locator ordering as the old mapping but just have new locators
   appended 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 end of the tunnel routers spread out so 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 caches are spread
      across all loc-status-bits that correspond to locators beyond 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 list it
   has cached, it simply ignores them.

   When a locator record is removed from a locator-set, ITRs doesn't increase management load,
      since caches are built and stored dynamically.  On that have
   the other hand,
      more ETRs does require more management since EID-prefix-to-RLOC
      mappings need mapping cached will not use the removed locator because the xTRs
   will set the loc-status-bit to be explicitly configured.

   When deciding on flat, recursive, or re-encapsulation tunneling, 0.  So even if 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 locator 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
   list, it is prepending a will not be used.  For new tunnel header, but if the site's
      ISP is doing the TE, then mapping requests, the site has no control.  Recursive
      tunneling generally will result in suboptimal paths but at xTRs can
   set the
      benefit of steering traffic locator address to resource available parts of 0 as well as setting the
      network.

   o  The technique of re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs corresponding
   loc-status-bit to be rerouted,
      it is first decapsulated by the ETR and then re-encapsulated 0.  This forces ITRs with
      a old or new tunnel header mappings to
   avoid using the removed locator.

   If many changes occur to a new RLOC.

   The next sub-sections mapping over a long period of time, one
   will describe where tunnel routers can reside find empty record slots in the network.

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close middle of the locator-set and new
   records appended to hosts, the EID-prefix set is at locator-set.  At some point, it would be
   useful to compact the granularity of an IP subnet.  So at locator-set so the expense of more EID-
   prefix-to-RLOC sets loc-status-bit settings can
   be efficiently packed.

   We propose here two approaches for locator-set compaction, one
   operational and the site, the caches in each tunnel router
   can remain relatively small.  But caches always depend on other a protocol mechanism.  The operational
   approach uses a clock sweep method.  The protocol approach uses the number
   concept of non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the increase Solicit-Map-Requests.

6.5.1.  Clock Sweep

   The clock sweep approach uses planning in control
   traffic grows as well: since advance and the EID-granularity 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 greater, more
   Map-Requests and Map-Replies are traveling between more routers. 24 hours.  So
   there is a 24 hour window to time out old mappings.  The advantage of placing following
   clock sweep procedure is used:

   1.  24 hours before a mapping change is to take effect, a network
       administrator configures the caches and databases ETRs at these stub
   routers is that a site to start the products deployed in this part of clock
       sweep window.

   2.  During the network
   have better price-memory ratios then their core router counterparts.
   Memory is typically less expensive in clock sweep window, ETRs continue to send Map-Reply
       messages with the current (unchanged) mapping records.  The TTL
       for these devices and fewer routes
   are stored (only IGP routes).  These devices tend mappings is set to 1 hour.

   3.  24 hours later, all previous cache entries will have excess
   capacity, both for forwarding timed out,
       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 any active cache entries will time out within 1 hour.  During
       this 1 hour window 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 ETRs continue to send Map-Reply messages
       with the EID
   space associated current (unchanged) mapping records with a site to be reachable via a small the TTL set of RLOCs
   assigned to
       1 minute.

   4.  At the CE routers for that site.

   This offers the opposite benefit end of the first-hop/last-hop tunnel
   router scenario: 1 hour window, the number of ETRs will send Map-Reply
       messages with the new (changed) mapping entries and network management
   touch points are reduced, allowing better scaling.

   One disadvantage 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 that less of a selective way for xTRs, at the network's resources site
   where mappings change, to control the rate they receive requests for
   Map-Reply messages.  SMRs are also used to
   reach host endpoints thereby centralizing tell remote ITRs to update
   the point-of-failure domain
   and creating network choke points at mappings they have cached.

   Since the CE router.

   Note xTRs don't keep track of remote ITRs that more than one CE router at a site have cached their
   mappings, they can be configured with not tell exactly who needs the same IP address.  In this case an RLOC is new mapping
   entries.  So 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 xTR will solicit Map-Requests from sites it is advertised out
   currently sending encapsulated data to, and only 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 those sites.
   The xTRs can locally decide if the tunnel endpoints are algorithm for how often and to how
   many sites it sends SMR messages.

   An SMR message is simply a bit set in the destination site (in
   either CE routers or last-hop routers within a site) Map-Request message.  An ITR
   or at other PE
   edges. PTR will send a Map-Request when they receive an SMR message.
   Both the SMR sender and the Map-Request responder must rate-limited
   these messages.

   The advantage of this case following procedure shows how a SMR exchange occurs when a site
   is that two or more tunnel headers
   can be avoided.  By having doing locator-set compaction for an EID-to-RLOC mapping:

   1.  When the PE be database mappings in an ETR change, the first router on ETRs at the path site
       begin to
   encapsulate, it can choose a TE path first, and send Map-Requests with the ETR can
   decapsulate and re-encapsulate SMR bit set for a tunnel to each locator
       in each map-cache entry the destination end
   site.

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

   2.  A remote xTR which receives the RLOCs used.

   As mentioned in earlier sections SMR message will schedule sending
       a combination of these scenarios is
   possible at Map-Request message to the expense source locator address of extra packet header overhead, if both site the SMR
       message.  A newly allocated random nonce is selected 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 the EID-
       prefix uses is highly desirable for it
   to see the entire path.  Since packets are encapsulated one copied from ITR to
   ETR, the hop across SMR message.

   3.  The remote xTR retransmits the tunnel could be viewed as Map-Request slowly until it gets a single hop.
   However, LISP traceroute
       Map-Reply while continuing to use the cached mapping.

   4.  The ETRs at the site with the changed mapping will provide reply to the entire path so
       Map-Request with a Map-Reply message provided the user can
   see 3 distinct segments of Map-Request
       nonce matches the path nonce from a source LISP host the SMR.  The Map-Reply messages
       SHOULD be rate limited.  This is important to a
   destination LISP host:

      Segment 1 (in source LISP avoid Map-Reply
       implosion.

   5.  The ETRs, at the site based on EIDs):

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

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

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

      Segment 3 (in changed mapping, records the fact
       that the destination LISP site based on EIDs):

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

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

   For segment 2 loc-status-bits are reflective of the path, ICMP Time Exceeded messages are returned new mapping for packets
       going to the remote site.  The ETR then stops sending SMR
       messages.

   For security reasons an ITR because MUST NOT process unsolicited Map-Replies.
   The nonce MUST be carried from SMR packet, into the TTL decrement resultant Map-
   Request, and then into Map-Reply to 0 is done on the outer
   header, so the destination reduce spoofing attacks.

   To avoid map-cache entry corruption by a third-party, a sender of the ICMP messages are to the an
   SMR-based Map-Request must be verified.  If an ITR RLOC
   address, receives an SMR-
   based Map-Request and the source source RLOC address of is not in the encapsulated
   traceroute packet.  The ITR looks inside of locator-set for the ICMP payload
   stored map-cache entry, then the responding Map-Request MUST be sent
   with an EID destination to
   inspect the traceroute source so mapping database system.  Since the
   mapping database system is more secure to reach an authoritative ETR,
   it can return will deliver the ICMP message Map-Request to the address authoritative source of the traceroute client as well as retaining the core
   router IP address in the ICMP message.  This
   mapping data.

7.  Router Performance Considerations

   LISP is so the traceroute
   client designed to be very hardware-based forwarding friendly.  By
   doing tunnel header prepending [RFC1955] and stripping instead of re-
   writing addresses, existing hardware can display the core router address (the RLOC address) in support the
   traceroute output.  The ETR returns its RLOC address and responds forwarding model
   with little or no modification.  Where modifications are required,
   they should be limited to
   the TTL decrement re-programming existing hardware rather
   than requiring expensive design changes to 0 like the previous core routers did.

   For segment 3, the next-hop router downstream from the ETR will hard-coded algorithms in
   silicon.

   A few implementation techniques can be
   decrementing the TTL for the used to incrementally
   implement LISP:

   o  When a tunnel encapsulated packet that was encapsulated, sent into
   the core, decapsulated is received by the an ETR, and forwarded because it isn't the
   final destination.  If the TTL is decremented to 0, any router on the
   path to the outer
      destination address may not be the address of the traceroute, including router.  This
      makes it challenging for the next-hop
   router or destination, will send an ICMP Time Exceeded message control plane to get packets from the
   source EID of the traceroute client.  The ICMP message will
      hardware.  This may be
   encapsulated mitigated by creating special FIB entries
      for the local ITR and sent back to EID-prefixes of EIDs served by the ETR in the
   originated traceroute source site, where (those for which
      the packet will router provides an RLOC translation).  These FIB entries are
      marked with a flag indicating that control plane processing should
      be delivered
   to the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire traceroute data packet performed.  The forwarding logic of testing for particular IP
      protocol number value is included in ICMP Time Exceeded
   message payload.  Therefore, only the ITR needs not necessary.  No changes to pay special
   attention for forwarding ICMP messages back existing,
      deployed hardware should be needed 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 support this.

   o  On an ITR, prepending a new IP header and 8 is as simple as adding more
      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, MAC rewrite string and therefore prepending the identity string as part of
      the traceroute source is lost.

   The solution we propose to solve outgoing encapsulation procedure.  Many routers that support
      GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already
      support this problem action.

   o  When a received packet's outer destination address contains an EID
      which is not intended to cache traceroute
   IPv4 headers in the ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and be forwarded on the ETR.  The
   ITR will use a circular buffer for caching routable topology
      (i.e.  LISP 1.5), the IPv4 and UDP headers source address of traceroute packets.  It will select a 16-bit number as a key to
   find them later when data packet or the IPv4 Time Exceeded messages are received.
   When an ITR encapsulates an IPv4 traceroute packet, it will use the
   16-bit number as
      router interface with which 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 associated (the
      interface from which it was received) can be associated with a VRF
      (Virtual Routing/Forwarding), in the ICMP payload
   thereby allowing the ITR which a different (i.e. non-
      congruent) topology can be used to find the cached headers for the
   traceroute source.  The ITR puts the cached headers in the payload EID-to-RLOC mappings.

8.  Deployment Scenarios

   This section will explore how and sends the ICMP Time Exceeded message to the traceroute source
   retaining where ITRs and ETRs can be deployed
   and will discuss the source address pros and cons of the original ICMP Time Exceeded
   message (a core router each deployment scenario.
   There are two basic deployment trade-offs to consider: centralized
   versus distributed caches and flat, recursive, or the ETR of the site of the traceroute
   destination).

9.3.  Traceroute using Mixed Locators re-encapsulating
   tunneling.

   When either an IPv4 traceroute or IPv6 traceroute is originated and deciding on centralized versus distributed caching, the ITR encapsulates it in
   following issues should be considered:

   o  Are the other address family header, you
   cannot get tunnel routers spread out so that the caches are spread
      across all 3 segments of the traceroute.  Segment 2 memories of the
   traceroute can not each router?

   o  Should management "touch points" be conveyed to the traceroute source since it is
   expecting addresses from intermediate hops in the same address format 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 type of traceroute it originated.  Therefore, in this case,
   segment 2 will make 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 look like one hop.  All the ITR has to
   do to make this work 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 not copy the inner TTL implement VPNs or to
      perform Traffic Engineering.  When doing VPN-based tunneling, the outer,
   encapsulating header's TTL when
      site has some control since the site is prepending a traceroute packet new tunnel
      header.  In the case of TE-based tunneling, the site may have
      control if it is encapsulated
   using an RLOC from prepending a different address family.  This will cause new tunnel header, but if the site's
      ISP is doing the TE, then the site has no
   TTL decrement to 0 to occur control.  Recursive
      tunneling generally will result in core routers between suboptimal paths but at the ITR and ETR.

10.  Mobility Considerations

   There are several kinds
      benefit of mobility steering traffic to resource available parts of which only some might be the
      network.

   o  The technique of
   concern to LISP.  Essentially they are as follows.

10.1.  Site Mobility

   A site wishes to change its attachment points re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs to be rerouted,
      it is first decapsulated by the Internet, ETR and
   its LISP Tunnel Routers will have then re-encapsulated with
      a new RLOCs when it changes upstream
   providers.  Changes tunnel header using a new RLOC.

   The next sub-sections will describe where tunnel routers can reside
   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 network.

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close to move, but is not concerned about
   maintaining session continuity.  Renumbering hosts, the EID-prefix set is involved.  LISP can
   help with at
   the issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling granularity of an IP subnet.  So at the address space used by a site from expense of more EID-
   prefix-to-RLOC sets for the address spaces
   used by its ISPs.  [RFC4984]

10.3.  Fast Endpoint Mobility

   Fast endpoint mobility occurs when an endpoint moves site, the caches in each tunnel router
   can remain relatively
   rapidly, changing its IP layer network attachment point.  Maintenance small.  But caches always depend on the number
   of session continuity is a goal.  This is where non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the Mobile IPv4
   [RFC3344bis] increase in control
   traffic grows as well: since the EID-granularity is greater, more
   Map-Requests and Mobile IPv6 [RFC3775] [RFC4866] mechanisms Map-Replies are used,
   and primarily where interactions with LISP need to be explored. traveling between more routers.

   The problem advantage of placing the caches and databases at these stub
   routers 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 products deployed in this is added to the overhead part of mobile IP binding
   updates, some packets might be delayed or dropped.

   In IPv4 mobility, when an endpoint the network
   have better price-memory ratios then their core router counterparts.
   Memory is away from home, packets to it typically less expensive in these devices and fewer routes
   are encapsulated stored (only IGP routes).  These devices tend to have excess
   capacity, both for forwarding and forwarded via a home agent which resides routing state.

   LISP functionality can also be deployed in the
   home area the endpoint's address belongs to.  The home agent will
   encapsulate edge switches.  These
   devices generally have layer-2 ports facing hosts and forward packets either directly to the endpoint or to
   a foreign agent which resides where layer-3 ports
   facing the endpoint has moved to.
   Packets from 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 endpoint may be sent directly EID
   space associated with a site to the correspondent
   node, may be sent reachable via the foreign agent, or may be reverse-tunneled
   back a small set of RLOCs
   assigned to the home agent CE routers for delivery to that site.

   This offers the mobile node.  As opposite benefit of the
   mobile node's EID or available RLOC changes, LISP EID-to-RLOC
   mappings are required for communication between first-hop/last-hop tunnel
   router scenario: the mobile node number of mapping entries 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 management
   touch points are reduced, allowing better scaling.

   One disadvantage is that it has done so.
      The Mobile IPv4 control packets the mobile node sends pass through
      one less 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 resources are sent directly used to
   reach host endpoints thereby centralizing the correspondent node, it may
      be that no traffic has been sent from the new visited point-of-failure domain
   and creating network to choke points at the correspondent node's network, and CE router.

   Note that more than one CE router at a site can be configured with
   the new visited network's
      ITR will need to obtain same IP address.  In this case an EID-RLOC mapping for RLOC is an anycast address.
   This allows resilience between the correspondent
      node's site.

   In addition, CE routers.  That is, if the IPv4 endpoint a CE
   router fails, traffic is sending packets from automatically routed to the new
   visited network other routers
   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 same anycast address.  However, this comes with the mobile node
   and
   disadvantage where the correspondent node 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 direction. CE routers or last-hop routers within a site) or at other PE
   edges.  The mobile node uses
   its "care-of" address (EID).  In advantage of this case, the route-returnability
   check would not be needed but one case is that two or more LISP mapping lookup may tunnel headers
   can be
   required instead:

   o  As above, three mapping changes may avoided.  By having the PE be needed for the mobile node first router on the path to communicate with its home agent
   encapsulate, it can choose a TE path first, and to send packets to the
      correspondent node.

   o  In addition, another mapping will be needed in the correspondent
      node's ITR, in order ETR can
   decapsulate and re-encapsulate for the correspondent node to send packets a tunnel to the mobile node's "care-of" address (EID) at destination end
   site.

   An obvious disadvantage is that the new network
      location.

   When both endpoints are mobile end site has no control over
   where its packets flow or the number of potential mapping
   lookups increases accordingly. RLOCs used.

   As a mobile node moves there are not only mobility state changes mentioned in earlier sections a combination of these scenarios is
   possible at the mobile node, correspondent node, expense of extra packet header overhead, if both site
   and home agent, but also state
   changes provider want control, then recursive or re-encapsulating tunnels
   are used.

9.  Traceroute Considerations

   When a source host in the ITRs and ETRs for at least some EID-prefixes.

   The goal is a LISP site initiates a traceroute to support rapid adaptation, with little delay or packet
   loss a
   destination host in another LISP site, it is highly desirable for it
   to see the entire system.  Heuristics can be added to LISP path.  Since packets are encapsulated from ITR to
   reduce
   ETR, the number of mapping changes required and to reduce hop across 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 tunnel could be viewed as 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, single hop.
   However, LISP traceroute will provide the ETR could examine entire path so the EID-RLOC mapping and use that
   mapping for all outgoing traffic to that EID.  It user can do this after
   performing a route-returnability check, to ensure that
   see 3 distinct segments of the new
   network location does have path from a internal route source LISP host to that endpoint.
   However, this does not cover the case where an a
   destination LISP host:

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

          source-host ---> first-hop ... next-hop ---> ITR (the node assigned

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

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

      Segment 3 (in the mobile-node location has been compromised.

   Mobile IP packet exchange is designed for an environment 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 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 normal matter as they are moving to 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 environment where some information may have
   to be obtained after packets EID address (the address of
   site-facing interface).

   For segment 2 of the path, ICMP Time Exceeded messages are in flight.  Modifications returned
   to IP
   mobility should be considered in order the ITR because the TTL decrement to optimize 0 is done on the behavior outer
   header, so the destination of the overall system.  Anything which decreases ICMP messages are to the number of new EID- ITR RLOC mappings needed when a node moves, or maintains
   address, the validity source source RLOC address of
   an EID-RLOC mapping for a longer time, is useful.

10.4.  Fast Network Mobility

   In addition the encapsulated
   traceroute packet.  The ITR looks inside of the ICMP payload to endpoints, a network can be mobile, possibly changing
   xTRs.  A "network"
   inspect the traceroute source so it can be return the ICMP message to
   the address of the traceroute client as small well as a single retaining the core
   router and as large as
   a whole site. IP address in the ICMP message.  This is different from site mobility in that it is
   fast so the traceroute
   client can display the core router address (the RLOC address) in the
   traceroute output.  The ETR returns its RLOC address and possibly short-lived, but different responds to
   the TTL decrement to 0 like the previous core routers did.

   For segment 3, the next-hop router downstream from endpoint mobility
   in the ETR will be
   decrementing the TTL for the packet that a whole prefix is changing RLOCs.  However, was encapsulated, sent into
   the mechanisms
   are core, decapsulated by the same ETR, and there forwarded because it isn't the
   final destination.  If the TTL is no new overhead in LISP.  A map request for decremented to 0, any endpoint will return a binding for router on the entire mobile prefix.

   If mobile networks become a more common occurrence, it may be useful
   path to revisit the design destination of the mapping service and allow for dynamic
   updates traceroute, including the next-hop
   router or destination, will send an ICMP Time Exceeded message to the
   source EID of the database. traceroute client.  The issue of interactions between mobility ICMP message will be
   encapsulated by the local ITR and LISP needs sent back to the ETR in the
   originated traceroute source site, where the packet will be
   explored further.  Specific improvements delivered
   to the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire system will
   depend on traceroute data packet is included in ICMP Time Exceeded
   message payload.  Therefore, only the details of mapping mechanisms.  Mapping mechanisms
   should be evaluated on how well they support session continuity ITR needs to pay special
   attention for
   mobile nodes.

10.5.  LISP Mobile Node Mobility

   An mobile device can use the LISP infrastructure forwarding ICMP messages back 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 traceroute source.

9.2.  IPv4 Traceroute

   For IPv4 traceroute, we cannot follow the mapping system
   (in LISP Map-Servers and Map-Resolvers) and are provided on demand to above procedure since IPv4
   ICMP Time Exceeded messages only include the correspondents of invoking IP header and 8
   bytes that follow the LISP mobile node.

   Refer IP header.  Therefore, when a core router sends
   an IPv4 Time Exceeded message to an ITR, all the LISP Mobility Architecture specification [LISP-MN] for
   more details.

11.  Multicast Considerations

   A multicast group address, as defined ITR has in the original Internet
   architecture ICMP
   payload is an identifier of the encapsulated header it prepended followed by a grouping of topologically
   independent receiver host locations. UDP
   header.  The address encoding itself
   does not determine original invoking IP header, and therefore the location identity
   of the receiver(s). traceroute source is lost.

   The multicast
   routing protocol, and the network-based state solution we propose to solve this problem is to cache traceroute
   IPv4 headers in the protocol creates,
   determines where ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and the receivers are located.

   In ETR.  The
   ITR will use a circular buffer for caching the context IPv4 and UDP headers
   of LISP, traceroute packets.  It will select a multicast group address is both an EID and 16-bit number as a Routing Locator.  Therefore, no specific semantic or action needs key to be taken for a destination address, as it would appear in
   find them later when the IPv4 Time Exceeded messages are received.
   When an IP
   header.  Therefore, a group address that appears in ITR encapsulates 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, IPv4 traceroute packet, it will use the same group address
   16-bit number as the
   destination Routing Locator.

   Having said that, only the source EID and UDP source Routing Locator
   needs to be dealt with.  Therefore, an ITR merely needs to put its
   own IP address port in the source Routing Locator field when prepending
   the outer IP encapsulating 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
   When the multicast routing protocol
   in a receiver site.  That is, an EID to Routing Locator translation
   is done at control-time.

   Another approach ICMP Time Exceeded message is returned to have the ITR not encapsulate a multicast
   packet and allow ITR, the UDP
   header of the host built packet encapsulating header is present in the ICMP payload
   thereby allowing the ITR to flow into find the core even
   if cached headers for the source address is allocated out of the EID namespace.  If
   traceroute source.  The ITR puts the
   RPF-Vector TLV [RPFV] is used by PIM cached headers in the core, then core routers
   can RPF payload
   and sends the ICMP Time Exceeded message to the ITR (the Locator address which is injected into core
   routing) rather than traceroute source
   retaining the host source address (the EID address which
   is not injected into of the original ICMP Time Exceeded
   message (a core routing).

   To avoid any EID-based multicast state in router or the network core, ETR of the first
   approach site of the traceroute
   destination).

9.3.  Traceroute using Mixed Locators

   When either an IPv4 traceroute or IPv6 traceroute is chosen for LISP-Multicast.  Details for LISP-Multicast originated and Interworking with non-LISP sites is described
   the ITR encapsulates it in specification
   [MLISP].

12.  Security Considerations

   It is believed that most the other address family header, you
   cannot get all 3 segments of the security mechanisms will be part traceroute.  Segment 2 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
   traceroute can not be conveyed to the
   use of a 24-bit Nonce field traceroute source since it is
   expecting addresses from intermediate hops in the LISP encapsulation header and a
   64-bit Nonce field same address format
   for the type of traceroute it originated.  Therefore, in this case,
   segment 2 will make the LISP control message.  The nonce, coupled
   with tunnel look like one hop.  All the ITR accepting only solicited Map-Replies goes a long way
   toward providing decent authentication.

   LISP does has to
   do to make this work is to not rely on copy the inner TTL to the outer,
   encapsulating header's TTL when a PKI infrastructure or traceroute packet is encapsulated
   using an RLOC from a more heavy weight
   authentication system.  These systems challenge different address family.  This will cause no
   TTL decrement to 0 to occur in core routers between the scalability ITR and ETR.

10.  Mobility Considerations

   There are several kinds of mobility of
   LISP which was a primary design goal.

   DoS attack prevention will depend on implementations rate-limiting
   Map-Requests and Map-Replies only some might be of
   concern to the control plane as well LISP.  Essentially they are as rate-
   limiting follows.

10.1.  Site Mobility

   A site wishes to change its attachment points to the number of data-triggered Map-Replies.

   To deal with map-cache exhaustion attempts Internet, and
   its LISP Tunnel Routers will have new RLOCs when it changes upstream
   providers.  Changes in an ITR/PTR, the
   implementation should consider putting a maximum cap on the number of
   entries stored with a reserve list EID-RLOC mappings for special or frequently accessed
   sites.  This should sites are expected to be a configuration policy control set
   handled by configuration, outside of the
   network administrator who manages ITRs and PTRs.

13.  Prototype Plans and Status

   The operator community has requested that 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 IETF take issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling the address space used by a practical
   approach to solving site from the scaling problems associated with global
   routing state growth.  This document offers a simple solution which 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 intended for use in a pilot program goal.  This is where the Mobile IPv4
   [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used,
   and primarily where interactions with LISP need to gain experience in working
   on this problem. be explored.

   The authors hope problem is that publishing this specification will allow as an endpoint moves, it may require changes to
   the
   rapid implementation of multiple vendor prototypes mapping between its EID and deployment on
   a small scale.  Doing this will help the community:

   o  Decide whether a set of RLOCs for its new EID-to-RLOC mapping database infrastructure network
   location.  When this is needed added to the overhead of mobile IP binding
   updates, some packets might be delayed or if a simple, UDP-based, data-triggered approach dropped.

   In IPv4 mobility, when an endpoint is
      flexible away from home, packets to it
   are encapsulated and robust enough.

   o  Experiment with provider-independent assignment of EIDs while at forwarded via a home agent which resides in the same time decreasing
   home area the size of DFZ routing tables through endpoint's address belongs to.  The home agent will
   encapsulate and forward packets either directly to the use of topologically-aligned, provider-based RLOCs.

   o  Determine whether multiple levels of tunneling can be used by ISPs endpoint or to achieve their Traffic Engineering goals while simultaneously
      removing
   a foreign agent which resides where the more specific routes currently injected into endpoint has moved to.
   Packets from the
      global routing system for this purpose.

   o  Experiment with mobility endpoint may be sent directly to determine if both acceptable
      convergence and session continuity properties can the correspondent
   node, may be scalably
      implemented sent via the foreign agent, or may be reverse-tunneled
   back to support both individual device roaming and site
      service provider changes.

   Here is a rough set of milestones:

   1.  Interoperable implementations have been available since the
       beginning of 2009.  We are trying home agent for delivery to converge on a packet format
       so implementations can converge on the -04 and later drafts.

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

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

   4.  Implement the available RLOC changes, LISP Multicast draft [MLISP].

   5.  Implement EID-to-RLOC
   mappings are required for communication between the LISP Mobile Node draft [LISP-MN].

   6.  Research more on how policy affects what gets returned in mobile node and
   the home agent, whether via foreign agent or not.  As a Map-
       Reply mobile
   endpoint changes networks, up to three LISP mapping changes may be
   required:

   o  The mobile node moves from an ETR.

   7.  Continue to experiment with mixed locator-sets old location to understand how
       LISP can help the a new visited
      network location and notifies its home agent that it has done so.
      The Mobile IPv4 to IPv6 transition.

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

   As control packets the mobile node sends pass through
      one 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 new visited network's ITRs, which needs a EID-RLOC
      mapping for this draft the home agent.

   o  The home agent might not have the EID-RLOC mappings 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 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 completed for draft [ALT].

   3.   A unit- sent from the new visited network to
      the correspondent node's network, and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [INTERWORK].  Support 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 translation endpoint is provided and PTR support 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 IPv4 and
   that EID.

   In 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 mobility, packets can flow directly between the features described above
        on a dual-stack infrastructure.

   6.   Darrel Lewis and Dave Meyer have deployed both LISP translation mobile node
   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 correspondent node in a LISP site.

   7.   Soon http://www.lisp6.net will work where your IPv6 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 site
        can talk mapping lookup may be
   required instead:

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

   o  In addition, another mapping will be needed in a LISP site by using mixed
        address-family based locators.

   8.   An public domain implementation of LISP is underway.  See
        [OPENLISP] the correspondent
      node's ITR, in order for details.

   9.   We have deployed Map-Resolvers and Map-Servers on the LISP pilot
        network correspondent node to send packets to gather experience with [LISP-MS].  The first layer of
      the architecture mobile node's "care-of" address (EID) at the new network
      location.

   When both endpoints are mobile the xTRs which use Map-Servers for EID-
        prefix registration and Map-Resolvers for EID-to-RLOC number of potential mapping
        resolution.  The second layer
   lookups increases accordingly.

   As a mobile node moves there are not only mobility state changes in
   the Map-Resolvers mobile node, correspondent node, and Map-
        Servers which connect to the ALT BGP peering infrastructure.
        And home agent, but also state
   changes in the third layer are ALT-routers which aggregate EID-prefixes ITRs and forward Map-Requests.

   10.  A cisco IOS implementation ETRs for at least some EID-prefixes.

   The goal 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 support rapid adaptation, with little delay or packet
   loss for the entire system.  Heuristics can be added to LISP pilot network.  See
        [LIG] for details.

   12.  A Linux implementation to
   reduce the number of LIG has been made available mapping changes required and
        supported by Dave Meyer.  It to reduce the delay
   per mapping change.  Also IP mobility can be run on any Linux modified to require
   fewer mapping changes.  In order to increase overall system
        which resides
   performance, there may be a need to reduce the optimization of one
   area in either order to place fewer demands on another.

   In LISP, one possibility is to "glean" information.  When a LISP site or non-LISP site.  See [LIG] packet
   arrives, the ETR could examine the EID-RLOC mapping and use that
   mapping for details.  Public domain code all outgoing traffic to that EID.  It can be downloaded from
        http://github.com/davidmeyer/lig/tree/master.

   13.  An experimental implementation 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 written compromised.

   Mobile IP packet exchange is designed for three
        locator reachability algorithms.  Two are the Echo-Noncing and
        RLOC-Probing algorithms which are documented an environment in this
        specification.  The third is called TCP-counts which will all
   routing information is disseminated before packets can be
        documented in forwarded.
   In order to allow the Internet to grow to support expected future drafts.

   14.  The LISP pilot network has been converted from using MD5 HMAC
        authentication
   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 Map-Register messages a longer time, is useful.

10.4.  Fast Network Mobility

   In addition to SHA-1 HMAC
        authentication.  ETRs send with SHA-1 but Map-Servers endpoints, a network can
        received 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 either for compatibility purposes.

   If interested site mobility in writing that it is
   fast and possibly short-lived, but different from endpoint mobility
   in that a LISP implementation, testing whole prefix is changing RLOCs.  However, the mechanisms
   are the same and there is no new overhead in LISP.  A map request for
   any of endpoint will return a binding for the
   LISP implementations, or want to entire mobile prefix.

   If mobile networks become a more common occurrence, it may be part useful
   to revisit the design 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. mapping service and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1498]  Saltzer, J., "On allow for dynamic
   updates of the Naming and Binding database.

   The issue of Network
              Destinations", RFC 1498, August 1993.

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

   [RFC2119]  Bradner, S., "Key words 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 in RFCs the LISP infrastructure to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. achieve mobility
   by implementing the LISP encapsulation 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., decapsulation functions
   and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3056]  Carpenter, B. 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 K. Moore, "Connection do not impose a cost on the global routing
   system.  These EIDs are maintained at the edges of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., the mapping system
   (in LISP Map-Servers and D. Black, "The Addition Map-Resolvers) and are provided on demand to
   only the correspondents of Explicit Congestion Notification (ECN) the LISP mobile node.

   Refer to IP",
              RFC 3168, September 2001.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 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 24-bit Nonce field in the LISP encapsulation header and a
   64-bit Nonce field in the LISP control message.  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.  Interoperable implementations have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   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.  Two are the Echo-Noncing and
        RLOC-Probing algorithms which are documented in this
        specification.  The third is called TCP-counts 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.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, 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.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

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

   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 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.

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

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), February
              May 2009.

14.2.  Informative References

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

   [ALT]

   [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, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-01.txt
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt (work in progress), May
              March 2009.

   [APT]      Jen,

   [LISP-MN]  Farinacci, D., Meisel, M., Massey, Fuller, V., Lewis, D., Wang, L., Zhang, B., and
              L. Zhang, "APT: A Practical Transit Mapping Service",
              draft-jen-apt-01.txt D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
              in progress), November 2007.

   [CHIAPPA]  Chiappa, J., "Endpoints July 2009.

   [LISP-MS]  Farinacci, D. and Endpoint names: A Proposed
              Enhancement to the Internet Architecture", Internet-
              Draft http://www.chiappa.net/~jnc/tech/endpoints.txt,
              1999.

   [CONS] V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-02.txt (work in progress),
              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, "LISP-CONS: A
              Content distribution Overlay Network  Service D., Zwiebel, J., and S. Venaas,
              "LISP for LISP",
              draft-meyer-lisp-cons-03.txt 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),
              November 2007.

   [DHTs]     Ratnasamy, S., Shenker, S., and I. Stoica, July 2008.

   [RADIR]    Narten, T., "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 Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress),
              November July 2007.

   [GSE]      "GSE - An Alternate Addressing Architecture

   [RFC3344bis]
              Perkins, C., "IP Mobility Support for  IPv6",
              draft-ietf-ipngwg-gseaddr-00.txt IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work in progress), 1997.

   [INTERWORK]
              Lewis, D., Meyer, D., Farinacci, D.,
              July 2007.

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

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

   [LIG]      Farinacci, D.

   [RPMD]     Handley, M., Huici, F., and D. Meyer, "LISP Internet Groper (LIG)",
              draft-farinacci-lisp-lig-01.txt A. Greenhalgh, "RPMD: Protocol
              for Routing Protocol Meta-data  Dissemination",
              draft-handley-p2ppush-unpublished-2007726.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., July 2007.

   [SHIM6]    Nordmark, E. and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt M. Bagnulo, "Level 3 multihoming shim
              protocol", draft-ietf-shim6-proto-06.txt (work in
              progress),
              March 2009.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., October 2006.

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 D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
              in progress), July 2009.

   [LISP-MS]  Farinacci, D. identity, as well as detailed review of the LISP
   architecture and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-02.txt (work in progress),
              September 2009.

   [LISP1]    Farinacci, D., Oran, D., Fuller, V., documents, coupled with enthusiasm for making LISP a
   practical 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., incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and J. ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
              "Locator/ID Separation Protocol (LISP2) [DNS-based
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt,
              November 2006.

   [LISPDHT]  Mathy, L.,
   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, L., 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, and O. Bonaventure, "LISP-DHT:
              Towards a DHT Jari
   Arkko.

   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.

Appendix B.  Document Change Log

B.1.  Changes to map identifiers onto locators",
              draft-mathy-lisp-dht-00.txt (work draft-ietf-lisp-05.txt

   o  Posted October 2009.

   o  Added this Document Change Log appendix.

   o  Added section indicating that encapsulated Map-Requests must use
      destination UDP port 4342.

   o  Don't use AH in progress),
              February 2008.

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

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP Map-Register payload.

   o  Added Jari to acknowledgment section.

   o  State the source-EID is set to 0 when using Map-Requests to
      refresh or RLOC-probe.

   o  Make more clear what source-RLOC should be for Multicast Environments",
              draft-ietf-lisp-multicast-01.txt (work in progress),
              May 2009.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID a Map-Request.

   o  The LISP-CONS authors thought that the Type definitions for CONS
      should be removed from this specification.

   o  Removed nonce from Map-Register message, it wasn't used so no need
      for it.

   o  Clarify what to RLOC Database",
              draft-lear-lisp-nerd-04.txt (work in progress),
              April 2008.

   [OPENLISP]
              Iannone, L. do for unspecified Action bits for negative Map-
      Replies.  Since No Action is a drop, make value 0 Drop.

B.2.  Changes to draft-ietf-lisp-04.txt

   o  Posted September 2009.

   o  How do deal with record count greater than 1 for a Map-Request.
      Damien and O. Bonaventure, "OpenLISP Implementation
              Report", draft-iannone-openlisp-implementation-01.txt
              (work in progress), July 2008.

   [RADIR]    Narten, T., "Routing Joel comment.  Joel suggests: 1) Specify that senders
      compliant with the current document will always set the count to
      1, and Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress), July 2007.

   [RFC3344bis]
              Perkins, C., "IP Mobility Support note that the count is included for IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work 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?

   o  Add Fred Templin in progress),
              July 2007.

   [RFC4192]  Baker, F., Lear, E., ack section.

   o  Add Margaret and R. Droms, "Procedures Sam to the ack section for
              Renumbering their great comments.

   o  Say more about LAGs in the UDP section per Sam Hartman's comment.

   o  Sam wants to use MAY instead of SHOULD for ignoring checksums on
      ETR.  From the mailing list: "You'd need to word it as an IPv6 Network without ITR MAY
      send a Flag Day", RFC 4192,
              September 2005.

   [RPFV]     Wijnands, IJ., Boers, A., zero checksum, an ETR MUST accept a 0 checksum and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-08.txt (work 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."

   o  Margaret wants a reference to
      http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt.

   o  Fix description in progress),
              January 2009.

   [RPMD]     Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol Map-Request section.  Where we describe Map-
      Reply Record, change "R-bit" to "M-bit".

   o  Add the mobility bit to Map-Replies.  So PTRs don't probe so often
      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.

Appendix A.  Acknowledgments

   An initial thank you goes MNs but often enough to Dave Oran get mapping updates.

   o  Indicate SHA1 can be used as well for planting Map-Registers.

   o  More Fred comments on MTU handling.

   o  Isidor comment about specing better periodic Map-Registers.  Will
      be fixed in draft-ietf-lisp-ms-02.txt.

   o  Margaret's comment on gleaning: "The current specification does
      not make it clear how long gleaned map entries should be retained
      in the seeds 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
   initial ideas for LISP.  His consultation continues mapping system.  The security implications of storing
      "gleaned" entries should also be explored in detail."

   o  Add section on RLOC-probing per working group feedback.

   o  Change "loc-reach-bits" to provide value "loc-status-bits" per comment from
      Noel.

   o  Remove SMR-bit from data-plane.  Dino prefers to have it in the
      control plane only.

   o  Change LISP authors.

   A special and appreciative thank you goes header to Noel Chiappa for
   providing architectural impetus over allow a "Research Bit" so the past decades on separation
   of location Nonce and identity, as well as detailed review of the LISP
   architecture LSB
      fields can be turned off and documents, coupled with enthusiasm used for making LISP another future purpose.  For
      Luigi et al versioning convergence.

   o  Add a
   practical and incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas N-bit 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, data header suggested by Noel.  Then the nonce
      field could be used when N is not 1.

   o  Clarify that when E-bit is 0, the nonce field can be an echoed
      nonce or a random nonce.  Comment from Jesper.

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

   o  Indicate that a verifying Map-Request, for accepting mapping data,
      should be sent over the the ALT (or to the EID).

   o  Reference IPsec RFC 4302.  Comment from Sam Hartman, Michael Hofling, and Brian Weis.

   o  Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
      noncing.  Comment by Pedro Marques.

   In particular, we would like and Dino.

   o  Jesper made a comment to thank Dave Meyer for his clever
   suggestion for loosen the name "LISP". ;-)

   This language about requiring the
      copy of inner TTL to outer TTL since the text to get mixed-AF
      traceroute to work originated would violate the "MUST" clause.  Changed from
      MUST to SHOULD in section 5.3.

B.3.  Changes to draft-ietf-lisp-03.txt

   o  Posted July 2009.

   o  Removed loc-reach-bits longword from control packets per Damien
      comment.

   o  Clarifications in MTU text from Roque.

   o  Added text to indicate that the Routing Research Group (RRG) locator-set be sorted by locator
      address from Isidor.

   o  Clarification text from JohnZ in Echo-Nonce section.

B.4.  Changes to draft-ietf-lisp-02.txt

   o  Posted July 2009.

   o  Encapsulation packet format change to add E-bit and make loc-
      reach-bits 32-bits in length.

   o  Added Echo-Nonce Algorithm section.

   o  Clarification how ECN bits are copied.

   o  Moved S-bit in Map-Request.

   o  Added P-bit in Map-Request and Map-Reply messages to anticipate
      RLOC-Probe Algorithm.

   o  Added to Mobility section to reference draft-meyer-lisp-mn-00.txt.

B.5.  Changes to draft-ietf-lisp-01.txt

   o  Posted 2 days after draft-ietf-lisp-00.txt in May 2009.

   o  Defined LEID to be a "LISP EID".

   o  Indicate encapsulation use IPv4 DF=0.

   o  Added negative Map-Reply messages with drop, native-forward, and
      send-map-request actions.

   o  Added Proxy-Map-Reply bit to Map-Register.

B.6.  Changes to draft-ietf-lisp-00.txt

   o  Posted May 2009.

   o  Rename of the IRTF.
   The individual submission [LISP-MAIN] was converted into this IETF
   LISP working group draft. draft-farinacci-lisp-12.txt.

   o  Acknowledgment to RRG.

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-104-839887824 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-104-839887824 Content-Disposition: attachment; filename=draft-ietf-lisp-05.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-05.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: March 30, 2010 D. Lewis cisco Systems September 26, 2009 Locator/ID Separation Protocol (LISP) (PROPOSED) draft-ietf-lisp-05.txt (NOT POSTED YET) 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 March 30, 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. Farinacci, et al. Expires March 30, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 . . . . . . . . . 22 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 . . . . . . . . . . . . . . . 30 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 33 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 34 6.1.7. Encapsualted Control Message Format . . . . . . . . . 35 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 37 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 38 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 41 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 42 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 43 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 43 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 44 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 45 7. Router Performance Considerations . . . . . . . . . . . . . . 47 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 48 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 49 Farinacci, et al. Expires March 30, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 49 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 50 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 51 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 52 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 52 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 52 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 54 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 54 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 54 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 54 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 56 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 56 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 58 12. Security Considerations . . . . . . . . . . . . . . . . . . . 59 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 60 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 14.1. Normative References . . . . . . . . . . . . . . . . . . . 63 14.2. Informative References . . . . . . . . . . . . . . . . . . 64 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 67 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 68 B.1. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 68 B.2. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 68 B.3. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 70 B.4. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 70 B.5. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 71 B.6. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 72 Farinacci, et al. Expires March 30, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 30, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 30, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 30, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 30, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 statically 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 prepends 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 statically configured. Farinacci, et al. Expires March 30, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 prepends 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 Farinacci, et al. Expires March 30, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 30, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | | Farinacci, et al. Expires March 30, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer 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 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 SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion. 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 Farinacci, et al. Expires March 30, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 headers are used. The UDP header length is 8 bytes. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See section Section 6.3.1 for details. L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. E: this is the echo-nonce-request bit. When this bit is set to 1, the N bit must be 1. 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. rflags: this 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 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. When the E-bit is clear but the N-bit is set, an ITR is either echoing a previously requested echo-nonce or providing a random nonce. See section Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least 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 outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Farinacci, et al. Expires March 30, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 Type of Service field (with one caveat, see below). When doing Re-encapsulated Tunneling: o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer 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. Farinacci, et al. Expires March 30, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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. Farinacci, et al. Expires March 30, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet with DF bit set to 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. Farinacci, et al. Expires March 30, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires March 30, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 | | + 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. Farinacci, et al. Expires March 30, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Encapsulated Control Message: 8 b'1000' 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=3D1 |A|M|P|S| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . 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: Farinacci, et al. Expires March 30, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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 Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. 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. When Map-Requests are used for refreshing a map-cache entry or for RLOC-probing, the value 0 is used. Originating ITR RLOC Address: Used to give the ETR the option of returning a Map-Reply in the address-family of this locator. Farinacci, et al. Expires March 30, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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. The source address is either an IPv4 or IPv6 RLOC address depending if the Map-Request is using an IPv4 versus IPv6 header, respectively. 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 4342 with a LISP type value set to "Encapsulated Control Message", 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]. Farinacci, et al. Expires March 30, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request, it may originate a "verifying Map-Request", addressed to the original ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map-Request" to the original Map-Request source. If not, then it MUST send it to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" mapping data. Farinacci, et al. Expires March 30, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| 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. See section Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is advertising that the site 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. Farinacci, et al. Expires March 30, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of 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. 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. Unassigned values should cause a map-cache entry to be created and, when packets match this negative cache entry, they will be dropped. The current assigned values are: (0) Drop: The packet is dropped silently. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) 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. 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. Farinacci, et al. Expires March 30, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 30, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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- Farinacci, et al. Expires March 30, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 UDP with a destination UDP port of 4342 and a randomly selected UDP source port number. 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=3D3 |P| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| 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: Farinacci, et al. Expires March 30, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Key ID: A configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. Authentication Data Length: The length in bytes of the Authentication Data field that follows this field. The length of the the Authentication Data field is dependent on the Message Authentication Code (MAC) algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Authentication Data: The message digest used from the output of the Message Authentication Code (MAC) algorithm. The entire Map- Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] is recommended. The definition of the rest of the Map-Register can be found in the Map-Reply section. 6.1.7. Encapsualted Control Message Format An Encapsulated Control Message is used as the service interface between ITRs, ETRs, and the mapping database system described in [LISP-MS]. Farinacci, et al. Expires March 30, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4342 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=3D8 | Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D yyyy = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet header descriptions: OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the source and destination header address fields. UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero. LH: Type 8 is defined to be a "LISP Encapsulated Control Message" and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the reserved field. IH: The inner IPv4 or IPv6 header which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format the destination address in this header is an EID. UDP: The inner UDP header where the port assignments depends on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is randomly assigned and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum Farinacci, et al. Expires March 30, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 field MUST be non-zero. LCM: The format is one of the control message formats described in this 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 Farinacci, et al. Expires March 30, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a Farinacci, et al. Expires March 30, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the 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. Farinacci, et al. Expires March 30, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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-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 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 Farinacci, et al. Expires March 30, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 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 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. 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 Farinacci, et al. Expires March 30, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 obtain those benefits, especially if the 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. Farinacci, et al. Expires March 30, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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- Farinacci, et al. Expires March 30, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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-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-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-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. Farinacci, et al. Expires March 30, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the 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 ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- prefix uses is the one copied from the SMR message. 3. The remote xTR retransmits the Map-Request slowly until it gets a Map-Reply while continuing to use the cached mapping. Farinacci, et al. Expires March 30, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending 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 more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. Farinacci, et al. Expires March 30, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 30, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, Farinacci, et al. Expires March 30, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 30, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 30, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 30, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 30, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. 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. Farinacci, et al. Expires March 30, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Interoperable implementations have been available since the beginning of 2009. We are trying to converge on a packet format so implementations can converge on the -04 and later drafts. 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. Farinacci, et al. Expires March 30, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 30, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts 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. Farinacci, et al. Expires March 30, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, 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. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. Farinacci, et al. Expires March 30, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 [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. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 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] Farinacci, et al. Expires March 30, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-02.txt (work in progress), 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. Farinacci, et al. Expires March 30, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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. Farinacci, et al. Expires March 30, 2010 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, and Jari Arkko. 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. Farinacci, et al. Expires March 30, 2010 [Page 67] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-05.txt o Posted October 2009. o Added this Document Change Log appendix. o Added section indicating that encapsulated Map-Requests must use destination UDP port 4342. o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- data in Map-Register payload. o Added Jari to acknowledgment section. o State the source-EID is set to 0 when using Map-Requests to refresh or RLOC-probe. o Make more clear what source-RLOC should be for a Map-Request. o The LISP-CONS authors thought that the Type definitions for CONS should be removed from this specification. o Removed nonce from Map-Register message, it wasn't used so no need for it. o Clarify what to do for unspecified Action bits for negative Map- Replies. Since No Action is a drop, make value 0 Drop. B.2. Changes to draft-ietf-lisp-04.txt o Posted September 2009. o 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? o Add Fred Templin in ack section. o Add Margaret and Sam to the ack section for their great comments. o Say more about LAGs in the UDP section per Sam Hartman's comment. Farinacci, et al. Expires March 30, 2010 [Page 68] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o Sam wants to use MAY instead of SHOULD for ignoring checksums on ETR. =46rom 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." o Margaret wants a reference to http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt. o Fix description in Map-Request section. Where we describe Map- Reply Record, change "R-bit" to "M-bit". o Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs but often enough to get mapping updates. o Indicate SHA1 can be used as well for Map-Registers. o More Fred comments on MTU handling. o Isidor comment about specing better periodic Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. o 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." o Add section on RLOC-probing per working group feedback. o Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. o Remove SMR-bit from data-plane. Dino prefers to have it in the control plane only. o 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. o Add a N-bit to the data header suggested by Noel. Then the nonce field could be used when N is not 1. Farinacci, et al. Expires March 30, 2010 [Page 69] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o Clarify that when E-bit is 0, the nonce field can be an echoed nonce or a random nonce. Comment from Jesper. o 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. o Indicate that a verifying Map-Request, for accepting mapping data, should be sent over the the ALT (or to the EID). o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- noncing. Comment by Pedro and Dino. o 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. B.3. Changes to draft-ietf-lisp-03.txt o Posted July 2009. o Removed loc-reach-bits longword from control packets per Damien comment. o Clarifications in MTU text from Roque. o Added text to indicate that the locator-set be sorted by locator address from Isidor. o Clarification text from JohnZ in Echo-Nonce section. B.4. Changes to draft-ietf-lisp-02.txt o Posted July 2009. o Encapsulation packet format change to add E-bit and make loc- reach-bits 32-bits in length. o Added Echo-Nonce Algorithm section. o Clarification how ECN bits are copied. o Moved S-bit in Map-Request. Farinacci, et al. Expires March 30, 2010 [Page 70] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o Added P-bit in Map-Request and Map-Reply messages to anticipate RLOC-Probe Algorithm. o Added to Mobility section to reference draft-meyer-lisp-mn-00.txt. B.5. Changes to draft-ietf-lisp-01.txt o Posted 2 days after draft-ietf-lisp-00.txt in May 2009. o Defined LEID to be a "LISP EID". o Indicate encapsulation use IPv4 DF=3D0. o Added negative Map-Reply messages with drop, native-forward, and send-map-request actions. o Added Proxy-Map-Reply bit to Map-Register. B.6. Changes to draft-ietf-lisp-00.txt o Posted May 2009. o Rename of draft-farinacci-lisp-12.txt. o Acknowledgment to RRG. Farinacci, et al. Expires March 30, 2010 [Page 71] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 30, 2010 [Page 72] =0C --Apple-Mail-104-839887824 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-104-839887824-- From lear@cisco.com Sun Sep 27 03:43: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 805F63A67B5 for ; Sun, 27 Sep 2009 03:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.243 X-Spam-Level: X-Spam-Status: No, score=-10.243 tagged_above=-999 required=5 tests=[AWL=0.356, 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 KqKtlqc3Ahfk for ; Sun, 27 Sep 2009 03:43:10 -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 01E5F3A67A5 for ; Sun, 27 Sep 2009 03:43:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAAJPevkqQ/uCKe2dsb2JhbACBT5kyAQEWJAahIohTAY4lBYQe X-IronPort-AV: E=Sophos;i="4.44,460,1249257600"; d="scan'208";a="50327976" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Sep 2009 10:44:23 +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 n8RAiN5r008255; Sun, 27 Sep 2009 12:44:23 +0200 Received: from elear-mac.local (dhcp-10-61-97-18.cisco.com [10.61.97.18]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8RAiNvH015596; Sun, 27 Sep 2009 10:44:23 GMT Message-ID: <4ABF4207.7050700@cisco.com> Date: Sun, 27 Sep 2009 12:44:23 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Luigi Iannone References: <4AB9B6BE.6070006@cisco.com> <4ABE2487.5000302@cisco.com> <80FD669A-E5F7-4084-84E3-D104670EC11E@net.t-labs.tu-berlin.de> In-Reply-To: <80FD669A-E5F7-4084-84E3-D104670EC11E@net.t-labs.tu-berlin.de> 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=154; t=1254048264; x=1254912264; 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]=20Call=20for=20interest=20in=20w orking=20on=20security |Sender:=20; bh=G0njk4oOv3h+dyEZuY+p5mspsySqtF9J0IGWGQNUuKQ=; b=pArMfpHSVMv2kWNxXe8khPmlzeSMKj5IsaCQezU3WRyalOIWfX9TNWKx8F +f03QGMsFhYC4xtz4br2c6n6J+nKmeOR2k06TSGLzR3Oqg+FzIVpiSAkV82c UsdF0RspDZ; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] Call for interest in working on security X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 27 Sep 2009 10:43:11 -0000 Luigi, You're right that we should be careful about separating the systems. I like, by the way, both your and Sam's organizing principles. Eliot From mrw@sandstorm.net Sun Sep 27 08:18: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 97DA23A68BE for ; Sun, 27 Sep 2009 08:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.076, 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 VXdTtVbTu9Av for ; Sun, 27 Sep 2009 08:18:48 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 8B1BD3A682A for ; Sun, 27 Sep 2009 08:18:48 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n8RFIXo3015380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 Sep 2009 11:18:33 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <2A7D106B-D5A0-4338-BB45-39DE9E6FB048@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: Sun, 27 Sep 2009 11:18:33 -0400 References: <3D19B2AF-6434-4CE4-88EA-A4414EFCD582@cisco.com> <8F75FB29-FC8E-4C3C-A91A-15A10E917936@sandstorm.net> <2A7D106B-D5A0-4338-BB45-39DE9E6FB048@cisco.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Proposed change to draft-ietf-lisp-05.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: Sun, 27 Sep 2009 15:18:49 -0000 Thanks for the reply, Dino. On Sep 27, 2009, at 12:08 AM, Dino Farinacci wrote: >> If I understood correctly, only the Map-Request would be encapsulated >> this way, right? The Map-Register and Map-Reply packets would not, > > Right. > >> right? So, saying that this is the service interface between ITRs, >> ETRs >> and the mapping database system would seem to be an overstatement. > > Why is that? Because it says that "an Encapsulated Message is used as the service interface"... There are several issues with that: (1) As I think we agree, the interface between the ITR, ETR and mapping system will involve both encapsulated and unencapsulated messages. So encapsulated messages aren't "the service interface"... (2) A service interface is not (merely) a packet layout. So, this is the wrong place in the document to claim we are defining the service interface. In fact, this document doesn't define the full service interface at all, as the actual service interface is defined in LISP-MS. How about the following change: Your Proposed -05: An Encapsulated Control Message is used as the service interface between ITRs, ETRs, and the mapping database system described in [LISP-MS]. New: An Encapsulated Control Message is used to encapsulate control packets sent between xTRs and the mapping database system described in [LISP-MS]. >> >> I thought that the inner UDP destination port would also be 4342, >> as the next >> thing up is also a LISP control message. > > I kept it unspecified because a Map-Reply or Map-Register *could* be > encapsulated as well. At least the packet format could allow it even > though the text doesn't indicate that anywhere. That is, only a Map- > Request can be encapsulated and that *is* specified. Okay. >> As indicated above, I believe that this particular encapsulation >> diagram will >> only be used for Map-Register, so much of this text should be >> reworked. I >> also think it will always have a UDP destination port of 4342, right? > > This *could* be a feature. I'd like to keep it there. The code > should be able to decode any control packet type that is encapsulated. I am a bit concerned about the interoperability implications here... Are we actually requiring that LISP nodes be able to decode any control message type inside an Encapsulated Control Packet? If so, I don't think that text was included in your edits, is it? Also, if you want to make this generic, why have you limited its scope to the mapping system described in [LISP-MS], and why have you indicated that it may contain one of three control message types? At the present time, it seems that the text is in an awkward position half-way between defining the specific usage of this encapsulation (Map- Registers) and making it a generic encapsulation for any control message. I'm not sure which way the WG would prefer to go on this (I could go either way), but we should pick one and do that. This whole discussion has me wondering why the functionality of the mapping database system is defined in [LISP-MS] while the associated control packets are defined in [LISP]. It seems like this creates overlapping content in the two documents, with no strong notion of which would be considered normative if they don't match. Also, it makes both documents harder to read, IMO. Would you consider moving the mapping-related control messages to [LISP-MS]? >> Why is this set to 0? Wouldn't this still be useful to determine >> that a reply was actually in response to our request? Why include >> the field in the Map-Register message if it will always be 0? > > Because it is not used. I think I'll remove the nonce from the Map- > Register. Is that okay with everyone? Since the Map-Register is a > one-way packet, the map-server can't do anything with it. I would support removing it. Margaret From dino@cisco.com Sun Sep 27 10:45: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 296F13A67D2 for ; Sun, 27 Sep 2009 10:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 JuU+0Nni74M7 for ; Sun, 27 Sep 2009 10:45:30 -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 1F2283A67A7 for ; Sun, 27 Sep 2009 10:45:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHpBv0qrR7PD/2dsb2JhbAC8CYhTAY1+BYQe X-IronPort-AV: E=Sophos;i="4.44,461,1249257600"; d="scan'208";a="397266645" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Sep 2009 17:46:45 +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 n8RHkjHh022815; Sun, 27 Sep 2009 10:46:45 -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 n8RHkj0M013561; Sun, 27 Sep 2009 17:46:45 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); Sun, 27 Sep 2009 10:46:44 -0700 Received: from [192.168.1.2] ([10.21.124.162]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Sep 2009 10:46:44 -0700 Message-Id: <8082EAC0-72D7-4CF2-BB13-7BDE4337225A@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 v936) Date: Sun, 27 Sep 2009 10:46:43 -0700 References: <3D19B2AF-6434-4CE4-88EA-A4414EFCD582@cisco.com> <8F75FB29-FC8E-4C3C-A91A-15A10E917936@sandstorm.net> <2A7D106B-D5A0-4338-BB45-39DE9E6FB048@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Sep 2009 17:46:44.0340 (UTC) FILETIME=[7A553B40:01CA3F9A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4959; t=1254073605; x=1254937605; 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=20change=20to=20draft -ietf-lisp-05.txt |Sender:=20; bh=vAtpj3n3TNQoyL+uCSRk8E4i4FrMdRm2Nt9FmSmdf0s=; b=MIPYS2L4oRNeJOuSekSH5vMLNporOHIQC9dDKtPVeefU1F6SJEu4tuIp4s FCUy/7WmA3Z5XF6MevXYNGBRFWLS1O7N3IVjAq9Tk3SDUfgv2WV6AwOSUTru DjgS4kai5a; 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] Proposed change to draft-ietf-lisp-05.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: Sun, 27 Sep 2009 17:45:31 -0000 > Thanks for the reply, Dino. > > On Sep 27, 2009, at 12:08 AM, Dino Farinacci wrote: >>> If I understood correctly, only the Map-Request would be >>> encapsulated >>> this way, right? The Map-Register and Map-Reply packets would not, >> >> Right. >> >>> right? So, saying that this is the service interface between >>> ITRs, ETRs >>> and the mapping database system would seem to be an overstatement. >> >> Why is that? > > Because it says that "an Encapsulated Message is used as the service > interface"... There are several issues with that: > > (1) As I think we agree, the interface between the ITR, ETR and > mapping > system will involve both encapsulated and unencapsulated messages. So > encapsulated messages aren't "the service interface"... In the existing documents, that is the way *we* defined it. > (2) A service interface is not (merely) a packet layout. So, this > is the > wrong place in the document to claim we are defining the service > interface. In fact, this document doesn't define the full service > interface > at all, as the actual service interface is defined in LISP-MS. That is correct. We reference the LISP-MS document. So why be so pedantic? > How about the following change: > > Your Proposed -05: > An Encapsulated Control Message is used as the service interface > between ITRs, ETRs, and the mapping database system described in > [LISP-MS]. > > New: > An Encapsulated Control Message is used to encapsulate control > packets sent between xTRs and the mapping database system > described in [LISP-MS]. Fine, I can make that change. But we are splitting hairs IMO. >>> I thought that the inner UDP destination port would also be 4342, >>> as the next >>> thing up is also a LISP control message. >> >> I kept it unspecified because a Map-Reply or Map-Register *could* >> be encapsulated as well. At least the packet format could allow it >> even though the text doesn't indicate that anywhere. That is, only >> a Map-Request can be encapsulated and that *is* specified. > > Okay. >>> As indicated above, I believe that this particular encapsulation >>> diagram will >>> only be used for Map-Register, so much of this text should be >>> reworked. I >>> also think it will always have a UDP destination port of 4342, >>> right? >> >> This *could* be a feature. I'd like to keep it there. The code >> should be able to decode any control packet type that is >> encapsulated. > > I am a bit concerned about the interoperability implications > here... Are we actually requiring that LISP nodes be able to decode > any > control message type inside an Encapsulated Control Packet? In the future yes, now, they don't have to. Don't worry, be happy. ;-) > If so, I don't think that text was included in your edits, is it? > Also, if you want to make this generic, why have you limited its > scope to the mapping system described in [LISP-MS], and why have you Because that is all we have designed so far. > indicated that it may contain one of three control message types? > At the present time, it seems that the text is in an awkward > position half-way between defining the specific usage of this > encapsulation (Map-Registers) and making it a generic encapsulation > for any control message. I'm not sure which way the WG would prefer > to go on this (I could go either way), but we should pick one and do > that. Can we please leave it this way? It is not hurting anything and it doesn't narrow the specification we can experiment with new ideas. > This whole discussion has me wondering why the functionality of the > mapping database system is defined in [LISP-MS] while the associated > control packets are defined in [LISP]. It seems like this creates Like I have said many times, we wanted to packet formats in one place so insanity wouldn't ensue in the implementer's mind. > overlapping content in the two documents, with no strong notion of > which would be considered normative if they don't match. Also, it > makes both documents harder to read, IMO. Would you consider moving > the mapping-related control messages to [LISP-MS]? We are not overlapping. The main spec says there is a packet format, and the MS spec says how to use it. There is a clear demarc. >>> Why is this set to 0? Wouldn't this still be useful to determine >>> that a reply was actually in response to our request? Why include >>> the field in the Map-Register message if it will always be 0? >> >> Because it is not used. I think I'll remove the nonce from the Map- >> Register. Is that okay with everyone? Since the Map-Register is a >> one-way packet, the map-server can't do anything with it. > > I would support removing it. I will send out another diff tonight with your suggested fix above. Dino From dino@cisco.com Mon Sep 28 00:46: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 757423A67D2 for ; Mon, 28 Sep 2009 00:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5xi2Xl+tV4I for ; Mon, 28 Sep 2009 00:46: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 CD68F3A67CF for ; Mon, 28 Sep 2009 00:46:16 -0700 (PDT) X-Files: rfcdiff-lisp-04-to-05.html, draft-ietf-lisp-05.txt : 301054, 161474 X-IronPort-AV: E=Sophos;i="4.44,465,1249257600"; d="txt'?html'217?scan'217,208,217";a="208715416" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 28 Sep 2009 07:47:33 +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 n8S7lU9C012745 for ; Mon, 28 Sep 2009 00:47:30 -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 n8S7lU9Z012605 for ; Mon, 28 Sep 2009 07:47:30 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, 28 Sep 2009 00:47:30 -0700 Received: from [192.168.1.2] ([10.21.145.22]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 00:47:29 -0700 Message-Id: <4AC20997-2940-42CA-9A08-01034A1DB130@cisco.com> From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-6-938941840 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 28 Sep 2009 00:47:28 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Sep 2009 07:47:29.0178 (UTC) FILETIME=[EDCCA7A0:01CA400F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=471980; t=1254124053; x=1254988053; 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:=20Early=20Monday=20morning=20diffs |Sender:=20; bh=3zTYVqcU5w5hEpC1d/uJ7Gx3CQqiuqd6BFNJXyed2XY=; b=lZ2hV1cMnJXOO6r13Xvi3iOk7HMva+AHpNVyVAh5C2gIjr85V4oQTkqMRH 2l4UFKfMQ1OOl9xkCCPfGnuH3wdA++xiqUHNdrIM4QwHMhueupZ+zOsOOlIH hTBGWITOjw; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [lisp] Early Monday morning diffs X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 Sep 2009 07:46:17 -0000 --Apple-Mail-6-938941840 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Contains Margaret's text in the intro section of "Encapsultated Control Message Formats". Chairs, have any idea when we can have rough consensus on this and when we can post -05? Thanks, Dino/Dave/Darrel/Vince --Apple-Mail-6-938941840 Content-Disposition: attachment; filename=rfcdiff-lisp-04-to-05.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-04-to-05.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-04.txt draft-ietf-lisp-05.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: March 20, 30, 2010                                         D. Lewis
                                                           cisco Systems
                                                      September 16, 26, 2009

                 Locator/ID Separation Protocol (LISP)
                         draft-ietf-lisp-04.txt
           (PROPOSED) draft-ietf-lisp-05.txt (NOT POSTED YET)

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 March 20, 30, 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 . . . . . . . . . 22
       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 30
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 32 33
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 33 34
       6.1.7.  Encapsualted Control Message Format  . . . . . . . . . 35
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 36 37
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 37 38
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 39 41
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41 42
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 41 43
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 42 43
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 43 44
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 44 45
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 46 47
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 47 48
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 48 49
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 48 49
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 49 50
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 50 51
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 51 52
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 51 52
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 51 52
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 53 54
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 53 54
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 54
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 54
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 55 56
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 55 56
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 57 58
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 58 59
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 59 60
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 63
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 62 63
     14.2. Informative References . . . . . . . . . . . . . . . . . . 63 64
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 66 67
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 68
     B.1.  Changes to draft-ietf-lisp-05.txt  . . . . . . . . . . . . 68
     B.2.  Changes to draft-ietf-lisp-04.txt  . . . . . . . . . . . . 68
     B.3.  Changes to draft-ietf-lisp-03.txt  . . . . . . . . . . . . 70
     B.4.  Changes to draft-ietf-lisp-02.txt  . . . . . . . . . . . . 70
     B.5.  Changes to draft-ietf-lisp-01.txt  . . . . . . . . . . . . 71
     B.6.  Changes to draft-ietf-lisp-00.txt  . . . . . . . . . . . . 71
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 72

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 statically 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 prepends 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
      statically 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 prepends 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   |N|L|E|  rflags |                 Nonce                         |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       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   |N|L|E|  rflags |                 Nonce                         |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       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

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

   Outer 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 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 SHOULD be transmitted as zero by an ITR for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
      packet with a zero UDP checksum is received by an ETR, the ETR
      MUST accept the packet for decapsulation.  When an ITR transmits a
      non-zero value for the UDP checksum, it MUST send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.  The handling of UDP checksums for all tunneling
      protocols, including LISP, is under active discussion within the
      IETF.  When that discussion concludes, any necessary changes will
      be made to align LISP with the outcome of the broader discussion.

   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.

   N: this is the nonce-present bit.  When this bit is set to 1, the
      low-order 24-bits of the first 32-bits of the LISP header contains
      a Nonce.  See section Section 6.3.1 for details.

   L: this is the Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are in use.

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1.  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.

   rflags:  this 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
      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.  When the E-bit is clear but the N-bit
      is set, an ITR is either echoing a previously requested echo-nonce
      or providing a random nonce.  See section Section 6.3.1 for more
      details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator Status Bits are numbered from 0 to n-1 from the least
      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 outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

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

   When doing Re-encapsulated Tunneling:

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

   o  The new outer 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 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
       LISP Encapsulated Control 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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.  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 Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  An 8-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.  The
      security of the LISP mapping protocol depends critically on the
      strength of the nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   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.  When
      Map-Requests are used for refreshing a map-cache entry or for
      RLOC-probing, the value 0 is used.

   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 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.  The
   source address is either an IPv4 or IPv6 RLOC address depending if
   the Map-Request is using an IPv4 versus IPv6 header, respectively.
   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
   4342 with a LISP type value set to "Encapsulated Control Message",
   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.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request, it may
   originate a "verifying Map-Request", addressed to the original ITR.
   If the ETR has a map-cache entry that matches the "piggybacked" EID
   and the RLOC is in the locator-set for the entry, then it may send
   the "verifying Map-Request" to the original Map-Request source.  If
   not, then it MUST send it to the "piggybacked" EID.  Doing this
   forces the "verifying Map-Request" to go through the mapping database
   system to reach the authoritative source of information about that
   EID, guarding against RLOC-spoofing in in the "piggybacked" 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|E|            Reserved               | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      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.  See
      section Section 6.3.2 for more details.

   E: Indicates that the ETR which sends this Map-Reply message is
      advertising that the site 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 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request is echoed in this Nonce field of 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.

   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.  Unassigned values should
      cause a map-cache entry to be created and, when packets match this
      negative cache entry, they will be dropped.  The current assigned
      values are:

      (0) No action:  No action Drop:  The packet is being conveyed by the sender of the
         Map-Reply message. dropped silently.

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

      (2) Drop:  The packet is dropped silently.

      (3) Send-Map-Request: 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.

   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 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 of 4342 and a
   randomly selected UDP source 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 [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 [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 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            Key ID             |                         . . . Nonce  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      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:  This 8-byte Nonce field is set

   Key ID:  A configured ID to 0 in Map-Register messages. find the configured Message
      Authentication Code (MAC) algorithm and key value used for the
      authentication function.

   Authentication Data Length:  The definition length in bytes of the rest
      Authentication Data field that follows this field.  The length 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 Authentication Data field is achieved by
   manipulating dependent on 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. Message
      Authentication Code (MAC) algorithm used.  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 length field allows
      a subset of the list has
      the same best priority.  Client can only use device that doesn't know the subset list
      according MAC algorithm to correctly parse
      the weighting assigned by the server-side.  In this
      case, packet.

   Authentication Data:  The message digest used from the server-side controls both output of the subset list and load-
      splitting across its members.
      Message Authentication Code (MAC) algorithm.  The client-side can use RLOCs
      outside of entire Map-
      Register payload is authenticated with this field preset to 0.
      After the subset list if MAC is computed, it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255).  Some
      sharing placed in this field.
      Implementations of control exists: the server-side determines the
      destination RLOC list this specification MUST include support for
      HMAC-SHA-1-96 [RFC2404] and load distribution while the client-side
      has the option support for HMAC-SHA-128-256 [RFC4634]
      is recommended.

   The definition of using alternatives to this list if RLOCs in the
      list are unreachable.

   o  Server-side sets weight rest of 0 for the RLOC subset list.  In this
      case, the client-side Map-Register can choose how the traffic load is spread
      across be found in the subset list.
   Map-Reply section.

6.1.7.  Encapsualted Control Message Format

   An Encapsulated Control Message is shared by the server-side
      determining used as the list service interface
   between ITRs, ETRs, 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 mapping database system described in
   [LISP-MS].

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   OH  |                      (uses RLOC
      reachability and preferability.  Server-side ETR gleaning of the
      client-side ITR addresses)                    |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4342        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LH  |Type=8 |                   Reserved                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   IH  |                  (uses RLOC is done by caching the inner header source or EID and the addresses)                 |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = yyyy        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LCM |                      LISP Control Message                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet header descriptions:

   OH:   The outer IPv4 or IPv6 header source which uses RLOC of received packets.  The
      client-side ITR controls how traffic is returned addresses in the
      source and can alternate
      using an destination header address fields.

   UDP:   The outer UDP header with destination port 4342.  The source RLOC, which then can
      port is randomly allocated.  The checksum field MUST be added to the
      list the server-side ETR uses non-zero.

   LH:   Type 8 is defined to return traffic.  Since no
      Priority be a "LISP Encapsulated Control Message"
      and what follows is either an IPv4 or Weights are provided using this method, IPv6 header as encoded by
      the server-
      side ETR must assume each client-side ITR first 4 bits after the reserved field.

   IH:   The inner IPv4 or IPv6 header which can use either RLOC uses or EID
      addresses in the same best
      Priority with header address fields.  When a Weight of zero.  In addition, since EID-prefix
      encoding cannot be conveyed Map-Request is
      encapsulated in data packets, this packet format the EID-to-RLOC cache destination address in this
      header is an EID.

   UDP:   The inner UDP header where the port assignments depends on tunnel routers can grow to be very large.

   o  A "gleaned" map-cache entry, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification
      control packet being encapsulated.  When the control packet is performed by
      sending a
      Map-Request to or Map-Register, the source EID (the inner header IP
      source address) of port is randomly assigned
      and the received encapsulated packet.  A reply to
      this "verifying Map-Request" destination port is used to fully populate 4342.  When the map-
      cache entry for control packet is a
      Map-Reply, the "gleaned" EID and source port is stored 4342 and used for the
      time indicated destination port is
      assigned from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix port of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply or that stored in the
   mapping database system provide reachability information for RLOCs.
   Such reachability needs invoking Map-Request.  Port
      number 4341 MUST NOT be assigned to either port.  The checksum
      field MUST be determined separately, using non-zero.

   LCM:   The format is one or
   more of the Routing Locator Reachability Algorithms control message formats described in the
   next
      this section.

6.3.

6.2.  Routing Locator Reachability

   Several mechanisms for determining RLOC reachability are currently
   defined:

   1.  An ETR Selection

   Both client-side and server-side may examine the Loc-Status-Bits in need control over the LISP header selection
   of an
       encapsulated data packet received from an ITR.  If the ETR RLOCs for conversations between them.  This control is
       also acting as an ITR and has traffic to return to achieved by
   manipulating the original
       ITR site, it can use this status Priority and Weight fields in EID-to-RLOC Map-Reply
   messages.  Alternatively, RLOC information to help select an
       RLOC.

   2.  An ITR may receive an ICMP Network be gleaned from
   received tunneled packets or ICMP Host Unreachable
       message EID-to-RLOC Map-Request messages.

   The following enumerates different scenarios for an RLOC it is using.  This indicates 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 is
       likely down.

   3.  An ITR which participates in where a subset of the global routing system list has
      the same best priority.  Client can
       determine that an RLOC is down if no BGP RIB route exists that
       matches only use the RLOC IP address.

   4.  An ITR may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR attempts subset list
      according to use
       interworking [INTERWORK] the weighting assigned by the server-side.  In this
      case, the server-side controls both the subset list and LISP-encapsulated data load-
      splitting across its members.  The client-side can use RLOCs
      outside of the subset list if it determines that the subset list
      is sent to a
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in response unreachable (unless RLOCs are set to a
       previously sent Map-Request.  The RLOC source Priority of 255).  Some
      sharing of control exists: the Map-Reply is
       likely up since server-side determines the ETR was able to send
      destination RLOC list and load distribution while the Map-Reply client-side
      has the option of using alternatives to this list if RLOCs in the
       ITR.

   6.  When an ETR receives an encapsulated packet from an ITR,
      list are unreachable.

   o  Server-side sets weight of 0 for the
       source RLOC from subset list.  In this
      case, the outer header of client-side can choose how the packet traffic load is likely up.

   7.  An ITR/ETR pair can use spread
      across the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability subset list.  Control is shared by examining the Loc-
   Status-Bits from server-side
      determining the LISP encapsulated data packet, an ETR will
   receive up to date status from an encapsulating ITR about
   reachability for all ETRs at list and the site.  CE-based ITRs at client determining load distribution.
      Again, the source
   site client can determine reachability relative to each other using use alternative RLOCs if the site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route into the site IGP. server-provided
      list of RLOCs are unreachable.

   o  If an ITR fails or if  Either side (more likely on the upstream link server-side ETR) decides not to its PE fails, its
      default route will either time-out or be withdrawn.

   Each ITR can thus observe the presence or lack of
      send a default route
   originated by the others to determine Map-Request.  For example, if the Locator Status Bits server-side ETR does not
      send Map-Requests, it sets
   for them. gleans RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1.  The
   Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit.  For example, if an RLOC
   listed in client-side ITR,
      giving the 3rd position client-side ITR responsibility for bidirectional RLOC
      reachability and preferability.  Server-side ETR gleaning of the Map-Reply goes down (ordinal value
   2), then all ITRs at
      client-side ITR RLOC is done by caching the site will clear inner header source
      EID and the 3rd least significant
   bit (xxxx x0xx) 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 Loc-Status-Bits field for
      list the packets they
   encapsulate.

   When an server-side ETR decapsulates a packet, it will check for any change in
   the Loc-Status-Bits field.  When a bit goes from 1 uses to 0, return traffic.  Since no
      Priority or Weights are provided using this method, the server-
      side ETR will
   refrain from encapsulating packets to an RLOC that is indicated as
   down.  It will only resume using that must assume each client-side ITR RLOC if uses the corresponding Loc-
   Status-Bit returns to a value of 1.  Loc-Status-Bits are associated same best
      Priority with a locator-set per EID-prefix.  Therefore, when a locator becomes
   unreachable, the Loc-Status-Bit that corresponds to that locator's
   position in the list returned by the last Map-Reply will Weight of zero.  In addition, since EID-prefix
      encoding cannot be set to
   zero for that particular EID-prefix.

   When ITRs at the site are not deployed conveyed in CE routers, data packets, the IGP EID-to-RLOC cache
      on tunnel routers can
   still be used grow to determine be very large.

   o  A "gleaned" map-cache entry, one learned from the reachability source RLOC of Locators provided they
   are injected into the IGP.  This is typically done when a /32 address
      received encapsulated packet, is configured on only stored and used for a loopback interface.

   When ITRs receive ICMP Network or Host Unreachable messages as few
      seconds, pending verification.  Verification is performed by
      sending a
   method Map-Request to determine unreachability, they will refrain from using
   Locators which are described in Locator lists the source EID (the inner header IP
      source address) of Map-Replies.
   However, using the received encapsulated packet.  A reply to
      this approach "verifying Map-Request" 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 used to fully populate the map-
      cache entry for the
   host that originated "gleaned" EID and is stored and used for the data packet
      time indicated from the ITR encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if
   a locator address from TTL field of a locator-set in received Map-Reply.  When a mapping
      verified map-cache 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-Status-Bits indicate the locator is up.  In this case, the path
   from the ITR to the ETR stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that is assigned matches 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
      EID-prefix of the Locator has been determined.
   Obviously, sending such probes increases the number of control verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply 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 R-bit for
   active traffic; this the locator record is set to 1.  Neither
   the same as if it were listed information contained in a Map-Reply
   with priority 255.

   The ITR can test or that stored in the
   mapping database system provide reachability information for RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the unreachable Routing Locator by
   sending periodic Requests.  Both Requests and Replies MUST be rate-
   limited. Reachability Algorithms described in the
   next section.

6.3.  Routing Locator reachability testing is never done with data
   packets since that increases the risk of packet loss Reachability

   Several mechanisms for end-to-end
   sessions.

   When an determining RLOC reachability are currently
   defined:

   1.  An ETR decapsulates a packet, it knows that it is reachable from may examine the encapsulating ITR because that is how Loc-Status-Bits in the LISP header of an
       encapsulated data packet arrived.  In
   most cases, received from an ITR.  If the ETR can is
       also reach the acting as an ITR but cannot assume this and has traffic to
   be true due return to the possibility of path asymmetry.  In the presence of
   unidirectional traffic flow from an original
       ITR site, it can use this status information to help select an ETR, the
       RLOC.

   2.  An ITR should not
   use the lack of return traffic as may receive an indication ICMP Network or ICMP Host Unreachable
       message for an RLOC it is using.  This indicates that the ETR is
   unreachable.  Instead, it must use an alternate mechanisms to
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When there RLOC is bidirectional data flow between a pair of locators, a
   simple mechanism called "nonce echoing"
       likely down.

   3.  An ITR which participates in the global routing system can be used to
       determine
   reachability between that an RLOC is down if no BGP RIB route exists that
       matches the RLOC IP address.

   4.  An ITR and ETR.  When may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR wants attempts to solicit a
   nonce echo, it sets the N and E bits use
       interworking [INTERWORK] and places a 24-bit nonce in the
   LISP header of the next encapsulated LISP-encapsulated data packet.

   When this packet is received by the ETR, sent to a
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in response to a
       previously sent Map-Request.  The RLOC source of the encapsulated packet Map-Reply is
   forwarded as normal.  When
       likely up since the ETR next sends a data packet was able to send the
   ITR, it includes the nonce received earlier with the N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the path Map-Reply to
   and from the
       ITR.

   6.  When an ETR is up.

   The ITR will set the E-bit and N-bit for every receives an encapsulated packet it sends while
   in echo-nonce-request state.  The time from an ITR, the ITR waits to process
       source RLOC from the
   echoed nonce before it determines outer header of the path is unreachable packet is variable
   and a choice left for likely up.

   7.  An ITR/ETR pair can use the implementation.

   If Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability by examining the ITR is receiving packets Loc-
   Status-Bits from the LISP encapsulated data packet, an ETR but does not see will
   receive up to date status from an encapsulating ITR about
   reachability for all ETRs at the
   nonce echoed while being in echo-nonce-request state, then site.  CE-based ITRs at the path source
   site can determine reachability relative to the ETR is unreachable.  This decision may be overridden by each other
   locator reachability algorithms.  Once using the site
   IGP as follows:

   o  Under normal circumstances, each ITR determines will advertise a default
      route into the path to site IGP.

   o  If an ITR fails or if the ETR is down it can switch upstream link to another locator for that EID-prefix.

   Note that "ITR" and "ETR" are relative terms here.  Both devices must its PE fails, its
      default route will either time-out or be implementing both ITR and ETR functionality for the echo nonce
   mechanism to operate.

   The withdrawn.

   Each ITR and ETR may both go into echo-nonce-request state at can thus observe the same
   time.  The number of packets sent presence or lack of a default route
   originated by the time during which echo nonce
   requests others to determine the Locator Status Bits it sets
   for them.

   RLOCs listed in a Map-Reply are sent is an implementation specific setting.  However,
   when an ITR is numbered with ordinals 0 to n-1.  The
   Loc-Status-Bits in echo-nonce-request state, it can echo a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the ETR's
   nonce least significant bit.  For example, if an RLOC
   listed in the next set 3rd position of packets that it encapsulates and the Map-Reply goes down (ordinal value
   2), then
   subsequently, continue sending echo-nonce-request packets.

   This mechanism does not completely solve all ITRs at the forward path
   reachability problem as traffic may be unidirectional.  That is, site will clear the 3rd least significant
   bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR receiving traffic at decapsulates a site may not may not be packet, it will check for any change in
   the same device as
   an ITR which transmits traffic Loc-Status-Bits field.  When a bit goes from that site or 1 to 0, the site ETR will
   refrain from encapsulating packets to site
   traffic is unidirectional so there an RLOC that is no ITR returning traffic.

   The echo-nonce algorithm is bilateral.  That is, indicated as
   down.  It will only resume using that RLOC if one side sets the
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing corresponding Loc-
   Status-Bit returns to a value of the nonce does not occur and the requesting side may
   regard the 1.  Loc-Status-Bits are associated
   with a locator-set per EID-prefix.  Therefore, when a locator unreachable erroneously.  An ITR should only set becomes
   unreachable, the E-bit Loc-Status-Bit that corresponds to that locator's
   position in a encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed list returned by the E-bit in the Map-
   Reply message.

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

6.3.2.  RLOC Probing Algorithm

   RLOC Probing is a method that an ITR or PTR particular EID-prefix.

   When ITRs at the site are not deployed in CE routers, the IGP can use
   still be used 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 Locators provided they
   are used for RLOC Probing.

   RLOC probing injected into the IGP.  This is typically done in the control-plane when a /32 address
   is configured on a timer basis where an
   ITR loopback interface.

   When ITRs receive ICMP Network or PTR will originate Host Unreachable messages as a Map-Request destined
   method to a locator address determine unreachability, they will refrain 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 using
   Locators which are described in the Map-Request Locator lists of Map-Replies.
   However, using this approach is the EID-prefix unreliable because many network
   operators turn off generation of the map-cache entry
   cached by the ITR or PTR.  The ICMP Unreachable messages.

   If an ITR does receive an ICMP Network or PTR may include a mapping data
   record for Host Unreachable message,
   it MAY originate its own database mapping information.

   When an ETR receives a Map-Request ICMP Unreachable 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 destined for the EID-prefix contained in the Map-Request.  This provides
   host that originated the opportunity for data packet the ITR or PTR, which sent encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the RLOC-probe BGP RIB to get
   mapping updates see if there were changes to the ETR's database
   a locator address from a locator-set in a mapping
   entries.

   There are advantages entry matches a
   prefix.  If it does not find one and disadvantages of RLOC Probing.  The greatest
   benefit of RLOC Probing BGP is that running in the Default
   Free Zone (DFZ), it can handle many failure scenarios
   allowing the ITR decide to determine when not use the locator even though the
   Loc-Status-Bits indicate the path to a specific locator is
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator up.  In this case, the path
   from the cached
   locator.  RLOC Probing ITR to the ETR that is assigned the locator is not
   available.  More details are in [LOC-ID-ARCH].

   Optionally, an ITR can also provide RTT estimates between send 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 Map-Request to a Locator and if a Map-
   Reply is in returned, reachability of the Locator has been determined.
   Obviously, sending such probes increases the number of control
   messages required and the
   amount of bandwidth used to obtain those benefits, especially if the
   requirement originated by tunnel routers for failure detection times active flows, so Locators
   are very small.

   Continued research and testing will attempt assumed to characterize be reachable when they are advertised.

   This assumption does create a dependency: Locator unreachability is
   detected by the
   tradeoffs receipt of failure detection times versus message overhead.

6.4.  Routing Locator Hashing ICMP Host Unreachable messages.  When an ETR provides an EID-to-RLOC mapping in a Map-Reply message
   Locator has been determined to
   a requesting ITR, the locator-set be unreachable, it is not used for
   active traffic; this is the EID-prefix may contain
   different priority values for each locator address.  When more than
   one best same as if it were listed in a Map-Reply
   with priority locator exists, the 255.

   The ITR can decide how to load
   share traffic against test the corresponding locators.

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

   1.  Either a source
   sending periodic Requests.  Both Requests and destination address hash can Replies MUST 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 rate-
   limited.  Locator reachability testing is never done with data
   packets since that increases the IP protocol number field or IPv6 next-
       protocol fields risk of a packet a host originates from within a LISP
       site. loss for end-to-end
   sessions.

   When an ETR decapsulates a packet is not a TCP, UDP, or SCTP packet, the
       source and destination addresses only it knows that it is reachable from
   the header are used to
       compute the hash.

   2.  Take the hash value and divide it by encapsulating ITR because that is how the number of locators
       stored in packet arrived.  In
   most cases, the locator-set for ETR can also reach the EID-to-RLOC mapping.

   3.  The remainder will ITR but cannot assume this to
   be yield a value of 0 true due to "number the possibility of locators
       minus 1".  Use path asymmetry.  In the remainder presence of
   unidirectional traffic flow from an ITR to select an ETR, the locator in ITR should not
   use the
       locator-set.

   Note lack of return traffic as an indication that when a packet is LISP encapsulated, the source port number
   in the outer UDP header needs ETR is
   unreachable.  Instead, it must use an alternate mechanisms to be set.  Selecting
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When there is bidirectional data flow between a random value
   allows core routers which are attached to Link Aggregation Groups
   (LAGs) to load-split the encapsulated packets across member links pair of
   such LAGs.  Otherwise, core routers would see locators, a single flow, since
   packets have
   simple mechanism called "nonce echoing" can be used to determine
   reachability between an ITR and ETR.  When an ITR wants to solicit a source address
   nonce echo, it sets the N and E bits and places a 24-bit nonce in the
   LISP header of the ITR, for packets which are
   originated next encapsulated data packet.

   When this packet is received by different EIDs at the source site.  A suggested setting
   for ETR, the source port number computed by an ITR encapsulated packet is a 5-tuple hash
   function on the inner header,
   forwarded as described above.

   Many core router implementations use normal.  When the ETR next sends a 5-tuple hash to decide how to
   balance data packet load across members of a LAG.  The 5-tuple hash to the
   ITR, it includes the source and destination addresses of nonce received earlier with the packet N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the
   source path to
   and destination ports when from the protocol number in ETR is up.

   The ITR will set the E-bit and N-bit for every packet it sends while
   in echo-nonce-request state.  The time the ITR waits to process the
   echoed nonce before it determines the path is TCP or UDP.  For this reason, UDP encoding unreachable is used variable
   and a choice left 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, implementation.

   If the only way an ITR can get a more up-to-
   date mapping is to re-request the mapping.  However, receiving packets from the ITRs do ETR but does not
   know when see the mappings change and
   nonce echoed while being in echo-nonce-request state, then the ETRs do not keep track of who
   requested its mappings.  For scalability reasons, we want to maintain
   this approach but need path
   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 unreachable.  This decision may be overridden by other
   locator reachability algorithms.  Once the ITR determines the path to
   the end of a locator-set, it ETR is
   easy down it can switch to update mappings.  We assume new mappings will maintain the
   same another locator ordering as 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 old mapping but just have new locators
   appended echo nonce
   mechanism to operate.

   The ITR and ETR may both go into echo-nonce-request state at the end same
   time.  The number of packets sent or 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 during which echo nonce
   requests are sent is an ITR has only implementation specific setting.  However,
   when an old mapping but detects bits set ITR is in the loc-status-bits that correspond to locators beyond the list it
   has cached, echo-nonce-request state, it simply ignores them.

   When a locator record is removed from a locator-set, ITRs that have can echo the mapping cached will not use ETR's
   nonce in the removed locator because the xTRs
   will next set the loc-status-bit to 0.  So even if the locator is in the
   list, of packets that it will 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 used.  For new mapping requests, unidirectional.  That is, the xTRs can
   set
   ETR receiving traffic at a site may not may not be the locator address to 0 as well same device as setting the corresponding
   loc-status-bit to 0.  This forces ITRs with old
   an ITR which transmits traffic from that site or new mappings to
   avoid using the removed locator.

   If many changes occur site to a mapping over a long period of time, site
   traffic is unidirectional so there is no ITR returning traffic.

   The echo-nonce algorithm is bilateral.  That is, if one
   will find empty record slots in the middle of side sets the locator-set
   E-bit and new
   records appended to the locator-set.  At some point, it would be
   useful to compact other side is not enabled for echo-noncing, then the locator-set so
   echoing of the loc-status-bit settings can
   be efficiently packed.

   We propose here two approaches for locator-set compaction, one
   operational nonce does not occur and the other a protocol mechanism.  The operational
   approach uses requesting side may
   regard the locator unreachable erroneously.  An ITR should only set
   the E-bit in a clock sweep method.  The protocol approach uses encapsulated data packet when it knows the
   concept of Solicit-Map-Requests.

6.5.1.  Clock Sweep

   The clock sweep approach uses planning ETR is
   enabled for echo-noncing.  This is conveyed by the E-bit in advance and the use of
   count-down TTLs to time out mappings Map-
   Reply message.

   Note that have already been cached.
   The default setting 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 EID-to-RLOC mapping TTL is 24 hours.  So
   there example of control-plane probing.

6.3.2.  RLOC Probing Algorithm

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

   RLOC probing is used:

   1.  24 hours before done in the control-plane on a mapping change 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 take effect, a network
       administrator configures Map-Server or on the ETRs at a site to start
   ALT like one would when soliciting mapping data.  The EID record
   encoded in the clock
       sweep window.

   2.  During Map-Request is the clock sweep window, ETRs continue to send 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
       messages with the current (unchanged) mapping records. P-bit set.  The TTL
       for these mappings source address of the
   Map-Reply 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 from the ETRs continue to send Map-Reply messages
       with destination address of the current (unchanged) mapping records with Map-Request and
   the TTL destination address of the Map-Reply is set to
       1 minute.

   4.  At from the end source
   address of the 1 hour window, the ETRs will send Map-Request.  The Map-Reply
       messages with the new (changed) should contain mapping records.  So any active
       caches can get
   data for the new mapping contents right away if not cached,
       or EID-prefix contained in 1 minute if they had the mapping cached.

6.5.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way Map-Request.  This provides
   the opportunity for xTRs, at the site
   where mappings change, to control ITR or PTR, which sent the rate they receive requests for
   Map-Reply messages.  SMRs are also used RLOC-probe to tell remote ITRs get
   mapping updates if there were changes 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 ETR's database mapping
   entries.  So an xTR will solicit Map-Requests from sites it is
   currently sending encapsulated data to,

   There are advantages and only from those sites. disadvantages of RLOC Probing.  The xTRs greatest
   benefit of RLOC Probing is that it can locally decide handle many failure scenarios
   allowing the algorithm for how often and ITR to determine when the path to how
   many sites it sends SMR messages.

   An SMR message is simply a bit set in a Map-Request message.  An ITR specific locator is
   reachable or PTR will send has become unreachable, thus providing a Map-Request when they receive an SMR message.
   Both the SMR sender and robust
   mechanism for switching to using another locator from the Map-Request responder must rate-limited
   these messages.

   The following procedure shows how a SMR exchange occurs when cached
   locator.  RLOC Probing can also provide RTT estimates between a site
   is doing locator-set compaction pair
   of locators which can be useful for an EID-to-RLOC mapping:

   1.  When the database mappings network management purposes as
   well as for selecting low delay paths.  The major disadvantage of
   RLOC Probing is in an ETR change, the ETRs at number of control messages required and the site
       begin
   amount of bandwidth used to send Map-Requests with obtain those benefits, especially if the SMR bit set
   requirement for each locator
       in each map-cache entry the ETR caches.

   2.  A remote xTR which receives failure detection times are very small.

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

6.4.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Request Map-Reply message to
   a requesting ITR, the source locator address of the SMR
       message.  A newly allocated random nonce is selected and the EID-
       prefix uses is locator-set for the EID-prefix may contain
   different priority values for each locator address.  When more than
   one copied from the SMR message.

   3.  The remote xTR retransmits best priority locator exists, the Map-Request slowly until it gets a
       Map-Reply while continuing ITR can decide how to use load
   share traffic against the cached mapping.

   4. corresponding locators.

   The ETRs at the site with the changed mapping will reply following hash algorithm may be used by an ITR to select a
   locator for a packet destined to an EID for the
       Map-Request with EID-to-RLOC mapping:

   1.  Either a Map-Reply message provided source and destination address hash can be used or the Map-Request
       nonce matches
       traditional 5-tuple hash which includes the nonce from source and
       destination addresses, source and destination TCP, UDP, or SCTP
       port numbers and the SMR.  The Map-Reply messages
       SHOULD be rate limited.  This IP protocol number field or IPv6 next-
       protocol fields of a packet a host originates from within a LISP
       site.  When a packet is important to avoid Map-Reply
       implosion.

   5.  The ETRs, at the site with not a TCP, UDP, or SCTP packet, the changed mapping, records
       source and destination addresses only from the fact
       that header are used to
       compute the site that sent hash.

   2.  Take the Map-Request has received hash value and divide it by the new
       mapping data number of locators
       stored in the mapping cache entry locator-set for the remote site so
       the loc-status-bits are reflective EID-to-RLOC mapping.

   3.  The remainder will be yield a value of 0 to "number of locators
       minus 1".  Use the new mapping for packets
       going remainder to select the remote site.  The ETR then stops sending SMR
       messages.

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

   To avoid map-cache entry corruption by a third-party,
       locator-set.

   Note that when 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 packet is more secure to reach an authoritative ETR,
   it will deliver the Map-Request to LISP encapsulated, the authoritative source of port number
   in the
   mapping data.

7.  Router Performance Considerations

   LISP is designed outer UDP header needs 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 set.  Selecting a random value
   allows core routers which are required,
   they should be limited to re-programming existing hardware rather
   than requiring expensive design changes attached to hard-coded algorithms in
   silicon.

   A few implementation techniques can be used Link Aggregation Groups
   (LAGs) to incrementally
   implement LISP:

   o  When a tunnel encapsulated packet is received by an ETR, the outer
      destination address may not be 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 router.  This
      makes it challenging ITR, for the control plane to get packets from the
      hardware.  This may be mitigated which are
   originated by creating special FIB entries
      for the EID-prefixes of different EIDs served by at the ETR (those source site.  A suggested setting
   for which the router provides source port number computed by an RLOC translation).  These FIB entries are
      marked with ITR is a flag indicating that control plane processing should
      be performed. 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 forwarding logic 5-tuple hash
   includes the source and destination addresses of testing for particular IP the packet and the
   source and destination ports when the protocol number value in the packet
   is not necessary.  No changes to existing,
      deployed hardware should be needed 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 support this.

   o  On retrieve and
   store EID-to-RLOC mappings, the only way an ITR, prepending ITR can get a new IP header is as simple as adding more
      bytes up-to-
   date mapping is to a MAC rewrite string re-request the mapping.  However, the ITRs do not
   know when the mappings change and prepending the string as part 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 outgoing encapsulation procedure.  Many routers sites that support
      GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already
      support this action.

   o are currently communicating with
   the ETR site using such mappings.

   When a received packet's outer destination address contains an EID
      which locator record is not intended added to be forwarded on the routable topology
      (i.e.  LISP 1.5), the source address end of a data packet or the
      router interface with which the source locator-set, it 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
   easy to find EID-to-RLOC update mappings.

8.  Deployment Scenarios

   This section will explore how and where ITRs and ETRs can be deployed
   and  We assume new mappings will discuss maintain the pros and cons of each deployment scenario.
   There are two basic deployment trade-offs
   same locator ordering as the old mapping but just have new locators
   appended 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 end of the tunnel routers spread out so 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 caches are spread
      across all loc-status-bits that correspond to locators beyond 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 list it
   has cached, it simply ignores them.

   When a locator record is removed from a locator-set, ITRs doesn't increase management load,
      since caches are built and stored dynamically.  On that have
   the other hand,
      more ETRs does require more management since EID-prefix-to-RLOC
      mappings need mapping cached will not use the removed locator because the xTRs
   will set the loc-status-bit to be explicitly configured.

   When deciding on flat, recursive, or re-encapsulation tunneling, 0.  So even if 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 locator 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
   list, it is prepending a will not be used.  For new tunnel header, but if the site's
      ISP is doing the TE, then mapping requests, the site has no control.  Recursive
      tunneling generally will result in suboptimal paths but at xTRs can
   set the
      benefit of steering traffic locator address to resource available parts of 0 as well as setting the
      network.

   o  The technique of re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs corresponding
   loc-status-bit to be rerouted,
      it is first decapsulated by the ETR and then re-encapsulated 0.  This forces ITRs with
      a old or new tunnel header mappings to
   avoid using the removed locator.

   If many changes occur to a new RLOC.

   The next sub-sections mapping over a long period of time, one
   will describe where tunnel routers can reside find empty record slots in the network.

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close middle of the locator-set and new
   records appended to hosts, the EID-prefix set is at locator-set.  At some point, it would be
   useful to compact the granularity of an IP subnet.  So at locator-set so the expense of more EID-
   prefix-to-RLOC sets loc-status-bit settings can
   be efficiently packed.

   We propose here two approaches for locator-set compaction, one
   operational and the site, the caches in each tunnel router
   can remain relatively small.  But caches always depend on other a protocol mechanism.  The operational
   approach uses a clock sweep method.  The protocol approach uses the number
   concept of non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the increase Solicit-Map-Requests.

6.5.1.  Clock Sweep

   The clock sweep approach uses planning in control
   traffic grows as well: since advance and the EID-granularity 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 greater, more
   Map-Requests and Map-Replies are traveling between more routers. 24 hours.  So
   there is a 24 hour window to time out old mappings.  The advantage of placing following
   clock sweep procedure is used:

   1.  24 hours before a mapping change is to take effect, a network
       administrator configures the caches and databases ETRs at these stub
   routers is that a site to start the products deployed in this part of clock
       sweep window.

   2.  During the network
   have better price-memory ratios then their core router counterparts.
   Memory is typically less expensive in clock sweep window, ETRs continue to send Map-Reply
       messages with the current (unchanged) mapping records.  The TTL
       for these devices and fewer routes
   are stored (only IGP routes).  These devices tend mappings is set to 1 hour.

   3.  24 hours later, all previous cache entries will have excess
   capacity, both for forwarding timed out,
       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 any active cache entries will time out within 1 hour.  During
       this 1 hour window 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 ETRs continue to send Map-Reply messages
       with the EID
   space associated current (unchanged) mapping records with a site to be reachable via a small the TTL set of RLOCs
   assigned to
       1 minute.

   4.  At the CE routers for that site.

   This offers the opposite benefit end of the first-hop/last-hop tunnel
   router scenario: 1 hour window, the number of ETRs will send Map-Reply
       messages with the new (changed) mapping entries and network management
   touch points are reduced, allowing better scaling.

   One disadvantage 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 that less of a selective way for xTRs, at the network's resources site
   where mappings change, to control the rate they receive requests for
   Map-Reply messages.  SMRs are also used to
   reach host endpoints thereby centralizing tell remote ITRs to update
   the point-of-failure domain
   and creating network choke points at mappings they have cached.

   Since the CE router.

   Note xTRs don't keep track of remote ITRs that more than one CE router at a site have cached their
   mappings, they can be configured with not tell exactly who needs the same IP address.  In this case an RLOC is new mapping
   entries.  So 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 xTR will solicit Map-Requests from sites it is advertised out
   currently sending encapsulated data to, and only 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 those sites.
   The xTRs can locally decide if the tunnel endpoints are algorithm for how often and to how
   many sites it sends SMR messages.

   An SMR message is simply a bit set in the destination site (in
   either CE routers or last-hop routers within a site) Map-Request message.  An ITR
   or at other PE
   edges. PTR will send a Map-Request when they receive an SMR message.
   Both the SMR sender and the Map-Request responder must rate-limited
   these messages.

   The advantage of this case following procedure shows how a SMR exchange occurs when a site
   is that two or more tunnel headers
   can be avoided.  By having doing locator-set compaction for an EID-to-RLOC mapping:

   1.  When the PE be database mappings in an ETR change, the first router on ETRs at the path site
       begin to
   encapsulate, it can choose a TE path first, and send Map-Requests with the ETR can
   decapsulate and re-encapsulate SMR bit set for a tunnel to each locator
       in each map-cache entry the destination end
   site.

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

   2.  A remote xTR which receives the RLOCs used.

   As mentioned in earlier sections SMR message will schedule sending
       a combination of these scenarios is
   possible at Map-Request message to the expense source locator address of extra packet header overhead, if both site the SMR
       message.  A newly allocated random nonce is selected 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 the EID-
       prefix uses is highly desirable for it
   to see the entire path.  Since packets are encapsulated one copied from ITR to
   ETR, the hop across SMR message.

   3.  The remote xTR retransmits the tunnel could be viewed as Map-Request slowly until it gets a single hop.
   However, LISP traceroute
       Map-Reply while continuing to use the cached mapping.

   4.  The ETRs at the site with the changed mapping will provide reply to the entire path so
       Map-Request with a Map-Reply message provided the user can
   see 3 distinct segments of Map-Request
       nonce matches the path nonce from a source LISP host the SMR.  The Map-Reply messages
       SHOULD be rate limited.  This is important to a
   destination LISP host:

      Segment 1 (in source LISP avoid Map-Reply
       implosion.

   5.  The ETRs, at the site based on EIDs):

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

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

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

      Segment 3 (in changed mapping, records the fact
       that the destination LISP site based on EIDs):

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

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

   For segment 2 loc-status-bits are reflective of the path, ICMP Time Exceeded messages are returned new mapping for packets
       going to the remote site.  The ETR then stops sending SMR
       messages.

   For security reasons an ITR because MUST NOT process unsolicited Map-Replies.
   The nonce MUST be carried from SMR packet, into the TTL decrement resultant Map-
   Request, and then into Map-Reply to 0 is done on the outer
   header, so the destination reduce spoofing attacks.

   To avoid map-cache entry corruption by a third-party, a sender of the ICMP messages are to the an
   SMR-based Map-Request must be verified.  If an ITR RLOC
   address, receives an SMR-
   based Map-Request and the source source RLOC address of is not in the encapsulated
   traceroute packet.  The ITR looks inside of locator-set for the ICMP payload
   stored map-cache entry, then the responding Map-Request MUST be sent
   with an EID destination to
   inspect the traceroute source so mapping database system.  Since the
   mapping database system is more secure to reach an authoritative ETR,
   it can return will deliver the ICMP message Map-Request to the address authoritative source of the traceroute client as well as retaining the core
   router IP address in the ICMP message.  This
   mapping data.

7.  Router Performance Considerations

   LISP is so the traceroute
   client designed to be very hardware-based forwarding friendly.  By
   doing tunnel header prepending [RFC1955] and stripping instead of re-
   writing addresses, existing hardware can display the core router address (the RLOC address) in support the
   traceroute output.  The ETR returns its RLOC address and responds forwarding model
   with little or no modification.  Where modifications are required,
   they should be limited to
   the TTL decrement re-programming existing hardware rather
   than requiring expensive design changes to 0 like the previous core routers did.

   For segment 3, the next-hop router downstream from the ETR will hard-coded algorithms in
   silicon.

   A few implementation techniques can be
   decrementing the TTL for the used to incrementally
   implement LISP:

   o  When a tunnel encapsulated packet that was encapsulated, sent into
   the core, decapsulated is received by the an ETR, and forwarded because it isn't the
   final destination.  If the TTL is decremented to 0, any router on the
   path to the outer
      destination address may not be the address of the traceroute, including router.  This
      makes it challenging for the next-hop
   router or destination, will send an ICMP Time Exceeded message control plane to get packets from the
   source EID of the traceroute client.  The ICMP message will
      hardware.  This may be
   encapsulated mitigated by creating special FIB entries
      for the local ITR and sent back to EID-prefixes of EIDs served by the ETR in the
   originated traceroute source site, where (those for which
      the packet will router provides an RLOC translation).  These FIB entries are
      marked with a flag indicating that control plane processing should
      be delivered
   to the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire traceroute data packet performed.  The forwarding logic of testing for particular IP
      protocol number value is included in ICMP Time Exceeded
   message payload.  Therefore, only the ITR needs not necessary.  No changes to pay special
   attention for forwarding ICMP messages back existing,
      deployed hardware should be needed 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 support this.

   o  On an ITR, prepending a new IP header and 8 is as simple as adding more
      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, MAC rewrite string and therefore prepending the identity string as part of
      the traceroute source is lost.

   The solution we propose to solve outgoing encapsulation procedure.  Many routers that support
      GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already
      support this problem action.

   o  When a received packet's outer destination address contains an EID
      which is not intended to cache traceroute
   IPv4 headers in the ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and be forwarded on the ETR.  The
   ITR will use a circular buffer for caching routable topology
      (i.e.  LISP 1.5), the IPv4 and UDP headers source address of traceroute packets.  It will select a 16-bit number as a key to
   find them later when data packet or the IPv4 Time Exceeded messages are received.
   When an ITR encapsulates an IPv4 traceroute packet, it will use the
   16-bit number as
      router interface with which 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 associated (the
      interface from which it was received) can be associated with a VRF
      (Virtual Routing/Forwarding), in the ICMP payload
   thereby allowing the ITR which a different (i.e. non-
      congruent) topology can be used to find the cached headers for the
   traceroute source.  The ITR puts the cached headers in the payload EID-to-RLOC mappings.

8.  Deployment Scenarios

   This section will explore how and sends the ICMP Time Exceeded message to the traceroute source
   retaining where ITRs and ETRs can be deployed
   and will discuss the source address pros and cons of the original ICMP Time Exceeded
   message (a core router each deployment scenario.
   There are two basic deployment trade-offs to consider: centralized
   versus distributed caches and flat, recursive, or the ETR of the site of the traceroute
   destination).

9.3.  Traceroute using Mixed Locators re-encapsulating
   tunneling.

   When either an IPv4 traceroute or IPv6 traceroute is originated and deciding on centralized versus distributed caching, the ITR encapsulates it in
   following issues should be considered:

   o  Are the other address family header, you
   cannot get tunnel routers spread out so that the caches are spread
      across all 3 segments of the traceroute.  Segment 2 memories of the
   traceroute can not each router?

   o  Should management "touch points" be conveyed to the traceroute source since it is
   expecting addresses from intermediate hops in the same address format 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 type of traceroute it originated.  Therefore, in this case,
   segment 2 will make 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 look like one hop.  All the ITR has to
   do to make this work 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 not copy the inner TTL implement VPNs or to
      perform Traffic Engineering.  When doing VPN-based tunneling, the outer,
   encapsulating header's TTL when
      site has some control since the site is prepending a traceroute packet new tunnel
      header.  In the case of TE-based tunneling, the site may have
      control if it is encapsulated
   using an RLOC from prepending a different address family.  This will cause new tunnel header, but if the site's
      ISP is doing the TE, then the site has no
   TTL decrement to 0 to occur control.  Recursive
      tunneling generally will result in core routers between suboptimal paths but at the ITR and ETR.

10.  Mobility Considerations

   There are several kinds
      benefit of mobility steering traffic to resource available parts of which only some might be the
      network.

   o  The technique of
   concern to LISP.  Essentially they are as follows.

10.1.  Site Mobility

   A site wishes to change its attachment points re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs to be rerouted,
      it is first decapsulated by the Internet, ETR and
   its LISP Tunnel Routers will have then re-encapsulated with
      a new RLOCs when it changes upstream
   providers.  Changes tunnel header using a new RLOC.

   The next sub-sections will describe where tunnel routers can reside
   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 network.

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close to move, but is not concerned about
   maintaining session continuity.  Renumbering hosts, the EID-prefix set is involved.  LISP can
   help with at
   the issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling granularity of an IP subnet.  So at the address space used by a site from expense of more EID-
   prefix-to-RLOC sets for the address spaces
   used by its ISPs.  [RFC4984]

10.3.  Fast Endpoint Mobility

   Fast endpoint mobility occurs when an endpoint moves site, the caches in each tunnel router
   can remain relatively
   rapidly, changing its IP layer network attachment point.  Maintenance small.  But caches always depend on the number
   of session continuity is a goal.  This is where non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the Mobile IPv4
   [RFC3344bis] increase in control
   traffic grows as well: since the EID-granularity is greater, more
   Map-Requests and Mobile IPv6 [RFC3775] [RFC4866] mechanisms Map-Replies are used,
   and primarily where interactions with LISP need to be explored. traveling between more routers.

   The problem advantage of placing the caches and databases at these stub
   routers 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 products deployed in this is added to the overhead part of mobile IP binding
   updates, some packets might be delayed or dropped.

   In IPv4 mobility, when an endpoint the network
   have better price-memory ratios then their core router counterparts.
   Memory is away from home, packets to it typically less expensive in these devices and fewer routes
   are encapsulated stored (only IGP routes).  These devices tend to have excess
   capacity, both for forwarding and forwarded via a home agent which resides routing state.

   LISP functionality can also be deployed in the
   home area the endpoint's address belongs to.  The home agent will
   encapsulate edge switches.  These
   devices generally have layer-2 ports facing hosts and forward packets either directly to the endpoint or to
   a foreign agent which resides where layer-3 ports
   facing the endpoint has moved to.
   Packets from 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 endpoint may be sent directly EID
   space associated with a site to the correspondent
   node, may be sent reachable via the foreign agent, or may be reverse-tunneled
   back a small set of RLOCs
   assigned to the home agent CE routers for delivery to that site.

   This offers the mobile node.  As opposite benefit of the
   mobile node's EID or available RLOC changes, LISP EID-to-RLOC
   mappings are required for communication between first-hop/last-hop tunnel
   router scenario: the mobile node number of mapping entries 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 management
   touch points are reduced, allowing better scaling.

   One disadvantage is that it has done so.
      The Mobile IPv4 control packets the mobile node sends pass through
      one less 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 resources are sent directly used to
   reach host endpoints thereby centralizing the correspondent node, it may
      be that no traffic has been sent from the new visited point-of-failure domain
   and creating network to choke points at the correspondent node's network, and CE router.

   Note that more than one CE router at a site can be configured with
   the new visited network's
      ITR will need to obtain same IP address.  In this case an EID-RLOC mapping for RLOC is an anycast address.
   This allows resilience between the correspondent
      node's site.

   In addition, CE routers.  That is, if the IPv4 endpoint a CE
   router fails, traffic is sending packets from automatically routed to the new
   visited network other routers
   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 same anycast address.  However, this comes with the mobile node
   and
   disadvantage where the correspondent node 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 direction. CE routers or last-hop routers within a site) or at other PE
   edges.  The mobile node uses
   its "care-of" address (EID).  In advantage of this case, the route-returnability
   check would not be needed but one case is that two or more LISP mapping lookup may tunnel headers
   can be
   required instead:

   o  As above, three mapping changes may avoided.  By having the PE be needed for the mobile node first router on the path to communicate with its home agent
   encapsulate, it can choose a TE path first, and to send packets to the
      correspondent node.

   o  In addition, another mapping will be needed in the correspondent
      node's ITR, in order ETR can
   decapsulate and re-encapsulate for the correspondent node to send packets a tunnel to the mobile node's "care-of" address (EID) at destination end
   site.

   An obvious disadvantage is that the new network
      location.

   When both endpoints are mobile end site has no control over
   where its packets flow or the number of potential mapping
   lookups increases accordingly. RLOCs used.

   As a mobile node moves there are not only mobility state changes mentioned in earlier sections a combination of these scenarios is
   possible at the mobile node, correspondent node, expense of extra packet header overhead, if both site
   and home agent, but also state
   changes provider want control, then recursive or re-encapsulating tunnels
   are used.

9.  Traceroute Considerations

   When a source host in the ITRs and ETRs for at least some EID-prefixes.

   The goal is a LISP site initiates a traceroute to support rapid adaptation, with little delay or packet
   loss a
   destination host in another LISP site, it is highly desirable for it
   to see the entire system.  Heuristics can be added to LISP path.  Since packets are encapsulated from ITR to
   reduce
   ETR, the number of mapping changes required and to reduce hop across 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 tunnel could be viewed as 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, single hop.
   However, LISP traceroute will provide the ETR could examine entire path so the EID-RLOC mapping and use that
   mapping for all outgoing traffic to that EID.  It user can do this after
   performing a route-returnability check, to ensure that
   see 3 distinct segments of the new
   network location does have path from a internal route source LISP host to that endpoint.
   However, this does not cover the case where an a
   destination LISP host:

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

          source-host ---> first-hop ... next-hop ---> ITR (the node assigned

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

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

      Segment 3 (in the mobile-node location has been compromised.

   Mobile IP packet exchange is designed for an environment 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 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 normal matter as they are moving to 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 environment where some information may have
   to be obtained after packets EID address (the address of
   site-facing interface).

   For segment 2 of the path, ICMP Time Exceeded messages are in flight.  Modifications returned
   to IP
   mobility should be considered in order the ITR because the TTL decrement to optimize 0 is done on the behavior outer
   header, so the destination of the overall system.  Anything which decreases ICMP messages are to the number of new EID- ITR RLOC mappings needed when a node moves, or maintains
   address, the validity source source RLOC address of
   an EID-RLOC mapping for a longer time, is useful.

10.4.  Fast Network Mobility

   In addition the encapsulated
   traceroute packet.  The ITR looks inside of the ICMP payload to endpoints, a network can be mobile, possibly changing
   xTRs.  A "network"
   inspect the traceroute source so it can be return the ICMP message to
   the address of the traceroute client as small well as a single retaining the core
   router and as large as
   a whole site. IP address in the ICMP message.  This is different from site mobility in that it is
   fast so the traceroute
   client can display the core router address (the RLOC address) in the
   traceroute output.  The ETR returns its RLOC address and possibly short-lived, but different responds to
   the TTL decrement to 0 like the previous core routers did.

   For segment 3, the next-hop router downstream from endpoint mobility
   in the ETR will be
   decrementing the TTL for the packet that a whole prefix is changing RLOCs.  However, was encapsulated, sent into
   the mechanisms
   are core, decapsulated by the same ETR, and there forwarded because it isn't the
   final destination.  If the TTL is no new overhead in LISP.  A map request for decremented to 0, any endpoint will return a binding for router on the entire mobile prefix.

   If mobile networks become a more common occurrence, it may be useful
   path to revisit the design destination of the mapping service and allow for dynamic
   updates traceroute, including the next-hop
   router or destination, will send an ICMP Time Exceeded message to the
   source EID of the database. traceroute client.  The issue of interactions between mobility ICMP message will be
   encapsulated by the local ITR and LISP needs sent back to the ETR in the
   originated traceroute source site, where the packet will be
   explored further.  Specific improvements delivered
   to the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire system will
   depend on traceroute data packet is included in ICMP Time Exceeded
   message payload.  Therefore, only the details of mapping mechanisms.  Mapping mechanisms
   should be evaluated on how well they support session continuity ITR needs to pay special
   attention for
   mobile nodes.

10.5.  LISP Mobile Node Mobility

   An mobile device can use the LISP infrastructure forwarding ICMP messages back 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 traceroute source.

9.2.  IPv4 Traceroute

   For IPv4 traceroute, we cannot follow the mapping system
   (in LISP Map-Servers and Map-Resolvers) and are provided on demand to above procedure since IPv4
   ICMP Time Exceeded messages only include the correspondents of invoking IP header and 8
   bytes that follow the LISP mobile node.

   Refer IP header.  Therefore, when a core router sends
   an IPv4 Time Exceeded message to an ITR, all the LISP Mobility Architecture specification [LISP-MN] for
   more details.

11.  Multicast Considerations

   A multicast group address, as defined ITR has in the original Internet
   architecture ICMP
   payload is an identifier of the encapsulated header it prepended followed by a grouping of topologically
   independent receiver host locations. UDP
   header.  The address encoding itself
   does not determine original invoking IP header, and therefore the location identity
   of the receiver(s). traceroute source is lost.

   The multicast
   routing protocol, and the network-based state solution we propose to solve this problem is to cache traceroute
   IPv4 headers in the protocol creates,
   determines where ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and the receivers are located.

   In ETR.  The
   ITR will use a circular buffer for caching the context IPv4 and UDP headers
   of LISP, traceroute packets.  It will select a multicast group address is both an EID and 16-bit number as a Routing Locator.  Therefore, no specific semantic or action needs key to be taken for a destination address, as it would appear in
   find them later when the IPv4 Time Exceeded messages are received.
   When an IP
   header.  Therefore, a group address that appears in ITR encapsulates 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, IPv4 traceroute packet, it will use the same group address
   16-bit number as the
   destination Routing Locator.

   Having said that, only the source EID and UDP source Routing Locator
   needs to be dealt with.  Therefore, an ITR merely needs to put its
   own IP address port in the source Routing Locator field when prepending
   the outer IP encapsulating 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
   When the multicast routing protocol
   in a receiver site.  That is, an EID to Routing Locator translation
   is done at control-time.

   Another approach ICMP Time Exceeded message is returned to have the ITR not encapsulate a multicast
   packet and allow ITR, the UDP
   header of the host built packet encapsulating header is present in the ICMP payload
   thereby allowing the ITR to flow into find the core even
   if cached headers for the source address is allocated out of the EID namespace.  If
   traceroute source.  The ITR puts the
   RPF-Vector TLV [RPFV] is used by PIM cached headers in the core, then core routers
   can RPF payload
   and sends the ICMP Time Exceeded message to the ITR (the Locator address which is injected into core
   routing) rather than traceroute source
   retaining the host source address (the EID address which
   is not injected into of the original ICMP Time Exceeded
   message (a core routing).

   To avoid any EID-based multicast state in router or the network core, ETR of the first
   approach site of the traceroute
   destination).

9.3.  Traceroute using Mixed Locators

   When either an IPv4 traceroute or IPv6 traceroute is chosen for LISP-Multicast.  Details for LISP-Multicast originated and Interworking with non-LISP sites is described
   the ITR encapsulates it in specification
   [MLISP].

12.  Security Considerations

   It is believed that most the other address family header, you
   cannot get all 3 segments of the security mechanisms will be part traceroute.  Segment 2 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
   traceroute can not be conveyed to the
   use of a 24-bit Nonce field traceroute source since it is
   expecting addresses from intermediate hops in the LISP encapsulation header and a
   64-bit Nonce field same address format
   for the type of traceroute it originated.  Therefore, in this case,
   segment 2 will make the LISP control message.  The nonce, coupled
   with tunnel look like one hop.  All the ITR accepting only solicited Map-Replies goes a long way
   toward providing decent authentication.

   LISP does has to
   do to make this work is to not rely on copy the inner TTL to the outer,
   encapsulating header's TTL when a PKI infrastructure or traceroute packet is encapsulated
   using an RLOC from a more heavy weight
   authentication system.  These systems challenge different address family.  This will cause no
   TTL decrement to 0 to occur in core routers between the scalability ITR and ETR.

10.  Mobility Considerations

   There are several kinds of mobility of
   LISP which was a primary design goal.

   DoS attack prevention will depend on implementations rate-limiting
   Map-Requests and Map-Replies only some might be of
   concern to the control plane as well LISP.  Essentially they are as rate-
   limiting follows.

10.1.  Site Mobility

   A site wishes to change its attachment points to the number of data-triggered Map-Replies.

   To deal with map-cache exhaustion attempts Internet, and
   its LISP Tunnel Routers will have new RLOCs when it changes upstream
   providers.  Changes in an ITR/PTR, the
   implementation should consider putting a maximum cap on the number of
   entries stored with a reserve list EID-RLOC mappings for special or frequently accessed
   sites.  This should sites are expected to be a configuration policy control set
   handled by configuration, outside of the
   network administrator who manages ITRs and PTRs.

13.  Prototype Plans and Status

   The operator community has requested that 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 IETF take issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling the address space used by a practical
   approach to solving site from the scaling problems associated with global
   routing state growth.  This document offers a simple solution which 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 intended for use in a pilot program goal.  This is where the Mobile IPv4
   [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used,
   and primarily where interactions with LISP need to gain experience in working
   on this problem. be explored.

   The authors hope problem is that publishing this specification will allow as an endpoint moves, it may require changes to
   the
   rapid implementation of multiple vendor prototypes mapping between its EID and deployment on
   a small scale.  Doing this will help the community:

   o  Decide whether a set of RLOCs for its new EID-to-RLOC mapping database infrastructure network
   location.  When this is needed added to the overhead of mobile IP binding
   updates, some packets might be delayed or if a simple, UDP-based, data-triggered approach dropped.

   In IPv4 mobility, when an endpoint is
      flexible away from home, packets to it
   are encapsulated and robust enough.

   o  Experiment with provider-independent assignment of EIDs while at forwarded via a home agent which resides in the same time decreasing
   home area the size of DFZ routing tables through endpoint's address belongs to.  The home agent will
   encapsulate and forward packets either directly to the use of topologically-aligned, provider-based RLOCs.

   o  Determine whether multiple levels of tunneling can be used by ISPs endpoint or to achieve their Traffic Engineering goals while simultaneously
      removing
   a foreign agent which resides where the more specific routes currently injected into endpoint has moved to.
   Packets from the
      global routing system for this purpose.

   o  Experiment with mobility endpoint may be sent directly to determine if both acceptable
      convergence and session continuity properties can the correspondent
   node, may be scalably
      implemented sent via the foreign agent, or may be reverse-tunneled
   back to support both individual device roaming and site
      service provider changes.

   Here is a rough set of milestones:

   1.  Interoperable implementations have been available since the
       beginning of 2009.  We are trying home agent for delivery to converge on a packet format
       so implementations can converge on the -04 and later drafts.

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

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

   4.  Implement the available RLOC changes, LISP Multicast draft [MLISP].

   5.  Implement EID-to-RLOC
   mappings are required for communication between the LISP Mobile Node draft [LISP-MN].

   6.  Research more on how policy affects what gets returned in mobile node and
   the home agent, whether via foreign agent or not.  As a Map-
       Reply mobile
   endpoint changes networks, up to three LISP mapping changes may be
   required:

   o  The mobile node moves from an ETR.

   7.  Continue to experiment with mixed locator-sets old location to understand how
       LISP can help the a new visited
      network location and notifies its home agent that it has done so.
      The Mobile IPv4 to IPv6 transition.

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

   As control packets the mobile node sends pass through
      one 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 new visited network's ITRs, which needs a EID-RLOC
      mapping for this draft the home agent.

   o  The home agent might not have the EID-RLOC mappings 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 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 completed for draft [ALT].

   3.   A unit- sent from the new visited network to
      the correspondent node's network, and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [INTERWORK].  Support 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 translation endpoint is provided and PTR support 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 IPv4 and
   that EID.

   In 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 mobility, packets can flow directly between the features described above
        on a dual-stack infrastructure.

   6.   Darrel Lewis and Dave Meyer have deployed both LISP translation mobile node
   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 correspondent node in a LISP site.

   7.   Soon http://www.lisp6.net will work where your IPv6 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 site
        can talk mapping lookup may be
   required instead:

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

   o  In addition, another mapping will be needed in a LISP site by using mixed
        address-family based locators.

   8.   An public domain implementation of LISP is underway.  See
        [OPENLISP] the correspondent
      node's ITR, in order for details.

   9.   We have deployed Map-Resolvers and Map-Servers on the LISP pilot
        network correspondent node to send packets to gather experience with [LISP-MS].  The first layer of
      the architecture mobile node's "care-of" address (EID) at the new network
      location.

   When both endpoints are mobile the xTRs which use Map-Servers for EID-
        prefix registration and Map-Resolvers for EID-to-RLOC number of potential mapping
        resolution.  The second layer
   lookups increases accordingly.

   As a mobile node moves there are not only mobility state changes in
   the Map-Resolvers mobile node, correspondent node, and Map-
        Servers which connect to the ALT BGP peering infrastructure.
        And home agent, but also state
   changes in the third layer are ALT-routers which aggregate EID-prefixes ITRs and forward Map-Requests.

   10.  A cisco IOS implementation ETRs for at least some EID-prefixes.

   The goal 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 support rapid adaptation, with little delay or packet
   loss for the entire system.  Heuristics can be added to LISP pilot network.  See
        [LIG] for details.

   12.  A Linux implementation to
   reduce the number of LIG has been made available mapping changes required and
        supported by Dave Meyer.  It to reduce the delay
   per mapping change.  Also IP mobility can be run on any Linux modified to require
   fewer mapping changes.  In order to increase overall system
        which resides
   performance, there may be a need to reduce the optimization of one
   area in either order to place fewer demands on another.

   In LISP, one possibility is to "glean" information.  When a LISP site or non-LISP site.  See [LIG] packet
   arrives, the ETR could examine the EID-RLOC mapping and use that
   mapping for details.  Public domain code all outgoing traffic to that EID.  It can be downloaded from
        http://github.com/davidmeyer/lig/tree/master.

   13.  An experimental implementation 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 written compromised.

   Mobile IP packet exchange is designed for three
        locator reachability algorithms.  Two are the Echo-Noncing and
        RLOC-Probing algorithms which are documented an environment in this
        specification.  The third is called TCP-counts which will all
   routing information is disseminated before packets can be
        documented in forwarded.
   In order to allow the Internet to grow to support expected future drafts.

   14.  The LISP pilot network has been converted from using MD5 HMAC
        authentication
   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 Map-Register messages a longer time, is useful.

10.4.  Fast Network Mobility

   In addition to SHA-1 HMAC
        authentication.  ETRs send with SHA-1 but Map-Servers endpoints, a network can
        received 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 either for compatibility purposes.

   If interested site mobility in writing that it is
   fast and possibly short-lived, but different from endpoint mobility
   in that a LISP implementation, testing whole prefix is changing RLOCs.  However, the mechanisms
   are the same and there is no new overhead in LISP.  A map request for
   any of endpoint will return a binding for the
   LISP implementations, or want to entire mobile prefix.

   If mobile networks become a more common occurrence, it may be part useful
   to revisit the design 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. mapping service and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1498]  Saltzer, J., "On allow for dynamic
   updates of the Naming and Binding database.

   The issue of Network
              Destinations", RFC 1498, August 1993.

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

   [RFC2119]  Bradner, S., "Key words 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 in RFCs the LISP infrastructure to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. achieve mobility
   by implementing the LISP encapsulation 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., decapsulation functions
   and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3056]  Carpenter, B. 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 K. Moore, "Connection do not impose a cost on the global routing
   system.  These EIDs are maintained at the edges of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., the mapping system
   (in LISP Map-Servers and D. Black, "The Addition Map-Resolvers) and are provided on demand to
   only the correspondents of Explicit Congestion Notification (ECN) the LISP mobile node.

   Refer to IP",
              RFC 3168, September 2001.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 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 24-bit Nonce field in the LISP encapsulation header and a
   64-bit Nonce field in the LISP control message.  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.  Interoperable implementations have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   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.  Two are the Echo-Noncing and
        RLOC-Probing algorithms which are documented in this
        specification.  The third is called TCP-counts 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.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, 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.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

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

   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 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.

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

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), February
              May 2009.

14.2.  Informative References

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

   [ALT]

   [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, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-01.txt
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt (work in progress), May
              March 2009.

   [APT]      Jen,

   [LISP-MN]  Farinacci, D., Meisel, M., Massey, Fuller, V., Lewis, D., Wang, L., Zhang, B., and
              L. Zhang, "APT: A Practical Transit Mapping Service",
              draft-jen-apt-01.txt D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
              in progress), November 2007.

   [CHIAPPA]  Chiappa, J., "Endpoints July 2009.

   [LISP-MS]  Farinacci, D. and Endpoint names: A Proposed
              Enhancement to the Internet Architecture", Internet-
              Draft http://www.chiappa.net/~jnc/tech/endpoints.txt,
              1999.

   [CONS] V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-02.txt (work in progress),
              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, "LISP-CONS: A
              Content distribution Overlay Network  Service D., Zwiebel, J., and S. Venaas,
              "LISP for LISP",
              draft-meyer-lisp-cons-03.txt 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),
              November 2007.

   [DHTs]     Ratnasamy, S., Shenker, S., and I. Stoica, July 2008.

   [RADIR]    Narten, T., "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 Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress),
              November July 2007.

   [GSE]      "GSE - An Alternate Addressing Architecture

   [RFC3344bis]
              Perkins, C., "IP Mobility Support for  IPv6",
              draft-ietf-ipngwg-gseaddr-00.txt IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work in progress), 1997.

   [INTERWORK]
              Lewis, D., Meyer, D., Farinacci, D.,
              July 2007.

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

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

   [LIG]      Farinacci, D.

   [RPMD]     Handley, M., Huici, F., and D. Meyer, "LISP Internet Groper (LIG)",
              draft-farinacci-lisp-lig-01.txt A. Greenhalgh, "RPMD: Protocol
              for Routing Protocol Meta-data  Dissemination",
              draft-handley-p2ppush-unpublished-2007726.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., July 2007.

   [SHIM6]    Nordmark, E. and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt M. Bagnulo, "Level 3 multihoming shim
              protocol", draft-ietf-shim6-proto-06.txt (work in
              progress),
              March 2009.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., October 2006.

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 D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
              in progress), July 2009.

   [LISP-MS]  Farinacci, D. identity, as well as detailed review of the LISP
   architecture and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-02.txt (work in progress),
              September 2009.

   [LISP1]    Farinacci, D., Oran, D., Fuller, V., documents, coupled with enthusiasm for making LISP a
   practical 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., incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and J. ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
              "Locator/ID Separation Protocol (LISP2) [DNS-based
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt,
              November 2006.

   [LISPDHT]  Mathy, L.,
   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, L., 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, and O. Bonaventure, "LISP-DHT:
              Towards a DHT Jari
   Arkko.

   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.

Appendix B.  Document Change Log

B.1.  Changes to map identifiers onto locators",
              draft-mathy-lisp-dht-00.txt (work draft-ietf-lisp-05.txt

   o  Posted October 2009.

   o  Added this Document Change Log appendix.

   o  Added section indicating that encapsulated Map-Requests must use
      destination UDP port 4342.

   o  Don't use AH in progress),
              February 2008.

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

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP Map-Register payload.

   o  Added Jari to acknowledgment section.

   o  State the source-EID is set to 0 when using Map-Requests to
      refresh or RLOC-probe.

   o  Make more clear what source-RLOC should be for Multicast Environments",
              draft-ietf-lisp-multicast-01.txt (work in progress),
              May 2009.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID a Map-Request.

   o  The LISP-CONS authors thought that the Type definitions for CONS
      should be removed from this specification.

   o  Removed nonce from Map-Register message, it wasn't used so no need
      for it.

   o  Clarify what to RLOC Database",
              draft-lear-lisp-nerd-04.txt (work in progress),
              April 2008.

   [OPENLISP]
              Iannone, L. do for unspecified Action bits for negative Map-
      Replies.  Since No Action is a drop, make value 0 Drop.

B.2.  Changes to draft-ietf-lisp-04.txt

   o  Posted September 2009.

   o  How do deal with record count greater than 1 for a Map-Request.
      Damien and O. Bonaventure, "OpenLISP Implementation
              Report", draft-iannone-openlisp-implementation-01.txt
              (work in progress), July 2008.

   [RADIR]    Narten, T., "Routing Joel comment.  Joel suggests: 1) Specify that senders
      compliant with the current document will always set the count to
      1, and Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress), July 2007.

   [RFC3344bis]
              Perkins, C., "IP Mobility Support note that the count is included for IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work 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?

   o  Add Fred Templin in progress),
              July 2007.

   [RFC4192]  Baker, F., Lear, E., ack section.

   o  Add Margaret and R. Droms, "Procedures Sam to the ack section for
              Renumbering their great comments.

   o  Say more about LAGs in the UDP section per Sam Hartman's comment.

   o  Sam wants to use MAY instead of SHOULD for ignoring checksums on
      ETR.  From the mailing list: "You'd need to word it as an IPv6 Network without ITR MAY
      send a Flag Day", RFC 4192,
              September 2005.

   [RPFV]     Wijnands, IJ., Boers, A., zero checksum, an ETR MUST accept a 0 checksum and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-08.txt (work 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."

   o  Margaret wants a reference to
      http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt.

   o  Fix description in progress),
              January 2009.

   [RPMD]     Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol Map-Request section.  Where we describe Map-
      Reply Record, change "R-bit" to "M-bit".

   o  Add the mobility bit to Map-Replies.  So PTRs don't probe so often
      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.

Appendix A.  Acknowledgments

   An initial thank you goes MNs but often enough to Dave Oran get mapping updates.

   o  Indicate SHA1 can be used as well for planting Map-Registers.

   o  More Fred comments on MTU handling.

   o  Isidor comment about specing better periodic Map-Registers.  Will
      be fixed in draft-ietf-lisp-ms-02.txt.

   o  Margaret's comment on gleaning: "The current specification does
      not make it clear how long gleaned map entries should be retained
      in the seeds 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
   initial ideas for LISP.  His consultation continues mapping system.  The security implications of storing
      "gleaned" entries should also be explored in detail."

   o  Add section on RLOC-probing per working group feedback.

   o  Change "loc-reach-bits" to provide value "loc-status-bits" per comment from
      Noel.

   o  Remove SMR-bit from data-plane.  Dino prefers to have it in the
      control plane only.

   o  Change LISP authors.

   A special and appreciative thank you goes header to Noel Chiappa for
   providing architectural impetus over allow a "Research Bit" so the past decades on separation
   of location Nonce and identity, as well as detailed review of the LISP
   architecture LSB
      fields can be turned off and documents, coupled with enthusiasm used for making LISP another future purpose.  For
      Luigi et al versioning convergence.

   o  Add a
   practical and incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas N-bit 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, data header suggested by Noel.  Then the nonce
      field could be used when N is not 1.

   o  Clarify that when E-bit is 0, the nonce field can be an echoed
      nonce or a random nonce.  Comment from Jesper.

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

   o  Indicate that a verifying Map-Request, for accepting mapping data,
      should be sent over the the ALT (or to the EID).

   o  Reference IPsec RFC 4302.  Comment from Sam Hartman, Michael Hofling, and Brian Weis.

   o  Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
      noncing.  Comment by Pedro Marques.

   In particular, we would like and Dino.

   o  Jesper made a comment to thank Dave Meyer for his clever
   suggestion for loosen the name "LISP". ;-)

   This language about requiring the
      copy of inner TTL to outer TTL since the text to get mixed-AF
      traceroute to work originated would violate the "MUST" clause.  Changed from
      MUST to SHOULD in section 5.3.

B.3.  Changes to draft-ietf-lisp-03.txt

   o  Posted July 2009.

   o  Removed loc-reach-bits longword from control packets per Damien
      comment.

   o  Clarifications in MTU text from Roque.

   o  Added text to indicate that the Routing Research Group (RRG) locator-set be sorted by locator
      address from Isidor.

   o  Clarification text from JohnZ in Echo-Nonce section.

B.4.  Changes to draft-ietf-lisp-02.txt

   o  Posted July 2009.

   o  Encapsulation packet format change to add E-bit and make loc-
      reach-bits 32-bits in length.

   o  Added Echo-Nonce Algorithm section.

   o  Clarification how ECN bits are copied.

   o  Moved S-bit in Map-Request.

   o  Added P-bit in Map-Request and Map-Reply messages to anticipate
      RLOC-Probe Algorithm.

   o  Added to Mobility section to reference draft-meyer-lisp-mn-00.txt.

B.5.  Changes to draft-ietf-lisp-01.txt

   o  Posted 2 days after draft-ietf-lisp-00.txt in May 2009.

   o  Defined LEID to be a "LISP EID".

   o  Indicate encapsulation use IPv4 DF=0.

   o  Added negative Map-Reply messages with drop, native-forward, and
      send-map-request actions.

   o  Added Proxy-Map-Reply bit to Map-Register.

B.6.  Changes to draft-ietf-lisp-00.txt

   o  Posted May 2009.

   o  Rename of the IRTF.
   The individual submission [LISP-MAIN] was converted into this IETF
   LISP working group draft. draft-farinacci-lisp-12.txt.

   o  Acknowledgment to RRG.

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-6-938941840 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-6-938941840 Content-Disposition: attachment; filename=draft-ietf-lisp-05.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-05.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: March 31, 2010 D. Lewis cisco Systems September 27, 2009 Locator/ID Separation Protocol (LISP) (PROPOSED) draft-ietf-lisp-05.txt (NOT POSTED YET) 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 March 31, 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. Farinacci, et al. Expires March 31, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 . . . . . . . . . 22 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 . . . . . . . . . . . . . . . 30 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 33 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 34 6.1.7. Encapsualted Control Message Format . . . . . . . . . 35 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 37 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 38 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 41 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 42 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 43 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 43 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 44 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 45 7. Router Performance Considerations . . . . . . . . . . . . . . 47 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 48 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 49 Farinacci, et al. Expires March 31, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 49 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 50 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 51 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 52 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 52 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 52 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 54 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 54 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 54 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 54 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 56 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 56 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 58 12. Security Considerations . . . . . . . . . . . . . . . . . . . 59 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 60 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 14.1. Normative References . . . . . . . . . . . . . . . . . . . 63 14.2. Informative References . . . . . . . . . . . . . . . . . . 64 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 67 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 68 B.1. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 68 B.2. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 68 B.3. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 70 B.4. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 70 B.5. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 71 B.6. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 72 Farinacci, et al. Expires March 31, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 31, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 31, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 31, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 31, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 statically 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 prepends 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 statically configured. Farinacci, et al. Expires March 31, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 prepends 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 Farinacci, et al. Expires March 31, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 31, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | | Farinacci, et al. Expires March 31, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer 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 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 SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion. 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 Farinacci, et al. Expires March 31, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 headers are used. The UDP header length is 8 bytes. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See section Section 6.3.1 for details. L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. E: this is the echo-nonce-request bit. When this bit is set to 1, the N bit must be 1. 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. rflags: this 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 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. When the E-bit is clear but the N-bit is set, an ITR is either echoing a previously requested echo-nonce or providing a random nonce. See section Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least 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 outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Farinacci, et al. Expires March 31, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 Type of Service field (with one caveat, see below). When doing Re-encapsulated Tunneling: o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer 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. Farinacci, et al. Expires March 31, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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. Farinacci, et al. Expires March 31, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet with DF bit set to 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. Farinacci, et al. Expires March 31, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires March 31, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 | | + 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. Farinacci, et al. Expires March 31, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Encapsulated Control Message: 8 b'1000' 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=3D1 |A|M|P|S| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . 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: Farinacci, et al. Expires March 31, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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 Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. 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. When Map-Requests are used for refreshing a map-cache entry or for RLOC-probing, the value 0 is used. Originating ITR RLOC Address: Used to give the ETR the option of returning a Map-Reply in the address-family of this locator. Farinacci, et al. Expires March 31, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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. The source address is either an IPv4 or IPv6 RLOC address depending if the Map-Request is using an IPv4 versus IPv6 header, respectively. 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 4342 with a LISP type value set to "Encapsulated Control Message", 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]. Farinacci, et al. Expires March 31, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request, it may originate a "verifying Map-Request", addressed to the original ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map-Request" to the original Map-Request source. If not, then it MUST send it to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" mapping data. Farinacci, et al. Expires March 31, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| 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. See section Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is advertising that the site 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. Farinacci, et al. Expires March 31, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of 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. 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. Unassigned values should cause a map-cache entry to be created and, when packets match this negative cache entry, they will be dropped. The current assigned values are: (0) Drop: The packet is dropped silently. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) 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. 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. Farinacci, et al. Expires March 31, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 31, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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- Farinacci, et al. Expires March 31, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 UDP with a destination UDP port of 4342 and a randomly selected UDP source port number. 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=3D3 |P| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| 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: Farinacci, et al. Expires March 31, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Key ID: A configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. Authentication Data Length: The length in bytes of the Authentication Data field that follows this field. The length of the the Authentication Data field is dependent on the Message Authentication Code (MAC) algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Authentication Data: The message digest used from the output of the Message Authentication Code (MAC) algorithm. The entire Map- Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] is recommended. The definition of the rest of the Map-Register can be found in the Map-Reply section. 6.1.7. Encapsualted Control Message Format An Encapsulated Control Message is used to encapsulate control packets sent between xTRs and the mapping database system described in [LISP-MS]. Farinacci, et al. Expires March 31, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4342 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=3D8 | Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D yyyy = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet header descriptions: OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the source and destination header address fields. UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero. LH: Type 8 is defined to be a "LISP Encapsulated Control Message" and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the reserved field. IH: The inner IPv4 or IPv6 header which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format the destination address in this header is an EID. UDP: The inner UDP header where the port assignments depends on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is randomly assigned and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum Farinacci, et al. Expires March 31, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 field MUST be non-zero. LCM: The format is one of the control message formats described in this 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 Farinacci, et al. Expires March 31, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a Farinacci, et al. Expires March 31, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the 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. Farinacci, et al. Expires March 31, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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-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 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 Farinacci, et al. Expires March 31, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 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 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. 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 Farinacci, et al. Expires March 31, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 obtain those benefits, especially if the 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. Farinacci, et al. Expires March 31, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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- Farinacci, et al. Expires March 31, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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-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-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-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. Farinacci, et al. Expires March 31, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the 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 ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- prefix uses is the one copied from the SMR message. 3. The remote xTR retransmits the Map-Request slowly until it gets a Map-Reply while continuing to use the cached mapping. Farinacci, et al. Expires March 31, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending 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 more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. Farinacci, et al. Expires March 31, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 31, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, Farinacci, et al. Expires March 31, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires March 31, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 31, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 31, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires March 31, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. 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. Farinacci, et al. Expires March 31, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Interoperable implementations have been available since the beginning of 2009. We are trying to converge on a packet format so implementations can converge on the -04 and later drafts. 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. Farinacci, et al. Expires March 31, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires March 31, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts 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. Farinacci, et al. Expires March 31, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, 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. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. Farinacci, et al. Expires March 31, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 [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. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 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] Farinacci, et al. Expires March 31, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-02.txt (work in progress), 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. Farinacci, et al. Expires March 31, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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. Farinacci, et al. Expires March 31, 2010 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, and Jari Arkko. 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. Farinacci, et al. Expires March 31, 2010 [Page 67] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-05.txt o Posted October 2009. o Added this Document Change Log appendix. o Added section indicating that encapsulated Map-Requests must use destination UDP port 4342. o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- data in Map-Register payload. o Added Jari to acknowledgment section. o State the source-EID is set to 0 when using Map-Requests to refresh or RLOC-probe. o Make more clear what source-RLOC should be for a Map-Request. o The LISP-CONS authors thought that the Type definitions for CONS should be removed from this specification. o Removed nonce from Map-Register message, it wasn't used so no need for it. o Clarify what to do for unspecified Action bits for negative Map- Replies. Since No Action is a drop, make value 0 Drop. B.2. Changes to draft-ietf-lisp-04.txt o Posted September 2009. o 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? o Add Fred Templin in ack section. o Add Margaret and Sam to the ack section for their great comments. o Say more about LAGs in the UDP section per Sam Hartman's comment. Farinacci, et al. Expires March 31, 2010 [Page 68] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o Sam wants to use MAY instead of SHOULD for ignoring checksums on ETR. =46rom 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." o Margaret wants a reference to http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt. o Fix description in Map-Request section. Where we describe Map- Reply Record, change "R-bit" to "M-bit". o Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs but often enough to get mapping updates. o Indicate SHA1 can be used as well for Map-Registers. o More Fred comments on MTU handling. o Isidor comment about specing better periodic Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. o 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." o Add section on RLOC-probing per working group feedback. o Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. o Remove SMR-bit from data-plane. Dino prefers to have it in the control plane only. o 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. o Add a N-bit to the data header suggested by Noel. Then the nonce field could be used when N is not 1. Farinacci, et al. Expires March 31, 2010 [Page 69] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o Clarify that when E-bit is 0, the nonce field can be an echoed nonce or a random nonce. Comment from Jesper. o 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. o Indicate that a verifying Map-Request, for accepting mapping data, should be sent over the the ALT (or to the EID). o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- noncing. Comment by Pedro and Dino. o 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. B.3. Changes to draft-ietf-lisp-03.txt o Posted July 2009. o Removed loc-reach-bits longword from control packets per Damien comment. o Clarifications in MTU text from Roque. o Added text to indicate that the locator-set be sorted by locator address from Isidor. o Clarification text from JohnZ in Echo-Nonce section. B.4. Changes to draft-ietf-lisp-02.txt o Posted July 2009. o Encapsulation packet format change to add E-bit and make loc- reach-bits 32-bits in length. o Added Echo-Nonce Algorithm section. o Clarification how ECN bits are copied. o Moved S-bit in Map-Request. Farinacci, et al. Expires March 31, 2010 [Page 70] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o Added P-bit in Map-Request and Map-Reply messages to anticipate RLOC-Probe Algorithm. o Added to Mobility section to reference draft-meyer-lisp-mn-00.txt. B.5. Changes to draft-ietf-lisp-01.txt o Posted 2 days after draft-ietf-lisp-00.txt in May 2009. o Defined LEID to be a "LISP EID". o Indicate encapsulation use IPv4 DF=3D0. o Added negative Map-Reply messages with drop, native-forward, and send-map-request actions. o Added Proxy-Map-Reply bit to Map-Register. B.6. Changes to draft-ietf-lisp-00.txt o Posted May 2009. o Rename of draft-farinacci-lisp-12.txt. o Acknowledgment to RRG. Farinacci, et al. Expires March 31, 2010 [Page 71] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires March 31, 2010 [Page 72] =0C --Apple-Mail-6-938941840 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-6-938941840-- From darlewis@cisco.com Mon Sep 28 09:57: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 665983A696F for ; Mon, 28 Sep 2009 09:57:32 -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 r8ViFasb8276 for ; Mon, 28 Sep 2009 09:57:31 -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 5C8723A63C9 for ; Mon, 28 Sep 2009 09:57:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAWIwEqrR7O6/2dsb2JhbADAQIhTAY4hBYQe X-IronPort-AV: E=Sophos;i="4.44,467,1249257600"; d="scan'208";a="247955897" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 28 Sep 2009 16:58:50 +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 n8SGwn5n026782 for ; Mon, 28 Sep 2009 09:58: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 n8SGwfxe005168 for ; Mon, 28 Sep 2009 16:58:49 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); Mon, 28 Sep 2009 09:58:47 -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: Mon, 28 Sep 2009 09:58:50 -0700 Message-ID: In-Reply-To: <4AC20997-2940-42CA-9A08-01034A1DB130@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Early Monday morning diffs Thread-Index: AcpAEA68hcZ2i082Rr21WO1NhtliOgATLXkQ References: <4AC20997-2940-42CA-9A08-01034A1DB130@cisco.com> From: "Darrel Lewis (darlewis)" To: "Dino Farinacci (dino)" , X-OriginalArrivalTime: 28 Sep 2009 16:58:48.0076 (UTC) FILETIME=[F25BECC0:01CA405C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=634; t=1254157129; x=1255021129; 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]=20Early=20Monday=20morning=20dif fs |Sender:=20; bh=ot6NkvsRdcQXRBSoHf7kiyNms1LoaAhfD/WxugGawhA=; b=U8uLO8uJISsWrc+0P7uiN6QBS2tvB0oTG73cPMsWcIObiMy+EAc8ZMUSfW zOl8BXdGCXkRJjL7oBe1vU2KBU7FJbWZRohTG0nXuX3HYlhs220dTUM5yAVA h/Qqi/4WG8; Authentication-Results: sj-dkim-2; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [lisp] Early Monday morning diffs X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 Sep 2009 16:57:32 -0000 Dino, Sam and I will let you know today our thoughts on the document and when we feel its OK to post. -Darrel=20 > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 > Behalf Of Dino Farinacci (dino) > Sent: Monday, September 28, 2009 12:47 AM > To: lisp@ietf.org > Subject: [lisp] Early Monday morning diffs >=20 > Contains Margaret's text in the intro section of "Encapsultated =20 > Control Message Formats". >=20 > Chairs, have any idea when we can have rough consensus on this and =20 > when we can post -05? >=20 > Thanks, > Dino/Dave/Darrel/Vince >=20 >=20 From dino@cisco.com Mon Sep 28 11:39: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 6D6163A69EC for ; Mon, 28 Sep 2009 11:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wjkx6If4gCD0 for ; Mon, 28 Sep 2009 11:39:11 -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 BA15D3A6916 for ; Mon, 28 Sep 2009 11:39:10 -0700 (PDT) X-Files: rfcdiff-lisp-04-to-05.html, draft-ietf-lisp-05.txt : 300414, 162236 X-IronPort-AV: E=Sophos;i="4.44,468,1249257600"; d="txt'?html'217?scan'217,208,217";a="397940198" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Sep 2009 18:40:29 +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 n8SIeTja029602 for ; Mon, 28 Sep 2009 11:40:29 -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 n8SIeT96012243 for ; Mon, 28 Sep 2009 18:40:29 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, 28 Sep 2009 11:40:28 -0700 Received: from [10.10.10.51] ([10.21.123.20]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 11:40:27 -0700 Message-Id: <32A04259-73A3-4778-A1E6-83EFD9893F16@cisco.com> From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-24-978120825 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 28 Sep 2009 11:40:27 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Sep 2009 18:40:28.0143 (UTC) FILETIME=[264847F0:01CA406B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=472368; t=1254163229; x=1255027229; 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:=20Later=20Monday=20morning=20diffs |Sender:=20; bh=KatUrFeEOB0n9RSxSS7V/TZpre+YharBmX4txJDJhtc=; b=ngIw3AYpxr2vgMU207cTfktmn8CtrClpAFGT85j/uMg1lsy0MdF96ftUQc aUaGdndAIiE/ZrUwrCvn+vk4NzRVWB3Ia9qEYSTxrGJwrV+IC8iFy3/GCDb2 i4hROR9qRz; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [lisp] Later Monday morning diffs X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 Sep 2009 18:39:11 -0000 --Apple-Mail-24-978120825 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit While talking with the chairs, the changes for this rev are: (1) Add nonce back to the Map-Register to avoid replay attacks per Noel and Sam's comment. (2) Add text indicating that only Map-Requests and PIM Join/Prune messages (for multicast) can be encapsulated in the new Encapsulated Control Messsage per Sam and Margaret's comment. Diffs and spec attached. Thanks, Dino/Dave/Darrel/Vince --Apple-Mail-24-978120825 Content-Disposition: attachment; filename=rfcdiff-lisp-04-to-05.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-04-to-05.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-04.txt draft-ietf-lisp-05.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: March 20, April 1, 2010                                          D. Lewis
                                                           cisco Systems
                                                      September 16, 28, 2009

                 Locator/ID Separation Protocol (LISP)
                         draft-ietf-lisp-04.txt
           (PROPOSED) draft-ietf-lisp-05.txt (NOT POSTED YET)

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 March 20, April 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 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 . . . . . . . . . 22
       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 30
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 32 33
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 33 34
       6.1.7.  Encapsualted Control Message Format  . . . . . . . . . 36
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 36 38
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 37 39
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 39 42
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41 43
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 41 44
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 42 45
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 43 45
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 44 46
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 46 48
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 47 49
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 48 50
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 48 50
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 49 51
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 50 52
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 51 53
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 51 53
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 51 53
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 53 55
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 53 55
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 55
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 55
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 55 57
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 55 57
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 57 59
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 58 60
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 59 61
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 64
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 62 64
     14.2. Informative References . . . . . . . . . . . . . . . . . . 63 65
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 66 68
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 69
     B.1.  Changes to draft-ietf-lisp-05.txt  . . . . . . . . . . . . 69
     B.2.  Changes to draft-ietf-lisp-04.txt  . . . . . . . . . . . . 69
     B.3.  Changes to draft-ietf-lisp-03.txt  . . . . . . . . . . . . 71
     B.4.  Changes to draft-ietf-lisp-02.txt  . . . . . . . . . . . . 71
     B.5.  Changes to draft-ietf-lisp-01.txt  . . . . . . . . . . . . 72
     B.6.  Changes to draft-ietf-lisp-00.txt  . . . . . . . . . . . . 72
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 73

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 statically 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 prepends 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
      statically 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 prepends 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   |N|L|E|  rflags |                 Nonce                         |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       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   |N|L|E|  rflags |                 Nonce                         |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       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

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

   Outer 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 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 SHOULD be transmitted as zero by an ITR for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
      packet with a zero UDP checksum is received by an ETR, the ETR
      MUST accept the packet for decapsulation.  When an ITR transmits a
      non-zero value for the UDP checksum, it MUST send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.  The handling of UDP checksums for all tunneling
      protocols, including LISP, is under active discussion within the
      IETF.  When that discussion concludes, any necessary changes will
      be made to align LISP with the outcome of the broader discussion.

   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.

   N: this is the nonce-present bit.  When this bit is set to 1, the
      low-order 24-bits of the first 32-bits of the LISP header contains
      a Nonce.  See section Section 6.3.1 for details.

   L: this is the Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are in use.

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1.  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.

   rflags:  this 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
      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.  When the E-bit is clear but the N-bit
      is set, an ITR is either echoing a previously requested echo-nonce
      or providing a random nonce.  See section Section 6.3.1 for more
      details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator Status Bits are numbered from 0 to n-1 from the least
      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 outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

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

   When doing Re-encapsulated Tunneling:

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

   o  The new outer 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 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
       LISP Encapsulated Control 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . 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.  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 Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  An 8-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.  The
      security of the LISP mapping protocol depends critically on the
      strength of the nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   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.  When
      Map-Requests are used for refreshing a map-cache entry or for
      RLOC-probing, the value 0 is used.

   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 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.  The
   source address is either an IPv4 or IPv6 RLOC address depending if
   the Map-Request is using an IPv4 versus IPv6 header, respectively.
   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
   4342 with a LISP type value set to "Encapsulated Control Message",
   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.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request, it may
   originate a "verifying Map-Request", addressed to the original ITR.
   If the ETR has a map-cache entry that matches the "piggybacked" EID
   and the RLOC is in the locator-set for the entry, then it may send
   the "verifying Map-Request" to the original Map-Request source.  If
   not, then it MUST send it to the "piggybacked" EID.  Doing this
   forces the "verifying Map-Request" to go through the mapping database
   system to reach the authoritative source of information about that
   EID, guarding against RLOC-spoofing in in the "piggybacked" 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|E|            Reserved               | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      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.  See
      section Section 6.3.2 for more details.

   E: Indicates that the ETR which sends this Map-Reply message is
      advertising that the site 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 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request is echoed in this Nonce field of 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.

   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.  Unassigned values should
      cause a map-cache entry to be created and, when packets match this
      negative cache entry, they will be dropped.  The current assigned
      values are:

      (0) No action:  No action Drop:  The packet is being conveyed by the sender of the
         Map-Reply message. dropped silently.

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

   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 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 of 4342 and a
   randomly selected UDP source 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 [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 [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 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 . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Key ID             |  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      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:  This 8-byte Nonce field is set to 0 in Map-Register messages.

   Key ID:  A configured ID to find the configured Message
      Authentication Code (MAC) algorithm and key value used for the
      authentication function.

   Authentication Data Length:  The definition length in bytes of the rest
      Authentication Data field that follows this field.  The length 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 Authentication Data field is achieved by
   manipulating dependent on 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. Message
      Authentication Code (MAC) algorithm used.  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 length field allows
      a subset of the list has
      the same best priority.  Client can only use device that doesn't know the subset list
      according MAC algorithm to correctly parse
      the weighting assigned by the server-side.  In this
      case, packet.

   Authentication Data:  The message digest used from the server-side controls both output of the subset list and load-
      splitting across its members.
      Message Authentication Code (MAC) algorithm.  The client-side can use RLOCs
      outside of entire Map-
      Register payload is authenticated with this field preset to 0.
      After the subset list if MAC is computed, it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255).  Some
      sharing placed in this field.
      Implementations of control exists: the server-side determines the
      destination RLOC list this specification MUST include support for
      HMAC-SHA-1-96 [RFC2404] and load distribution while the client-side
      has the option support for HMAC-SHA-128-256 [RFC4634]
      is recommended.

   The definition of using alternatives to this list if RLOCs in the
      list are unreachable.

   o  Server-side sets weight rest of 0 for the RLOC subset list.  In this
      case, the client-side Map-Register can choose how the traffic load is spread
      across be found in the subset list.
   Map-Reply section.

6.1.7.  Encapsualted Control Message Format

   An Encapsulated Control Message is shared by the server-side
      determining the list used to encapsulate control
   packets sent between xTRs 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 mapping database system described
   in [LISP-MS].

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   OH  |                      (uses RLOC
      reachability and preferability.  Server-side ETR gleaning of the
      client-side ITR addresses)                    |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4342        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LH  |Type=8 |                   Reserved                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   IH  |                  (uses RLOC is done by caching the inner header source or EID and the addresses)                 |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = yyyy        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LCM |                      LISP Control Message                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet header descriptions:

   OH:   The outer IPv4 or IPv6 header source which uses RLOC of received packets.  The
      client-side ITR controls how traffic is returned addresses in the
      source and can alternate
      using an destination header address fields.

   UDP:   The outer UDP header with destination port 4342.  The source RLOC, which then can
      port is randomly allocated.  The checksum field MUST be added non-zero.

   LH:   Type 8 is defined to the
      list the server-side ETR uses to return traffic.  Since no
      Priority be a "LISP Encapsulated Control Message"
      and what follows is either an IPv4 or Weights are provided using this method, IPv6 header as encoded by
      the server-
      side ETR must assume each client-side ITR first 4 bits after the reserved field.

   IH:   The inner IPv4 or IPv6 header which can use either RLOC uses or EID
      addresses in the same best
      Priority with header address fields.  When a Weight of zero.  In addition, since EID-prefix
      encoding cannot be conveyed Map-Request is
      encapsulated in data packets, this packet format the EID-to-RLOC cache destination address in this
      header is an EID.

   UDP:   The inner UDP header where the port assignments depends on tunnel routers can grow to be very large.

   o  A "gleaned" map-cache entry, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification
      control packet being encapsulated.  When the control packet is performed by
      sending a
      Map-Request to or Map-Register, the source EID (the inner header IP
      source address) of port is randomly assigned
      and the received encapsulated packet.  A reply to
      this "verifying Map-Request" destination port is used to fully populate 4342.  When the map-
      cache entry for control packet is a
      Map-Reply, the "gleaned" EID and source port is stored 4342 and used for the
      time indicated destination port is
      assigned from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix port of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply or that stored in the
   mapping database system provide reachability information for RLOCs.
   Such reachability needs invoking Map-Request.  Port
      number 4341 MUST NOT be assigned to either port.  The checksum
      field MUST be determined separately, using non-zero.

   LCM:   The format is one or
   more of the Routing Locator Reachability Algorithms control message formats described in the
   next
      this section.

6.3.  At this time, only Map-Request messages and PIM
      Join-Prune messages [MLISP] are allowed to be encapsulated.
      Encapsulating other types of LISP control messages are for further
      study.

6.2.  Routing Locator Reachability

   Several mechanisms for determining RLOC reachability are currently
   defined:

   1.  An ETR Selection

   Both client-side and server-side may examine the Loc-Status-Bits in need control over the LISP header selection
   of an
       encapsulated data packet received from an ITR.  If the ETR RLOCs for conversations between them.  This control is
       also acting as an ITR and has traffic to return to achieved by
   manipulating the original
       ITR site, it can use this status Priority and Weight fields in EID-to-RLOC Map-Reply
   messages.  Alternatively, RLOC information to help select an
       RLOC.

   2.  An ITR may receive an ICMP Network be gleaned from
   received tunneled packets or ICMP Host Unreachable
       message EID-to-RLOC Map-Request messages.

   The following enumerates different scenarios for an RLOC it is using.  This indicates 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 is
       likely down.

   3.  An ITR which participates in where a subset of the global routing system can
       determine that an RLOC is down if no BGP RIB route exists that
       matches list has
      the RLOC IP address.

   4.  An ITR may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR attempts to same best priority.  Client can only use
       interworking [INTERWORK] the subset list
      according to the weighting assigned by the server-side.  In this
      case, the server-side controls both the subset list and LISP-encapsulated data load-
      splitting across its members.  The client-side can use RLOCs
      outside of the subset list if it determines that the subset list
      is sent to a
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in response unreachable (unless RLOCs are set to a
       previously sent Map-Request.  The RLOC source Priority of 255).  Some
      sharing of control exists: the Map-Reply is
       likely up since server-side determines the ETR was able to send
      destination RLOC list and load distribution while the Map-Reply client-side
      has the option of using alternatives to this list if RLOCs in the
       ITR.

   6.  When an ETR receives an encapsulated packet from an ITR,
      list are unreachable.

   o  Server-side sets weight of 0 for the
       source RLOC from subset list.  In this
      case, the outer header of client-side can choose how the packet traffic load is likely up.

   7.  An ITR/ETR pair can use spread
      across the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability subset list.  Control is shared by examining the Loc-
   Status-Bits from server-side
      determining the LISP encapsulated data packet, an ETR will
   receive up to date status from an encapsulating ITR about
   reachability for all ETRs at list and the site.  CE-based ITRs at client determining load distribution.
      Again, the source
   site client can determine reachability relative to each other using the site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route into the site IGP.

   o  If an ITR fails or use alternative RLOCs if the upstream link to its PE fails, its
      default route will either time-out or be withdrawn.

   Each ITR can thus observe the presence or lack server-provided
      list of a default route
   originated by the others to determine the Locator Status Bits it sets
   for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 unreachable.

   o  Either side (more likely on the server-side ETR) decides not to n-1.  The
   Loc-Status-Bits in
      send a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit. Map-Request.  For example, if an RLOC
   listed in the 3rd position of the Map-Reply goes down (ordinal value
   2), then all ITRs at the site will clear the 3rd least significant
   bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they
   encapsulate.

   When an server-side ETR decapsulates a packet, does not
      send Map-Requests, it will check for any change in
   the Loc-Status-Bits field.  When a bit goes gleans RLOCs from 1 to 0, the client-side ITR,
      giving the client-side ITR responsibility for bidirectional RLOC
      reachability and preferability.  Server-side ETR will
   refrain from encapsulating packets to an gleaning of the
      client-side ITR RLOC that is indicated as
   down.  It will only resume using that RLOC if done by caching the corresponding Loc-
   Status-Bit returns to a value inner header source
      EID and the outer header source RLOC of 1.  Loc-Status-Bits are associated
   with a locator-set per EID-prefix.  Therefore, when a locator becomes
   unreachable, the Loc-Status-Bit that corresponds 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 that locator's
   position in the
      list returned by the last Map-Reply will be set server-side ETR uses to
   zero for that particular EID-prefix.

   When ITRs at the site return traffic.  Since no
      Priority or Weights are not deployed 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 CE routers, data packets, the IGP EID-to-RLOC cache
      on tunnel routers can
   still be used grow to determine be very large.

   o  A "gleaned" map-cache entry, one learned from the reachability source RLOC of Locators provided they
   are injected into the IGP.  This is typically done when a /32 address
      received encapsulated packet, is configured on only stored and used for a loopback interface.

   When ITRs receive ICMP Network or Host Unreachable messages as few
      seconds, pending verification.  Verification is performed by
      sending a
   method Map-Request to determine unreachability, they will refrain from using
   Locators which are described in Locator lists the source EID (the inner header IP
      source address) of Map-Replies.
   However, using the received encapsulated packet.  A reply to
      this approach "verifying Map-Request" is unreliable because many network
   operators turn off generation used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field 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 received Map-Reply.  When a mapping
      verified map-cache 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-Status-Bits indicate the locator is up.  In this case, the path
   from the ITR to the ETR stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that is assigned matches 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
      EID-prefix of the Locator has been determined.
   Obviously, sending such probes increases the number of control verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply 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 R-bit for
   active traffic; this the locator record is set to 1.  Neither
   the same as if it were listed information contained in a Map-Reply
   with priority 255.

   The ITR can test or that stored in the
   mapping database system provide reachability of the unreachable Locator by
   sending periodic Requests.  Both Requests and Replies MUST information for RLOCs.
   Such reachability needs to be rate-
   limited. determined separately, using one or
   more of the Routing Locator reachability testing is never done with data
   packets since that increases Reachability Algorithms described in the risk of packet loss
   next section.

6.3.  Routing Locator Reachability

   Several mechanisms for end-to-end
   sessions.

   When an determining RLOC reachability are currently
   defined:

   1.  An ETR decapsulates a packet, it knows that it is reachable from may examine the encapsulating ITR because that is how Loc-Status-Bits in the LISP header of an
       encapsulated data packet arrived.  In
   most cases, received from an ITR.  If the ETR can is
       also reach the acting as an ITR but cannot assume this and has traffic to
   be true due return to the possibility of path asymmetry.  In the presence of
   unidirectional traffic flow from an original
       ITR site, it can use this status information to help select an ETR, the
       RLOC.

   2.  An ITR should not
   use the lack of return traffic as may receive an indication ICMP Network or ICMP Host Unreachable
       message for an RLOC it is using.  This indicates that the ETR is
   unreachable.  Instead, it must use an alternate mechanisms to
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When there RLOC is bidirectional data flow between a pair of locators, a
   simple mechanism called "nonce echoing"
       likely down.

   3.  An ITR which participates in the global routing system can be used to
       determine
   reachability between that an RLOC is down if no BGP RIB route exists that
       matches the RLOC IP address.

   4.  An ITR and ETR.  When may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR wants attempts to solicit a
   nonce echo, it sets the N and E bits use
       interworking [INTERWORK] and places LISP-encapsulated data is sent to a 24-bit nonce
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in the
   LISP header response to a
       previously sent Map-Request.  The RLOC source of the next encapsulated data packet.

   When this packet Map-Reply is received by
       likely up since the ETR, ETR was able to send the encapsulated packet is
   forwarded as normal.  When Map-Reply to the
       ITR.

   6.  When an ETR next sends a data receives an encapsulated packet to the from an ITR, it includes the nonce received earlier with
       source RLOC from the N bit set and E
   bit cleared.  The ITR sees outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this "echoed nonce" and knows section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability by examining the path to
   and Loc-
   Status-Bits from the LISP encapsulated data packet, an ETR is up.

   The ITR will set the E-bit and N-bit
   receive up to date status from an encapsulating ITR about
   reachability for every packet it sends while
   in echo-nonce-request state.  The time all ETRs at the ITR waits to process site.  CE-based ITRs at the
   echoed nonce before it determines source
   site can determine reachability relative to each other using the path is unreachable is variable
   and site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a choice left for default
      route into the implementation. site IGP.

   o  If the an ITR is receiving packets from the ETR but does not see fails or if the
   nonce echoed while being in echo-nonce-request state, then the path upstream link to the ETR is unreachable.  This decision may its PE fails, its
      default route will either time-out or be overridden by other
   locator reachability algorithms.  Once the withdrawn.

   Each ITR determines can thus observe the path presence or lack of a default route
   originated by the others to determine the ETR is down Locator Status Bits it can switch to another locator sets
   for that EID-prefix.

   Note that "ITR" and "ETR" them.

   RLOCs listed in a Map-Reply are relative terms here.  Both devices must
   be implementing both ITR and ETR functionality for the echo nonce
   mechanism numbered with ordinals 0 to operate.

   The ITR and ETR may both go into echo-nonce-request state at the same
   time. n-1.  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
   Loc-Status-Bits in echo-nonce-request state, it can echo a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the ETR's
   nonce least significant bit.  For example, if an RLOC
   listed in the next set 3rd position of packets that it encapsulates and the Map-Reply goes down (ordinal value
   2), then
   subsequently, continue sending echo-nonce-request packets.

   This mechanism does not completely solve all ITRs at the forward path
   reachability problem as traffic may be unidirectional.  That is, site will clear the 3rd least significant
   bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR receiving traffic at decapsulates a site may not may not be packet, it will check for any change in
   the same device as
   an ITR which transmits traffic from that site or Loc-Status-Bits field.  When a bit goes from 1 to 0, the site ETR will
   refrain from encapsulating packets to site
   traffic is unidirectional so there is no ITR returning traffic.

   The echo-nonce algorithm an RLOC that is bilateral.  That is, indicated as
   down.  It will only resume using that RLOC if one side sets the
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing corresponding Loc-
   Status-Bit returns to a value of the nonce does not occur and the requesting side may
   regard the 1.  Loc-Status-Bits are associated
   with a locator-set per EID-prefix.  Therefore, when a locator unreachable erroneously.  An ITR should only set becomes
   unreachable, the E-bit Loc-Status-Bit that corresponds to that locator's
   position in a encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed list returned by the E-bit in the Map-
   Reply message.

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

6.3.2.  RLOC Probing Algorithm

   RLOC Probing is a method that an ITR or PTR particular EID-prefix.

   When ITRs at the site are not deployed in CE routers, the IGP can use
   still be used 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 Locators provided they
   are used for RLOC Probing.

   RLOC probing injected into the IGP.  This is typically done in the control-plane when a /32 address
   is configured on a timer basis where an
   ITR or PTR will originate loopback interface.

   When ITRs receive ICMP Network or Host Unreachable messages as a Map-Request destined
   method to a locator address determine unreachability, they will refrain 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 using
   Locators which are described in the Map-Request Locator lists of Map-Replies.
   However, using this approach is the EID-prefix unreliable because many network
   operators turn off generation of the map-cache entry
   cached by the ITR or PTR.  The ICMP Unreachable messages.

   If an ITR does receive an ICMP Network or PTR may include a mapping data
   record for Host Unreachable message,
   it MAY originate its own database mapping information.

   When an ETR receives a Map-Request ICMP Unreachable message with destined for the P-bit set, it
   returns a Map-Reply with
   host that originated the P-bit set.  The source address of data packet the
   Map-Reply is set from ITR encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the destination BGP RIB to see if
   a locator address of the Map-Request from a locator-set in a mapping entry matches a
   prefix.  If it does not find one and
   the destination address of the Map-Reply BGP is set from running in the source
   address of Default
   Free Zone (DFZ), it can decide to not use the Map-Request.  The Map-Reply should contain mapping
   data for locator even though the EID-prefix contained in
   Loc-Status-Bits indicate the Map-Request.  This provides locator is up.  In this case, the opportunity for path
   from 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 ETR that it can handle many failure scenarios
   allowing the ITR to determine when is assigned the path to a specific locator is
   reachable or has become unreachable, thus providing not
   available.  More details are in [LOC-ID-ARCH].

   Optionally, an ITR can send a robust
   mechanism for switching Map-Request 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 Locator and if a Map-
   Reply is in returned, reachability of the Locator has been determined.
   Obviously, sending such probes increases the number of control
   messages required and the
   amount of bandwidth used to obtain those benefits, especially if the
   requirement originated by tunnel routers for failure detection times active flows, so Locators
   are very small.

   Continued research and testing will attempt assumed to characterize be reachable when they are advertised.

   This assumption does create a dependency: Locator unreachability is
   detected by the
   tradeoffs receipt of failure detection times versus message overhead.

6.4.  Routing Locator Hashing ICMP Host Unreachable messages.  When an ETR provides an EID-to-RLOC mapping in a Map-Reply message
   Locator has been determined to
   a requesting ITR, the locator-set be unreachable, it is not used for
   active traffic; this is the EID-prefix may contain
   different priority values for each locator address.  When more than
   one best same as if it were listed in a Map-Reply
   with priority locator exists, the 255.

   The ITR can decide how to load
   share traffic against test 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 reachability of the EID-to-RLOC mapping:

   1.  Either a source unreachable Locator by
   sending periodic Requests.  Both Requests and destination address hash can Replies MUST 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 rate-
   limited.  Locator reachability testing is never done with data
   packets since that increases the IP protocol number field or IPv6 next-
       protocol fields risk of a packet a host originates from within a LISP
       site. loss for end-to-end
   sessions.

   When an ETR decapsulates a packet is not a TCP, UDP, or SCTP packet, the
       source and destination addresses only it knows that it is reachable from
   the header are used to
       compute the hash.

   2.  Take the hash value and divide it by encapsulating ITR because that is how the number of locators
       stored in packet arrived.  In
   most cases, the locator-set for ETR can also reach the EID-to-RLOC mapping.

   3.  The remainder will ITR but cannot assume this to
   be yield a value of 0 true due to "number the possibility of locators
       minus 1".  Use path asymmetry.  In the remainder presence of
   unidirectional traffic flow from an ITR to select an ETR, the locator in ITR should not
   use the
       locator-set.

   Note lack of return traffic as an indication that when a packet is LISP encapsulated, the source port number
   in the outer UDP header needs ETR is
   unreachable.  Instead, it must use an alternate mechanisms to be set.  Selecting a random value
   allows core routers which are attached
   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 Link Aggregation Groups
   (LAGs) determine
   reachability between an ITR and ETR.  When an ITR wants to load-split the encapsulated packets across member links of
   such LAGs.  Otherwise, core routers would see solicit a single flow, since
   packets have
   nonce echo, it sets the N and E bits and places a source address 24-bit nonce in the
   LISP header of the ITR, for packets which are
   originated next encapsulated data packet.

   When this packet is received by different EIDs at the source site.  A suggested setting
   for ETR, the source port number computed by an ITR encapsulated packet is a 5-tuple hash
   function on the inner header,
   forwarded as described above.

   Many core router implementations use normal.  When the ETR next sends a 5-tuple hash to decide how to
   balance data packet load across members of a LAG.  The 5-tuple hash to the
   ITR, it includes the source and destination addresses of nonce received earlier with the packet N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the
   source path to
   and destination ports when from the protocol number in ETR is up.

   The ITR will set the E-bit and N-bit for every packet it sends while
   in echo-nonce-request state.  The time the ITR waits to process the
   echoed nonce before it determines the path is TCP or UDP.  For this reason, UDP encoding unreachable is used variable
   and a choice left 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, implementation.

   If the only way an ITR can get a more up-to-
   date mapping is to re-request the mapping.  However, receiving packets from the ITRs do ETR but does not
   know when see the mappings change and
   nonce echoed while being in echo-nonce-request state, then the ETRs do not keep track of who
   requested its mappings.  For scalability reasons, we want to maintain
   this approach but need path
   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 unreachable.  This decision may be overridden by other
   locator reachability algorithms.  Once the ITR determines the path to
   the end of a locator-set, it ETR is
   easy down it can switch to update mappings.  We assume new mappings will maintain the
   same another locator ordering as 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 old mapping but just have new locators
   appended echo nonce
   mechanism to operate.

   The ITR and ETR may both go into echo-nonce-request state at the end same
   time.  The number of packets sent or 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 during which echo nonce
   requests are sent is an ITR has only implementation specific setting.  However,
   when an old mapping but detects bits set ITR is in the loc-status-bits that correspond to locators beyond the list echo-nonce-request state, 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-status-bit to 0.  So even if can echo the locator is ETR's
   nonce in the
   list, next set of packets that it will 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 used.  For new mapping requests, unidirectional.  That is, the xTRs can
   set
   ETR receiving traffic at a site may not may not be the locator address to 0 as well same device as setting the corresponding
   loc-status-bit to 0.  This forces ITRs with old
   an ITR which transmits traffic from that site or new mappings to
   avoid using the removed locator.

   If many changes occur site to a mapping over a long period of time, site
   traffic is unidirectional so there is no ITR returning traffic.

   The echo-nonce algorithm is bilateral.  That is, if one
   will find empty record slots in side sets the middle
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing of the locator-set nonce does not occur and new
   records appended to the locator-set.  At some point, it would be
   useful to compact requesting side may
   regard the locator-set so locator unreachable erroneously.  An ITR should only set
   the loc-status-bit settings can
   be efficiently packed.

   We propose here two approaches E-bit in a encapsulated data packet when it knows the ETR is
   enabled for locator-set compaction, one
   operational and echo-noncing.  This is conveyed by the E-bit in the Map-
   Reply message.

   Note that 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 locator reachability mechanisms are being researched
   and can be used to compliment or even override the use Echo Nonce
   Algorithm.  See next section for an example of
   count-down TTLs control-plane probing.

6.3.2.  RLOC Probing Algorithm

   RLOC Probing is a method that an ITR or PTR can use to time out mappings determine the
   reachability status of one or more locators that have already been cached. it has cached in a
   map-cache entry.  The default setting P-bit (Probe Bit) of the Map-Request and Map-
   Reply messages are used for an EID-to-RLOC mapping TTL is 24 hours.  So
   there RLOC Probing.

   RLOC probing is done in the control-plane on a 24 hour window timer basis where an
   ITR or PTR will originate a Map-Request destined to time out old mappings.  The following
   clock sweep procedure is used:

   1.  24 hours before a mapping change locator address
   from one of its own locator addresses.  A Map-Request used as an
   RLOC-probe is NOT encapsulated and NOT sent to take effect, a network
       administrator configures Map-Server or on the ETRs at a site to start
   ALT like one would when soliciting mapping data.  The EID record
   encoded in the clock
       sweep window.

   2.  During Map-Request is the clock sweep window, ETRs continue to send Map-Reply
       messages with EID-prefix of the current (unchanged) mapping records. map-cache entry
   cached by the ITR or PTR.  The TTL ITR or PTR may include a mapping data
   record 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 its own database mapping information.

   When an ETR receives a Map-Request message with the ETRs continue to send P-bit set, it
   returns a Map-Reply messages with the current (unchanged) mapping records with P-bit set.  The source address of the TTL
   Map-Reply is set to
       1 minute.

   4.  At from the end destination address of the 1 hour window, Map-Request and
   the destination address of the ETRs will send Map-Reply
       messages with is set from the new (changed) mapping records.  So any active
       caches can get source
   address of the new Map-Request.  The Map-Reply should contain mapping contents right away if not cached,
       or
   data for the EID-prefix contained in 1 minute if they had the mapping cached.

6.5.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way Map-Request.  This provides
   the opportunity for xTRs, at the site
   where mappings change, to control ITR or PTR, which sent the rate they receive requests for
   Map-Reply messages.  SMRs are also used RLOC-probe to tell remote ITRs get
   mapping updates if there were changes 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 ETR's database mapping
   entries.  So an xTR will solicit Map-Requests from sites it is
   currently sending encapsulated data to,

   There are advantages and only from those sites. disadvantages of RLOC Probing.  The xTRs greatest
   benefit of RLOC Probing is that it can locally decide the algorithm for how often and to how handle many sites it sends SMR messages.

   An SMR message is simply a bit set in a Map-Request message.  An failure scenarios
   allowing the ITR
   or PTR will send a Map-Request to determine when they receive an SMR message.
   Both the SMR sender and the Map-Request responder must rate-limited
   these messages.

   The following procedure shows how a SMR exchange occurs when path to a site specific locator is doing locator-set compaction
   reachable or has become unreachable, thus providing a robust
   mechanism for an EID-to-RLOC mapping:

   1.  When switching to using another locator from the database mappings 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 an ETR change, the ETRs at number of control messages required and the site
       begin
   amount of bandwidth used to send Map-Requests with obtain those benefits, especially if the SMR bit set
   requirement for each locator
       in each map-cache entry the ETR caches.

   2.  A remote xTR which receives failure detection times are very small.

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

6.4.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Request Map-Reply message to
   a requesting ITR, the source locator address of the SMR
       message.  A newly allocated random nonce is selected and the EID-
       prefix uses is locator-set for the EID-prefix may contain
   different priority values for each locator address.  When more than
   one copied from best priority locator exists, the SMR message.

   3.  The remote xTR retransmits the Map-Request slowly until it gets a
       Map-Reply while continuing ITR can decide how to use load
   share traffic against the cached mapping.

   4. corresponding locators.

   The ETRs at the site with the changed mapping will reply following hash algorithm may be used by an ITR to select a
   locator for a packet destined to an EID for the
       Map-Request with EID-to-RLOC mapping:

   1.  Either a Map-Reply message provided source and destination address hash can be used or the Map-Request
       nonce matches
       traditional 5-tuple hash which includes the nonce from source and
       destination addresses, source and destination TCP, UDP, or SCTP
       port numbers and the SMR.  The Map-Reply messages
       SHOULD be rate limited.  This IP protocol number field or IPv6 next-
       protocol fields of a packet a host originates from within a LISP
       site.  When a packet is important to avoid Map-Reply
       implosion.

   5.  The ETRs, at the site with not a TCP, UDP, or SCTP packet, the changed mapping, records
       source and destination addresses only from the fact
       that header are used to
       compute the site that sent hash.

   2.  Take the Map-Request has received hash value and divide it by the new
       mapping data number of locators
       stored in the mapping cache entry locator-set for the remote site so
       the loc-status-bits are reflective EID-to-RLOC mapping.

   3.  The remainder will be yield a value of 0 to "number of locators
       minus 1".  Use the new mapping for packets
       going remainder to select the remote site.  The ETR then stops sending SMR
       messages.

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

   Note that when a packet is LISP encapsulated, the source port number
   in the outer UDP header needs to reduce spoofing attacks.

   To avoid map-cache entry corruption by be set.  Selecting a third-party, 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 sender single flow, since
   packets have a source address of an
   SMR-based Map-Request must be verified.  If 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 receives an SMR-
   based Map-Request 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 is not and destination ports when the protocol number in the locator-set packet
   is TCP or UDP.  For this reason, UDP encoding is used for LISP
   encapsulation.

6.5.  Changing the
   stored map-cache entry, then Contents of EID-to-RLOC Mappings

   Since the responding Map-Request MUST be sent
   with an EID destination 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 database system.  Since the
   mapping database system is more secure to reach an authoritative ETR,
   it will deliver re-request the Map-Request to mapping.  However, the authoritative source of ITRs do not
   know when the
   mapping data.

7.  Router Performance Considerations

   LISP is designed to be very hardware-based forwarding friendly.  By
   doing tunnel header prepending [RFC1955] mappings change and stripping instead the ETRs do not keep track of re-
   writing addresses, existing hardware can support 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 forwarding model
   with little or no modification.  Where modifications sites that are required,
   they should be limited currently communicating with
   the ETR site using such mappings.

   When a locator record is added to re-programming existing hardware rather
   than requiring expensive design changes the end of a locator-set, it is
   easy to hard-coded algorithms in
   silicon.

   A few implementation techniques 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 be 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-status-bits that correspond to incrementally
   implement LISP:

   o locators beyond the list it
   has cached, it simply ignores them.

   When a tunnel encapsulated packet locator record is received by an ETR, removed from a locator-set, ITRs that have
   the outer
      destination address may mapping cached will not be use the address of removed locator because the router.  This
      makes it challenging for xTRs
   will set the control plane loc-status-bit to get packets from 0.  So even if the
      hardware.  This may be mitigated by creating special FIB entries
      for locator is in 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
   list, it will not necessary.  No changes to existing,
      deployed hardware should be needed to support this.

   o  On an ITR, prepending a used.  For new IP header is as simple as adding more
      bytes to a MAC rewrite string and prepending mapping requests, the string xTRs can
   set the locator address to 0 as part of well as setting the outgoing encapsulation procedure.  Many routers that support
      GRE tunneling [RFC2784] corresponding
   loc-status-bit to 0.  This forces ITRs with old 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 new mappings to be forwarded on
   avoid using the routable topology
      (i.e.  LISP 1.5), removed locator.

   If many changes occur to a mapping over a long period of time, one
   will find empty record slots in the source address middle of a data packet or the
      router interface with which locator-set and new
   records appended to the source is associated (the
      interface from which locator-set.  At some point, it was received) can be associated with a VRF
      (Virtual Routing/Forwarding), in which a different (i.e. non-
      congruent) topology can would be used
   useful to find EID-to-RLOC mappings.

8.  Deployment Scenarios

   This section will explore how and where ITRs and ETRs compact the locator-set so the loc-status-bit settings can
   be deployed
   and will discuss the pros and cons of each deployment scenario.
   There are efficiently packed.

   We propose here two basic deployment trade-offs to consider: centralized
   versus distributed caches approaches for locator-set compaction, one
   operational 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 other a protocol mechanism.  The operational
   approach uses a clock sweep method.  The protocol approach uses the memories
   concept 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 Solicit-Map-Requests.

6.5.1.  Clock Sweep

   The clock sweep approach uses planning in advance and stored dynamically.  On the other hand,
      more ETRs does require more management since EID-prefix-to-RLOC use of
   count-down TTLs to time out mappings need 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 be explicitly configured.

   When deciding on flat, recursive, or re-encapsulation tunneling, the time out old mappings.  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
   clock sweep procedure is when tunneled traffic used:

   1.  24 hours before a mapping change is again further
      encapsulated in another tunnel, either to implement VPNs or to
      perform Traffic Engineering.  When doing VPN-based tunneling, take effect, a network
       administrator configures the ETRs at a 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 to start the site has no control.  Recursive
      tunneling generally will result in suboptimal paths but at clock
       sweep window.

   2.  During the
      benefit of steering traffic clock sweep window, ETRs continue to resource available parts of send Map-Reply
       messages with the
      network.

   o current (unchanged) mapping records.  The technique of re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs to be rerouted,
      it TTL
       for these mappings is first decapsulated by the ETR set to 1 hour.

   3.  24 hours later, all previous cache entries will have timed out,
       and then re-encapsulated with
      a new tunnel header using a new RLOC.

   The next sub-sections any active cache entries will describe where tunnel routers can reside
   in time out within 1 hour.  During
       this 1 hour window the network.

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close ETRs continue to hosts, send Map-Reply messages
       with the EID-prefix current (unchanged) mapping records with the TTL set is at to
       1 minute.

   4.  At the granularity end of an IP subnet.  So at the expense of more EID-
   prefix-to-RLOC sets for 1 hour window, the site, ETRs will send Map-Reply
       messages with the new (changed) mapping records.  So any active
       caches in each tunnel router can remain relatively small.  But caches always depend on get the number
   of non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the increase new mapping contents right away if not cached,
       or in control
   traffic grows as well: since 1 minute if they had the EID-granularity mapping cached.

6.5.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is greater, more
   Map-Requests and Map-Replies a selective way for xTRs, at the site
   where mappings change, to control the rate they receive requests for
   Map-Reply messages.  SMRs are traveling between more routers.

   The advantage of placing also used to tell remote ITRs to update
   the caches and databases at these stub
   routers is that mappings they have cached.

   Since the products deployed in this part xTRs don't keep track of the network remote ITRs that have better price-memory ratios then cached their core router counterparts.
   Memory
   mappings, they can not tell exactly who needs the new mapping
   entries.  So an xTR will solicit Map-Requests from sites it 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
   currently sending encapsulated data to, and routing state.

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

8.2.  Border/Edge Tunnel Routers

   Using customer-edge (CE) routers algorithm for tunnel endpoints allows the EID
   space associated with a site how often and to be reachable via how
   many sites it sends SMR messages.

   An SMR message is simply a small bit 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: in a Map-Request message.  An ITR
   or PTR will send a Map-Request when they receive an SMR message.
   Both the number of mapping entries SMR sender and network management
   touch points are reduced, allowing better scaling.

   One disadvantage the Map-Request responder must rate-limited
   these messages.

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

   1.  When the network's resources are used to
   reach host endpoints thereby centralizing database mappings in an ETR change, the point-of-failure domain
   and creating network choke points ETRs at the CE router.

   Note that more than one CE router at a site can be configured
       begin to send Map-Requests with the same IP address.  In this case an RLOC is an anycast address.
   This allows resilience between SMR bit set for each locator
       in each map-cache entry the CE routers.  That is, if ETR caches.

   2.  A remote xTR which receives the SMR message will schedule sending
       a CE
   router fails, traffic Map-Request message to the source locator address of the SMR
       message.  A newly allocated random nonce is automatically routed selected and the EID-
       prefix uses is the one copied from the SMR message.

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

   4.  The ETRs at the same anycast address.  However, this comes site with the
   disadvantage where changed mapping will reply to the site cannot control
       Map-Request with a Map-Reply message provided the entrance point when Map-Request
       nonce matches the anycast route is advertised out nonce 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 SMR.  The Map-Reply messages
       SHOULD be rate limited.  This is important to avoid Map-Reply
       implosion.

   5.  The ETRs, at the egress tunnel endpoints.  That is, site with the ISP
   can decide if changed mapping, records the tunnel endpoints are in fact
       that 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 sent the first router on Map-Request has received the path to
   encapsulate, it can choose a TE path first, and new
       mapping data in the ETR can
   decapsulate and re-encapsulate mapping cache entry for a tunnel to the destination end
   site.

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

   As mentioned in earlier sections a combination loc-status-bits are reflective 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 new mapping for it
   to see the entire path.  Since packets are encapsulated from ITR
       going 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 remote site.  The ETR then stops sending SMR
       messages.

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

   To avoid map-cache entry corruption by 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): third-party, a sender of an
   SMR-based Map-Request must be verified.  If an ITR ---> next-hop ... next-hop ---> ETR

      Segment 3 (in the destination LISP site receives an SMR-
   based on EIDs):

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

   For segment 1 of Map-Request and the path, ICMP Time Exceeded messages are returned source is not in the normal matter as they are today.  The ITR performs a TTL
   decrement and test locator-set for 0 before encapsulating.  So the ITR hop is
   seen by
   stored map-cache entry, then the traceroute source has responding Map-Request MUST be sent
   with an EID address (the address of
   site-facing interface).

   For segment 2 of the path, ICMP Time Exceeded messages are returned destination to the ITR because mapping database system.  Since the TTL decrement to 0
   mapping database system is done on the outer
   header, so the destination of the ICMP messages are more secure to reach an authoritative ETR,
   it will deliver the ITR RLOC
   address, Map-Request to the authoritative 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
   mapping data.

7.  Router Performance Considerations

   LISP is designed to
   the address be very hardware-based forwarding friendly.  By
   doing tunnel header prepending [RFC1955] and stripping instead of the traceroute client as well as retaining the core
   router IP address in the ICMP message.  This is so the traceroute
   client re-
   writing addresses, existing hardware can display the core router address (the RLOC address) in support the
   traceroute output.  The ETR returns its RLOC address and responds forwarding model
   with little or no modification.  Where modifications are required,
   they should be limited to
   the TTL decrement re-programming existing hardware rather
   than requiring expensive design changes to 0 like the previous core routers did.

   For segment 3, the next-hop router downstream from the ETR will hard-coded algorithms in
   silicon.

   A few implementation techniques can be
   decrementing the TTL for the used to incrementally
   implement LISP:

   o  When a tunnel encapsulated packet that was encapsulated, sent into
   the core, decapsulated is received by the an ETR, and forwarded because it isn't the
   final destination.  If the TTL is decremented to 0, any router on the
   path to the outer
      destination address may not be the address of the traceroute, including router.  This
      makes it challenging for the next-hop
   router or destination, will send an ICMP Time Exceeded message control plane to get packets from the
   source EID of the traceroute client.  The ICMP message will
      hardware.  This may be
   encapsulated mitigated by creating special FIB entries
      for the local ITR and sent back to EID-prefixes of EIDs served by the ETR in the
   originated traceroute source site, where the packet will be delivered
   to (those for which
      the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire traceroute data packet 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 included in ICMP Time Exceeded
   message payload.  Therefore, only the ITR needs not necessary.  No changes to pay special
   attention for forwarding ICMP messages back existing,
      deployed hardware should be needed 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 support this.

   o  On an ITR, prepending a new IP header and 8 is as simple as adding more
      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, MAC rewrite string and therefore prepending the identity string as part of
      the traceroute source is lost.

   The solution we propose to solve outgoing encapsulation procedure.  Many routers that support
      GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already
      support this problem action.

   o  When a received packet's outer destination address contains an EID
      which is not intended to cache traceroute
   IPv4 headers in be forwarded on the ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and routable topology
      (i.e.  LISP 1.5), the ETR.  The
   ITR will use source address of a circular buffer for caching data packet or the IPv4 and UDP headers
   of traceroute packets.  It will select
      router interface with which the source is associated (the
      interface from which it was received) can be associated with a 16-bit number as VRF
      (Virtual Routing/Forwarding), in which a key different (i.e. non-
      congruent) topology can be used to find them later when EID-to-RLOC mappings.

8.  Deployment Scenarios

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

   When an ITR encapsulates an IPv4 traceroute packet, it will use the
   16-bit number as the UDP source port in deciding on centralized versus distributed caching, the encapsulating header.
   When
   following issues should be considered:

   o  Are the ICMP Time Exceeded message is returned to tunnel routers spread out so that the ITR, caches are spread
      across all the UDP
   header memories of the encapsulating header is present in the ICMP payload
   thereby allowing the ITR to find the cached headers each router?

   o  Should management "touch points" be minimized by choosing few
      tunnel routers, just enough for the
   traceroute source.  The ITR puts the cached headers in the payload redundancy?

   o  In general, using more ITRs doesn't increase management load,
      since caches are built and sends stored dynamically.  On the ICMP Time Exceeded message 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 traceroute source
   retaining the source address of the original ICMP Time Exceeded
   message (a core router
   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 ETR of
      site has some control since the site is prepending a new tunnel
      header.  In the case of TE-based tunneling, the traceroute
   destination).

9.3.  Traceroute using Mixed Locators

   When either an IPv4 traceroute or IPv6 traceroute site may have
      control if it is originated and prepending a new tunnel header, but if the ITR encapsulates it site's
      ISP is doing the TE, then the site has no control.  Recursive
      tunneling generally will result in suboptimal paths but at the other address family header, you
   cannot get all 3 segments
      benefit of steering traffic to resource available parts of the traceroute.  Segment 2
      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
   traceroute ETR and then re-encapsulated with
      a new tunnel header using a new RLOC.

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

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close to hosts, the traceroute source since it EID-prefix set is
   expecting addresses from intermediate hops in at
   the same address format
   for granularity of an IP subnet.  So at the type expense of traceroute it originated.  Therefore, in this case,
   segment 2 will make more EID-
   prefix-to-RLOC sets for the tunnel look like one hop.  All site, the ITR has to
   do to make this work is to not copy caches in each tunnel router
   can remain relatively small.  But caches always depend on the inner TTL to number
   of non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, 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 increase in core routers between control
   traffic grows as well: since the ITR EID-granularity is greater, more
   Map-Requests and ETR.

10.  Mobility Considerations

   There Map-Replies are several kinds of mobility of which only some might be traveling between more routers.

   The advantage of
   concern to LISP.  Essentially they are as follows.

10.1.  Site Mobility

   A site wishes to change its attachment points to placing the Internet, caches and
   its LISP Tunnel Routers will have new RLOCs when it changes upstream
   providers.  Changes databases at these stub
   routers is that the products deployed in EID-RLOC mappings for sites are expected to be
   handled by configuration, outside this part of the LISP protocol.

10.2.  Slow Endpoint Mobility

   An individual endpoint wishes to move, but is not concerned about
   maintaining session continuity.  Renumbering network
   have better price-memory ratios then their core router counterparts.
   Memory is involved. 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
   help with also be deployed in edge switches.  These
   devices generally have layer-2 ports facing hosts and layer-3 ports
   facing the issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling 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 address EID
   space used by associated with 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 to be reachable via a goal. small set of RLOCs
   assigned to the CE routers for that site.

   This is where offers the Mobile IPv4
   [RFC3344bis] opposite benefit of the first-hop/last-hop tunnel
   router scenario: the number of mapping entries and Mobile IPv6 [RFC3775] [RFC4866] mechanisms network management
   touch points are used,
   and primarily where interactions with LISP need to be explored.

   The problem reduced, allowing better scaling.

   One disadvantage is that as an endpoint moves, it may require changes less of the network's resources are used to
   reach host endpoints thereby centralizing the mapping between its EID point-of-failure domain
   and a set of RLOCs for its new creating network
   location.  When this is added to choke points at the overhead of mobile IP binding
   updates, some packets might CE router.

   Note that more than one CE router at a site can be delayed or dropped. configured with
   the same IP address.  In IPv4 mobility, when this case an endpoint RLOC 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 an anycast address.
   This allows resilience between the endpoint or to CE routers.  That is, if a foreign agent which resides CE
   router fails, traffic is automatically routed to the other routers
   using the same anycast address.  However, this comes with the
   disadvantage where the endpoint has moved to.
   Packets from 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 may be sent directly to routers gives an ISP control
   over the correspondent
   node, may be sent via location of the foreign agent, egress tunnel endpoints.  That is, the ISP
   can decide if the tunnel endpoints are in the destination site (in
   either CE routers or may 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 reverse-tunneled
   back avoided.  By having the PE be the first router on the path to
   encapsulate, it can choose a TE path first, and the home agent ETR can
   decapsulate and re-encapsulate for delivery a tunnel to the mobile node.  As destination end
   site.

   An obvious disadvantage is that the
   mobile node's EID end site has no control over
   where its packets flow 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. RLOCs used.

   As mentioned in earlier sections 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 combination of these scenarios is
   possible at 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 expense of extra packet header overhead, if both site
   and provider want control, then recursive or its foreign agent re-encapsulating tunnels
   are used.

9.  Traceroute Considerations

   When a source host in the new visited
      network, a LISP site initiates a traceroute to a
   destination host in which case another LISP site, it is highly desirable for it will need
   to acquire them.

   o  When see the entire path.  Since packets are sent directly to the correspondent node, it may
      be that no traffic has been sent encapsulated from the new visited network ITR to
   ETR, the correspondent node's network, and hop across the new visited network's
      ITR tunnel could be viewed as a single hop.
   However, LISP traceroute will need to obtain an EID-RLOC mapping for provide the correspondent
      node's site.

   In addition, if entire path so the IPv4 endpoint is sending packets from user can
   see 3 distinct segments of the new
   visited network using its original EID, then path from a source LISP will need host to
   perform a route-returnability check
   destination LISP host:

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

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

      Segment 2 (in the new EID-RLOC mapping for
   that EID.

   In IPv6 mobility, packets can flow directly between core network based on RLOCs):

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

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

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

   For segment 1 of the correspondent node path, ICMP Time Exceeded messages are returned
   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 normal matter as they are today.  The ITR performs a TTL
   decrement and test for 0 before encapsulating.  So the mobile node
      to communicate with its home agent and 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 send packets the ITR because the TTL decrement to 0 is done on the
      correspondent node.

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

   When both endpoints are mobile source source RLOC address of the number encapsulated
   traceroute packet.  The ITR looks inside 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 ICMP payload to
   inspect 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 traceroute source so it can be added to LISP return the ICMP message to
   reduce
   the number address of mapping changes required and to reduce the delay
   per mapping change.  Also traceroute client as well as retaining the core
   router IP mobility address in the ICMP message.  This is so the traceroute
   client can be modified to require
   fewer mapping changes.  In order to increase overall system
   performance, there may be a need to reduce display the optimization of one
   area core router address (the RLOC address) in order the
   traceroute output.  The ETR returns its RLOC address and responds to place fewer demands on another.

   In LISP, one possibility is
   the TTL decrement to "glean" information.  When a packet
   arrives, 0 like the previous core routers did.

   For segment 3, the next-hop router downstream from the ETR could examine will be
   decrementing the EID-RLOC mapping and use that
   mapping TTL 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 packet that endpoint.
   However, this does not cover was encapsulated, sent into
   the case where an ITR (the node assigned core, decapsulated by the RLOC) at ETR, and forwarded because it isn't the mobile-node location has been compromised.

   Mobile IP packet exchange is designed for an environment in which all
   routing information
   final destination.  If the TTL is disseminated before packets can be forwarded.
   In order decremented to allow 0, any router on the Internet to grow
   path 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 destination of the overall system.  Anything which decreases traceroute, including the number of new EID-
   RLOC mappings needed when a node moves, next-hop
   router or maintains the validity of destination, will send an EID-RLOC mapping for a longer time, is useful.

10.4.  Fast Network Mobility

   In addition ICMP Time Exceeded message to endpoints, a network can be mobile, possibly changing
   xTRs.  A "network" can the
   source EID of the traceroute client.  The ICMP message will 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
   encapsulated by the local ITR and possibly short-lived, but different from endpoint mobility sent back to the ETR in that a whole prefix is changing RLOCs.  However, the mechanisms
   are
   originated traceroute source site, where the same and there is no new overhead in LISP.  A map request for
   any endpoint packet will return a binding for the entire mobile prefix.

   If mobile networks become a more common occurrence, it may be useful delivered
   to revisit the design of host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the mapping service and allow for dynamic
   updates of procedure described above since the database.

   The issue of interactions between mobility and LISP
   entire traceroute data packet is included in ICMP Time Exceeded
   message payload.  Therefore, only the ITR needs to be
   explored further.  Specific improvements pay special
   attention for forwarding ICMP messages back 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 traceroute source.

9.2.  IPv4 Traceroute

   For IPv4 traceroute, we cannot follow the LISP infrastructure to achieve mobility
   by implementing above procedure since IPv4
   ICMP Time Exceeded messages only include 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 invoking 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) header and are provided on demand to
   only the correspondents of 8
   bytes that follow the LISP mobile node.

   Refer IP header.  Therefore, when a core router sends
   an IPv4 Time Exceeded message to an ITR, all the LISP Mobility Architecture specification [LISP-MN] for
   more details.

11.  Multicast Considerations

   A multicast group address, as defined ITR has in the original Internet
   architecture ICMP
   payload is an identifier of the encapsulated header it prepended followed by a grouping of topologically
   independent receiver host locations. UDP
   header.  The address encoding itself
   does not determine original invoking IP header, and therefore the location identity
   of the receiver(s). traceroute source is lost.

   The multicast
   routing protocol, and solution we propose to solve this problem is to cache traceroute
   IPv4 headers in the network-based state ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and the protocol creates,
   determines where the receivers are located.

   In ETR.  The
   ITR will use a circular buffer for caching the context IPv4 and UDP headers
   of LISP, traceroute packets.  It will select a multicast group address is both an EID and 16-bit number as a Routing Locator.  Therefore, no specific semantic or action needs key to be taken for a destination address, as it would appear in
   find them later when the IPv4 Time Exceeded messages are received.
   When an IP
   header.  Therefore, a group address that appears in ITR encapsulates 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, IPv4 traceroute packet, it will use the same group address
   16-bit number as the
   destination Routing Locator.

   Having said that, only the source EID and UDP source Routing Locator
   needs port in the encapsulating header.
   When the ICMP Time Exceeded message is returned to be dealt with.  Therefore, an the ITR, the UDP
   header of the encapsulating header is present in the ICMP payload
   thereby allowing the ITR merely needs to put its
   own IP address 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 Routing Locator field when prepending
   retaining the outer IP header.  This source Routing Locator address, like any
   other Routing Locator address MUST be globally routable.

   Therefore, 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 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 IPv4 traceroute or PIM).  But the
   source Routing Locator IPv6 traceroute is decided by originated and
   the multicast routing protocol ITR encapsulates it 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 other address family header, you
   cannot get all 3 segments of the traceroute.  Segment 2 of the host built packet
   traceroute can not be conveyed to flow into the core even
   if the traceroute source address since it is allocated out of
   expecting addresses from intermediate hops in the EID namespace.  If same address format
   for the
   RPF-Vector TLV [RPFV] is used by PIM type of traceroute it originated.  Therefore, in this case,
   segment 2 will make the core, then core routers
   can RPF to tunnel look like one hop.  All the ITR (the Locator address which is injected into core
   routing) rather than the host source address (the EID address which has to
   do to make this work is to not injected into core routing).

   To avoid any EID-based multicast state in copy the network core, inner TTL to the first
   approach is chosen for LISP-Multicast.  Details for LISP-Multicast
   and Interworking with non-LISP sites outer,
   encapsulating header's TTL when a traceroute packet is described encapsulated
   using an RLOC from a different address family.  This will cause no
   TTL decrement to 0 to occur in specification
   [MLISP].

12.  Security Considerations

   It is believed that most of core routers between the security mechanisms will ITR and ETR.

10.  Mobility Considerations

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

10.1.  Site Mobility

   A site wishes to change its attachment points to the mapping database service Internet, and
   its LISP Tunnel Routers will have new RLOCs when using control plane procedures for
   obtaining EID-to-RLOC mappings.  For data plane triggered mappings,
   as described it changes upstream
   providers.  Changes in this specification, protection is provided against
   ETR spoofing by using Return- Routability mechanisms evidenced EID-RLOC mappings for sites are expected to be
   handled by the
   use configuration, outside of a 24-bit Nonce field in the LISP encapsulation header and a
   64-bit Nonce field in the protocol.

10.2.  Slow Endpoint Mobility

   An individual endpoint wishes to move, but is not concerned about
   maintaining session continuity.  Renumbering is involved.  LISP control message.  The nonce, coupled can
   help 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 issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling the address space used by a more heavy weight
   authentication system.  These systems challenge site from the scalability 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
   LISP which was session continuity is 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  This is where 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 Mobile IPv4
   [RFC3344bis] and PTRs.

13.  Prototype Plans Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used,
   and Status primarily where interactions with LISP need to be explored.

   The operator community has requested problem is that the IETF take a practical
   approach as an endpoint moves, it may require changes to solving
   the scaling problems associated with global
   routing state growth.  This document offers mapping between its EID and a simple solution which
   is intended set of RLOCs for use in a pilot program to gain experience in working
   on this problem.

   The authors hope that publishing its new network
   location.  When this specification will allow is added to the
   rapid implementation overhead of multiple vendor prototypes 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 deployment on forwarded via a small scale.  Doing this home agent which resides in the
   home area the endpoint's address belongs to.  The home agent will help
   encapsulate and forward packets either directly to the community:

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

   o  Experiment with provider-independent assignment of EIDs while at foreign agent which resides where the same time decreasing endpoint has moved to.
   Packets from the size of DFZ routing tables through
      the use of topologically-aligned, provider-based RLOCs.

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

   o  Experiment with mobility to determine if both acceptable
      convergence and session continuity properties can foreign agent, or may be scalably
      implemented reverse-tunneled
   back to support both individual device roaming and site
      service provider changes.

   Here is a rough set of milestones:

   1.  Interoperable implementations have been available since the
       beginning of 2009.  We are trying home agent for delivery to converge on a packet format
       so implementations can converge on the -04 and later drafts.

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

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

   4.  Implement the available RLOC changes, LISP Multicast draft [MLISP].

   5.  Implement EID-to-RLOC
   mappings are required for communication between the LISP Mobile Node draft [LISP-MN].

   6.  Research more on how policy affects what gets returned in mobile node and
   the home agent, whether via foreign agent or not.  As a Map-
       Reply mobile
   endpoint changes networks, up to three LISP mapping changes may be
   required:

   o  The mobile node moves from an ETR.

   7.  Continue to experiment with mixed locator-sets old location to understand how
       LISP can help the a new visited
      network location and notifies its home agent that it has done so.
      The Mobile IPv4 to IPv6 transition.

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

   As control packets the mobile node sends pass through
      one 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 new visited network's ITRs, which needs a EID-RLOC
      mapping for this draft the home agent.

   o  The home agent might not have the EID-RLOC mappings 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 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 completed for draft [ALT].

   3.   A unit- sent from the new visited network to
      the correspondent node's network, and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [INTERWORK].  Support 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 translation endpoint is provided and PTR support 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 IPv4 and
   that EID.

   In 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 mobility, packets can flow directly between the features described above
        on a dual-stack infrastructure.

   6.   Darrel Lewis and Dave Meyer have deployed both LISP translation mobile node
   and LISP PTR support the correspondent node in either direction.  The mobile node uses
   its "care-of" address (EID).  In this case, the pilot network.  Point your browser 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 http://www.lisp4.net communicate with its home agent and 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 send packets to a IPv6 web server the
      correspondent node.

   o  In addition, another mapping will be needed in a LISP site by using mixed
        address-family based locators.

   8.   An public domain implementation of LISP is underway.  See
        [OPENLISP] the correspondent
      node's ITR, in order for details.

   9.   We have deployed Map-Resolvers and Map-Servers on the LISP pilot
        network correspondent node to send packets to gather experience with [LISP-MS].  The first layer of
      the architecture mobile node's "care-of" address (EID) at the new network
      location.

   When both endpoints are mobile the xTRs which use Map-Servers for EID-
        prefix registration and Map-Resolvers for EID-to-RLOC number of potential mapping
        resolution.  The second layer
   lookups increases accordingly.

   As a mobile node moves there are not only mobility state changes in
   the Map-Resolvers mobile node, correspondent node, and Map-
        Servers which connect to the ALT BGP peering infrastructure.
        And home agent, but also state
   changes in 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 ITRs and decapsulation features.

   11.  A LISP router based LIG implementation ETRs for at least some EID-prefixes.

   The goal is supported, deployed,
        and used daily to debug and test support rapid adaptation, with little delay or packet
   loss for the entire system.  Heuristics can be added to LISP pilot network.  See
        [LIG] for details.

   12.  A Linux implementation to
   reduce the number of LIG has been made available mapping changes required and
        supported by Dave Meyer.  It to reduce the delay
   per mapping change.  Also IP mobility can be run on any Linux modified to require
   fewer mapping changes.  In order to increase overall system
        which resides
   performance, there may be a need to reduce the optimization of one
   area in either order to place fewer demands on another.

   In LISP, one possibility is to "glean" information.  When a LISP site or non-LISP site.  See [LIG] packet
   arrives, the ETR could examine the EID-RLOC mapping and use that
   mapping for details.  Public domain code all outgoing traffic to that EID.  It can be downloaded from
        http://github.com/davidmeyer/lig/tree/master.

   13.  An experimental implementation 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 written compromised.

   Mobile IP packet exchange is designed for three
        locator reachability algorithms.  Two are the Echo-Noncing and
        RLOC-Probing algorithms which are documented an environment in this
        specification.  The third is called TCP-counts which will be
        documented in all
   routing information is disseminated before packets can be forwarded.
   In order to allow the Internet to grow to support expected future drafts.

   14.  The LISP pilot network has been converted from using MD5 HMAC
        authentication
   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 Map-Register messages a longer time, is useful.

10.4.  Fast Network Mobility

   In addition to SHA-1 HMAC
        authentication.  ETRs send with SHA-1 but Map-Servers endpoints, a network can
        received 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 either for compatibility purposes.

   If interested site mobility in writing that it is
   fast and possibly short-lived, but different from endpoint mobility
   in that a LISP implementation, testing 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 implementations, or want needs to be part of
   explored further.  Specific improvements to 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 entire system will
   depend on the Naming and Binding details 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 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 in RFCs the LISP infrastructure to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. achieve mobility
   by implementing the LISP encapsulation 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., decapsulation functions
   and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3056]  Carpenter, B. 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 K. Moore, "Connection do not impose a cost on the global routing
   system.  These EIDs are maintained at the edges of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., the mapping system
   (in LISP Map-Servers and D. Black, "The Addition Map-Resolvers) and are provided on demand to
   only the correspondents of Explicit Congestion Notification (ECN) the LISP mobile node.

   Refer to IP",
              RFC 3168, September 2001.

   [RFC3775]  Johnson, 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 24-bit Nonce field in the LISP encapsulation header and a
   64-bit Nonce field in the LISP control message.  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.  Interoperable implementations have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   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.  Two are the Echo-Noncing and
        RLOC-Probing algorithms which are documented in this
        specification.  The third is called TCP-counts 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.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, 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.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

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

   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 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.

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

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), February
              May 2009.

14.2.  Informative References

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

   [ALT]

   [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, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-01.txt
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt (work in progress), May
              March 2009.

   [APT]      Jen,

   [LISP-MN]  Farinacci, D., Meisel, M., Massey, Fuller, V., Lewis, D., Wang, L., Zhang, B., and
              L. Zhang, "APT: A Practical Transit Mapping Service",
              draft-jen-apt-01.txt D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
              in progress), November 2007.

   [CHIAPPA]  Chiappa, J., "Endpoints July 2009.

   [LISP-MS]  Farinacci, D. and Endpoint names: A Proposed
              Enhancement to the Internet Architecture", Internet-
              Draft http://www.chiappa.net/~jnc/tech/endpoints.txt,
              1999.

   [CONS] V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-02.txt (work in progress),
              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, "LISP-CONS: A
              Content distribution Overlay Network  Service D., Zwiebel, J., and S. Venaas,
              "LISP for LISP",
              draft-meyer-lisp-cons-03.txt Multicast Environments",
              draft-ietf-lisp-multicast-02.txt (work in progress),
              October 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),
              November 2007.

   [DHTs]     Ratnasamy, S., Shenker, S., and I. Stoica, July 2008.

   [RADIR]    Narten, T., "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 Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress),
              November July 2007.

   [GSE]      "GSE - An Alternate Addressing Architecture

   [RFC3344bis]
              Perkins, C., "IP Mobility Support for  IPv6",
              draft-ietf-ipngwg-gseaddr-00.txt IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work in progress), 1997.

   [INTERWORK]
              Lewis, D., Meyer, D., Farinacci, D.,
              July 2007.

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

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

   [LIG]      Farinacci, D.

   [RPMD]     Handley, M., Huici, F., and D. Meyer, "LISP Internet Groper (LIG)",
              draft-farinacci-lisp-lig-01.txt A. Greenhalgh, "RPMD: Protocol
              for Routing Protocol Meta-data  Dissemination",
              draft-handley-p2ppush-unpublished-2007726.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., July 2007.

   [SHIM6]    Nordmark, E. and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt M. Bagnulo, "Level 3 multihoming shim
              protocol", draft-ietf-shim6-proto-06.txt (work in
              progress),
              March 2009.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., October 2006.

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 D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
              in progress), July 2009.

   [LISP-MS]  Farinacci, D. identity, as well as detailed review of the LISP
   architecture and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-02.txt (work in progress),
              September 2009.

   [LISP1]    Farinacci, D., Oran, D., Fuller, V., documents, coupled with enthusiasm for making LISP a
   practical 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., incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and J. ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
              "Locator/ID Separation Protocol (LISP2) [DNS-based
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt,
              November 2006.

   [LISPDHT]  Mathy, L.,
   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, L., 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, and O. Bonaventure, "LISP-DHT:
              Towards a DHT Jari
   Arkko.

   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.

Appendix B.  Document Change Log

B.1.  Changes to map identifiers onto locators",
              draft-mathy-lisp-dht-00.txt (work draft-ietf-lisp-05.txt

   o  Posted October 2009.

   o  Added this Document Change Log appendix.

   o  Added section indicating that encapsulated Map-Requests must use
      destination UDP port 4342.

   o  Don't use AH in progress),
              February 2008.

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

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP Map-Register payload.

   o  Added Jari to acknowledgment section.

   o  State the source-EID is set to 0 when using Map-Requests to
      refresh or RLOC-probe.

   o  Make more clear what source-RLOC should be for Multicast Environments",
              draft-ietf-lisp-multicast-01.txt (work in progress),
              May 2009.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID a Map-Request.

   o  The LISP-CONS authors thought that the Type definitions for CONS
      should be removed from this specification.

   o  Removed nonce from Map-Register message, it wasn't used so no need
      for it.

   o  Clarify what to RLOC Database",
              draft-lear-lisp-nerd-04.txt (work in progress),
              April 2008.

   [OPENLISP]
              Iannone, L. do for unspecified Action bits for negative Map-
      Replies.  Since No Action is a drop, make value 0 Drop.

B.2.  Changes to draft-ietf-lisp-04.txt

   o  Posted September 2009.

   o  How do deal with record count greater than 1 for a Map-Request.
      Damien and O. Bonaventure, "OpenLISP Implementation
              Report", draft-iannone-openlisp-implementation-01.txt
              (work in progress), July 2008.

   [RADIR]    Narten, T., "Routing Joel comment.  Joel suggests: 1) Specify that senders
      compliant with the current document will always set the count to
      1, and Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress), July 2007.

   [RFC3344bis]
              Perkins, C., "IP Mobility Support note that the count is included for IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work 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?

   o  Add Fred Templin in progress),
              July 2007.

   [RFC4192]  Baker, F., Lear, E., ack section.

   o  Add Margaret and R. Droms, "Procedures Sam to the ack section for
              Renumbering their great comments.

   o  Say more about LAGs in the UDP section per Sam Hartman's comment.

   o  Sam wants to use MAY instead of SHOULD for ignoring checksums on
      ETR.  From the mailing list: "You'd need to word it as an IPv6 Network without ITR MAY
      send a Flag Day", RFC 4192,
              September 2005.

   [RPFV]     Wijnands, IJ., Boers, A., zero checksum, an ETR MUST accept a 0 checksum and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-08.txt (work 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."

   o  Margaret wants a reference to
      http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt.

   o  Fix description in progress),
              January 2009.

   [RPMD]     Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol Map-Request section.  Where we describe Map-
      Reply Record, change "R-bit" to "M-bit".

   o  Add the mobility bit to Map-Replies.  So PTRs don't probe so often
      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.

Appendix A.  Acknowledgments

   An initial thank you goes MNs but often enough to Dave Oran get mapping updates.

   o  Indicate SHA1 can be used as well for planting Map-Registers.

   o  More Fred comments on MTU handling.

   o  Isidor comment about specing better periodic Map-Registers.  Will
      be fixed in draft-ietf-lisp-ms-02.txt.

   o  Margaret's comment on gleaning: "The current specification does
      not make it clear how long gleaned map entries should be retained
      in the seeds 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
   initial ideas for LISP.  His consultation continues mapping system.  The security implications of storing
      "gleaned" entries should also be explored in detail."

   o  Add section on RLOC-probing per working group feedback.

   o  Change "loc-reach-bits" to provide value "loc-status-bits" per comment from
      Noel.

   o  Remove SMR-bit from data-plane.  Dino prefers to have it in the
      control plane only.

   o  Change LISP authors.

   A special and appreciative thank you goes header to Noel Chiappa for
   providing architectural impetus over allow a "Research Bit" so the past decades on separation
   of location Nonce and identity, as well as detailed review of the LISP
   architecture LSB
      fields can be turned off and documents, coupled with enthusiasm used for making LISP another future purpose.  For
      Luigi et al versioning convergence.

   o  Add a
   practical and incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas N-bit 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, data header suggested by Noel.  Then the nonce
      field could be used when N is not 1.

   o  Clarify that when E-bit is 0, the nonce field can be an echoed
      nonce or a random nonce.  Comment from Jesper.

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

   o  Indicate that a verifying Map-Request, for accepting mapping data,
      should be sent over the the ALT (or to the EID).

   o  Reference IPsec RFC 4302.  Comment from Sam Hartman, Michael Hofling, and Brian Weis.

   o  Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
      noncing.  Comment by Pedro Marques.

   In particular, we would like and Dino.

   o  Jesper made a comment to thank Dave Meyer for his clever
   suggestion for loosen the name "LISP". ;-)

   This language about requiring the
      copy of inner TTL to outer TTL since the text to get mixed-AF
      traceroute to work originated would violate the "MUST" clause.  Changed from
      MUST to SHOULD in section 5.3.

B.3.  Changes to draft-ietf-lisp-03.txt

   o  Posted July 2009.

   o  Removed loc-reach-bits longword from control packets per Damien
      comment.

   o  Clarifications in MTU text from Roque.

   o  Added text to indicate that the Routing Research Group (RRG) locator-set be sorted by locator
      address from Isidor.

   o  Clarification text from JohnZ in Echo-Nonce section.

B.4.  Changes to draft-ietf-lisp-02.txt

   o  Posted July 2009.

   o  Encapsulation packet format change to add E-bit and make loc-
      reach-bits 32-bits in length.

   o  Added Echo-Nonce Algorithm section.

   o  Clarification how ECN bits are copied.

   o  Moved S-bit in Map-Request.

   o  Added P-bit in Map-Request and Map-Reply messages to anticipate
      RLOC-Probe Algorithm.

   o  Added to Mobility section to reference draft-meyer-lisp-mn-00.txt.

B.5.  Changes to draft-ietf-lisp-01.txt

   o  Posted 2 days after draft-ietf-lisp-00.txt in May 2009.

   o  Defined LEID to be a "LISP EID".

   o  Indicate encapsulation use IPv4 DF=0.

   o  Added negative Map-Reply messages with drop, native-forward, and
      send-map-request actions.

   o  Added Proxy-Map-Reply bit to Map-Register.

B.6.  Changes to draft-ietf-lisp-00.txt

   o  Posted May 2009.

   o  Rename of the IRTF.
   The individual submission [LISP-MAIN] was converted into this IETF
   LISP working group draft. draft-farinacci-lisp-12.txt.

   o  Acknowledgment to RRG.

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-24-978120825 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-24-978120825 Content-Disposition: attachment; filename=draft-ietf-lisp-05.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-05.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: April 1, 2010 D. Lewis cisco Systems September 28, 2009 Locator/ID Separation Protocol (LISP) (PROPOSED) draft-ietf-lisp-05.txt (NOT POSTED YET) 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 April 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. Farinacci, et al. Expires April 1, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 . . . . . . . . . 22 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 . . . . . . . . . . . . . . . 30 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 33 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 34 6.1.7. Encapsualted Control Message Format . . . . . . . . . 36 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 38 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 39 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 42 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 43 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 44 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 45 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 45 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 46 7. Router Performance Considerations . . . . . . . . . . . . . . 48 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 49 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 50 Farinacci, et al. Expires April 1, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 50 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 51 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 52 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 53 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 53 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 53 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 55 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 55 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 55 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 55 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 57 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 57 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 59 12. Security Considerations . . . . . . . . . . . . . . . . . . . 60 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 61 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 14.1. Normative References . . . . . . . . . . . . . . . . . . . 64 14.2. Informative References . . . . . . . . . . . . . . . . . . 65 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 68 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 69 B.1. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 69 B.2. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 69 B.3. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 71 B.4. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 71 B.5. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 72 B.6. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 Farinacci, et al. Expires April 1, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires April 1, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires April 1, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires April 1, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires April 1, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 statically 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 prepends 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 statically configured. Farinacci, et al. Expires April 1, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 prepends 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 Farinacci, et al. Expires April 1, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires April 1, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E| rflags | Nonce | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | 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 | | Farinacci, et al. Expires April 1, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer 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 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 SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion. 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 Farinacci, et al. Expires April 1, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 headers are used. The UDP header length is 8 bytes. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See section Section 6.3.1 for details. L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. E: this is the echo-nonce-request bit. When this bit is set to 1, the N bit must be 1. 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. rflags: this 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 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. When the E-bit is clear but the N-bit is set, an ITR is either echoing a previously requested echo-nonce or providing a random nonce. See section Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least 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 outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Farinacci, et al. Expires April 1, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 Type of Service field (with one caveat, see below). When doing Re-encapsulated Tunneling: o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer 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. Farinacci, et al. Expires April 1, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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. Farinacci, et al. Expires April 1, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet with DF bit set to 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. Farinacci, et al. Expires April 1, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 =3D 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=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires April 1, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 | | + 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. Farinacci, et al. Expires April 1, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Encapsulated Control Message: 8 b'1000' 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=3D1 |A|M|P|S| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . 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: Farinacci, et al. Expires April 1, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. 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 Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. 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. When Map-Requests are used for refreshing a map-cache entry or for RLOC-probing, the value 0 is used. Originating ITR RLOC Address: Used to give the ETR the option of returning a Map-Reply in the address-family of this locator. Farinacci, et al. Expires April 1, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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. The source address is either an IPv4 or IPv6 RLOC address depending if the Map-Request is using an IPv4 versus IPv6 header, respectively. 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 4342 with a LISP type value set to "Encapsulated Control Message", 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]. Farinacci, et al. Expires April 1, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request, it may originate a "verifying Map-Request", addressed to the original ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map-Request" to the original Map-Request source. If not, then it MUST send it to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" mapping data. Farinacci, et al. Expires April 1, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| 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. See section Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is advertising that the site 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. Farinacci, et al. Expires April 1, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of 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. 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. Unassigned values should cause a map-cache entry to be created and, when packets match this negative cache entry, they will be dropped. The current assigned values are: (0) Drop: The packet is dropped silently. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) 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. 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. Farinacci, et al. Expires April 1, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires April 1, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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- Farinacci, et al. Expires April 1, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 UDP with a destination UDP port of 4342 and a randomly selected UDP source port number. The Map-Register message format is: Farinacci, et al. Expires April 1, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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=3D3 |P| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| 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: This 8-byte Nonce field is set to 0 in Map-Register messages. Farinacci, et al. Expires April 1, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 Key ID: A configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. Authentication Data Length: The length in bytes of the Authentication Data field that follows this field. The length of the the Authentication Data field is dependent on the Message Authentication Code (MAC) algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Authentication Data: The message digest used from the output of the Message Authentication Code (MAC) algorithm. The entire Map- Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] is recommended. The definition of the rest of the Map-Register can be found in the Map-Reply section. 6.1.7. Encapsualted Control Message Format An Encapsulated Control Message is used to encapsulate control packets sent between xTRs and the mapping database system described in [LISP-MS]. Farinacci, et al. Expires April 1, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4342 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=3D8 | Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D yyyy = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet header descriptions: OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the source and destination header address fields. UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero. LH: Type 8 is defined to be a "LISP Encapsulated Control Message" and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the reserved field. IH: The inner IPv4 or IPv6 header which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format the destination address in this header is an EID. UDP: The inner UDP header where the port assignments depends on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is randomly assigned and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum Farinacci, et al. Expires April 1, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 field MUST be non-zero. LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages and PIM Join-Prune messages [MLISP] are allowed to be encapsulated. Encapsulating other types of LISP control messages are for further study. 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 Farinacci, et al. Expires April 1, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. Farinacci, et al. Expires April 1, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the Loc-Status-Bit that corresponds to that locator's Farinacci, et al. Expires April 1, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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-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 asymmetry. In the presence of Farinacci, et al. Expires April 1, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 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 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. The echo-nonce algorithm is bilateral. That is, if one side sets the Farinacci, et al. Expires April 1, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 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 obtain those benefits, especially if the requirement for failure detection times are very small. Farinacci, et al. Expires April 1, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-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-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-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-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: Farinacci, et al. Expires April 1, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the 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 ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- Farinacci, et al. Expires April 1, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 prefix uses is the one copied from the SMR 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-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending 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 more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. Farinacci, et al. Expires April 1, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires April 1, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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, Farinacci, et al. Expires April 1, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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: Farinacci, et al. Expires April 1, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires April 1, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires April 1, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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]. Farinacci, et al. Expires April 1, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. 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. Farinacci, et al. Expires April 1, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Interoperable implementations have been available since the beginning of 2009. We are trying to converge on a packet format so implementations can converge on the -04 and later drafts. 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. Farinacci, et al. Expires April 1, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Farinacci, et al. Expires April 1, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts 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. Farinacci, et al. Expires April 1, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, 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. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. Farinacci, et al. Expires April 1, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 [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. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 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] Farinacci, et al. Expires April 1, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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-02.txt (work in progress), 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. Farinacci, et al. Expires April 1, 2010 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-ietf-lisp-multicast-02.txt (work in progress), October 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. Farinacci, et al. Expires April 1, 2010 [Page 67] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 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, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, and Jari Arkko. 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. Farinacci, et al. Expires April 1, 2010 [Page 68] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-05.txt o Posted October 2009. o Added this Document Change Log appendix. o Added section indicating that encapsulated Map-Requests must use destination UDP port 4342. o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- data in Map-Register payload. o Added Jari to acknowledgment section. o State the source-EID is set to 0 when using Map-Requests to refresh or RLOC-probe. o Make more clear what source-RLOC should be for a Map-Request. o The LISP-CONS authors thought that the Type definitions for CONS should be removed from this specification. o Removed nonce from Map-Register message, it wasn't used so no need for it. o Clarify what to do for unspecified Action bits for negative Map- Replies. Since No Action is a drop, make value 0 Drop. B.2. Changes to draft-ietf-lisp-04.txt o Posted September 2009. o 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? o Add Fred Templin in ack section. o Add Margaret and Sam to the ack section for their great comments. o Say more about LAGs in the UDP section per Sam Hartman's comment. Farinacci, et al. Expires April 1, 2010 [Page 69] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o Sam wants to use MAY instead of SHOULD for ignoring checksums on ETR. =46rom 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." o Margaret wants a reference to http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt. o Fix description in Map-Request section. Where we describe Map- Reply Record, change "R-bit" to "M-bit". o Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs but often enough to get mapping updates. o Indicate SHA1 can be used as well for Map-Registers. o More Fred comments on MTU handling. o Isidor comment about specing better periodic Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. o 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." o Add section on RLOC-probing per working group feedback. o Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. o Remove SMR-bit from data-plane. Dino prefers to have it in the control plane only. o 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. o Add a N-bit to the data header suggested by Noel. Then the nonce field could be used when N is not 1. Farinacci, et al. Expires April 1, 2010 [Page 70] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o Clarify that when E-bit is 0, the nonce field can be an echoed nonce or a random nonce. Comment from Jesper. o 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. o Indicate that a verifying Map-Request, for accepting mapping data, should be sent over the the ALT (or to the EID). o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- noncing. Comment by Pedro and Dino. o 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. B.3. Changes to draft-ietf-lisp-03.txt o Posted July 2009. o Removed loc-reach-bits longword from control packets per Damien comment. o Clarifications in MTU text from Roque. o Added text to indicate that the locator-set be sorted by locator address from Isidor. o Clarification text from JohnZ in Echo-Nonce section. B.4. Changes to draft-ietf-lisp-02.txt o Posted July 2009. o Encapsulation packet format change to add E-bit and make loc- reach-bits 32-bits in length. o Added Echo-Nonce Algorithm section. o Clarification how ECN bits are copied. o Moved S-bit in Map-Request. Farinacci, et al. Expires April 1, 2010 [Page 71] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 o Added P-bit in Map-Request and Map-Reply messages to anticipate RLOC-Probe Algorithm. o Added to Mobility section to reference draft-meyer-lisp-mn-00.txt. B.5. Changes to draft-ietf-lisp-01.txt o Posted 2 days after draft-ietf-lisp-00.txt in May 2009. o Defined LEID to be a "LISP EID". o Indicate encapsulation use IPv4 DF=3D0. o Added negative Map-Reply messages with drop, native-forward, and send-map-request actions. o Added Proxy-Map-Reply bit to Map-Register. B.6. Changes to draft-ietf-lisp-00.txt o Posted May 2009. o Rename of draft-farinacci-lisp-12.txt. o Acknowledgment to RRG. Farinacci, et al. Expires April 1, 2010 [Page 72] =0C Internet-Draft Locator/ID Separation Protocol (LISP) September 2009 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 Farinacci, et al. Expires April 1, 2010 [Page 73] =0C --Apple-Mail-24-978120825 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-24-978120825-- From darlewis@cisco.com Mon Sep 28 15:56: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 00CFA3A6939 for ; Mon, 28 Sep 2009 15:56:47 -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 3TabrX3TLgTj for ; Mon, 28 Sep 2009 15:56:45 -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 DF2BF3A67AD for ; Mon, 28 Sep 2009 15:56:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABvcwEqrR7MV/2dsb2JhbADAEohTAY5SBYQe X-IronPort-AV: E=Sophos;i="4.44,469,1249257600"; d="scan'208";a="192793562" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2009 22:58:05 +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 n8SMw58b006214 for ; Mon, 28 Sep 2009 15:58:05 -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 n8SMw5eR009949 for ; Mon, 28 Sep 2009 22:58:05 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); Mon, 28 Sep 2009 15:58:04 -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: Mon, 28 Sep 2009 15:58:04 -0700 Message-ID: In-Reply-To: <32A04259-73A3-4778-A1E6-83EFD9893F16@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Later Monday morning diffs Thread-Index: AcpAa15adTZQ+9YNTLqnXNuk4kbhUAAIlrUw References: <32A04259-73A3-4778-A1E6-83EFD9893F16@cisco.com> From: "Darrel Lewis (darlewis)" To: "Dino Farinacci (dino)" , X-OriginalArrivalTime: 28 Sep 2009 22:58:04.0897 (UTC) FILETIME=[2339C510:01CA408F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1931; t=1254178685; x=1255042685; 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]=20Later=20Monday=20morning=20dif fs |Sender:=20; bh=MkeUrHC3ohIKw075RsbEA/xoEOd/YpmIb8x/gpxlA1g=; b=nCDY1efr8aB8FZYVeRgfeCjSEY4kjTwr/wiwEyZbZ2yfes5vekBLbuA0I7 T6JyiF8D7eRCwe5RAlgYvOnw6JXfFkrigP75EyTho3p6Teg9+vvNQ/gqkp5G 0YeHr5ER8lHRwXXzgnSZMbBJ9RI3ZGgIF71P94OMvV7ds20WA5F+s=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [lisp] Later Monday morning diffs X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 Sep 2009 22:56:47 -0000 Speaking as WG Co-chair. Dino I think you can go ahead and post -05 tomorrow 9/29 at the end of the day PDT. The chairs would like to thank you for taking the time to include a historical change log in the latest version of the document.=20 I'd also like to summarize what I understand to be the major substantive changes to this document: o Added section indicating that encapsulated Map-Requests must use destination UDP port 4342. o Don't use AH in Map-Registers. Put key-id, auth-length, and=20 auth-data in Map-Register payload. Its my understanding that the details of this reflect the discussion we've had this week. If I've missed something and there are outstanding issues please let me know, and if substantive we will address prior to posting. If there are still wording/detail differences of opinion (for example, the discussion about a 'service interface') and the posting of this should not be seen as the end of that discussion. In fact, the chairs welcome continued discussion so we can refine the -06 version of this draft. Thanks to the WG participants for their careful and detailed review of the document to date. =20 -Darrel > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 > Behalf Of Dino Farinacci (dino) > Sent: Monday, September 28, 2009 11:40 AM > To: lisp@ietf.org > Subject: [lisp] Later Monday morning diffs >=20 > While talking with the chairs, the changes for this rev are: >=20 > (1) Add nonce back to the Map-Register to avoid replay attacks per =20 > Noel and Sam's comment. >=20 > (2) Add text indicating that only Map-Requests and PIM Join/Prune =20 > messages (for multicast) can be encapsulated in the new Encapsulated =20 > Control Messsage per Sam and Margaret's comment. >=20 > Diffs and spec attached. >=20 > Thanks, > Dino/Dave/Darrel/Vince >=20 >=20 From dino@cisco.com Mon Sep 28 22:18: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 9CFDA3A6A3E for ; Mon, 28 Sep 2009 22:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.080, 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 kFROdvlvt2MF for ; Mon, 28 Sep 2009 22:18:44 -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 D8BC93A67B1 for ; Mon, 28 Sep 2009 22:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=136485; q=dns/txt; s=sjiport01001; t=1254201604; x=1255411204; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Dino=20Farinacci=20|Subject:=20P roposed=20changes=20to=20draft-ietf-lisp-multicast-02.txt |Date:=20Mon,=2028=20Sep=202009=2022:19:58=20-0700 |Message-Id:=20<0EF3B951-BF95-4D1D-8435-37A5EC3A4E16@cisc o.com>|To:=20lisp@ietf.org|Cc:=20David=20Meyer=20,=20John=20Zwiebel=20,=0D=0A =20=20=20=20=20=20=20=20Stig=20Venaas=20|Mime-Version:=201.0=20(Apple=20Message=20framework=20v 936); bh=JNpLGvvIdeBSpE/6qQWanaj23l5BO+74vT+E9RRzH/s=; b=nlSW1S3n7zvCp8Y/2jRxXhVxvAkgNpZsJEq2DoUII6GHoM3TzGvIBIzW hSj8Yrb7zN1ML+YcQjs/ED5+ZP5uV0zn893ESzHCJtourvRhYU7O5eqKQ rwmOZasfVslTfFOFcw91G0Qw8HWSNlbFR/2Rq7yAVuVgG+FBAgpJqDDiJ Y=; Authentication-Results: sj-iport-1.cisco.com; dkim=pass (partially verified [136445 bytes] [TEST]) header.i=dino@cisco.com X-Files: rfcdiff-lisp-multicast-01-to-02.html, draft-ietf-lisp-multicast-02.txt : 63882, 68094 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAGc1wUqrR7MV/2dsb2JhbACCIjK8L4hTASaPAQWCMAGBbYFd X-IronPort-AV: E=Sophos;i="4.44,471,1249257600"; d="txt'?html'217?scan'217,208,217";a="248249952" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 29 Sep 2009 05:20:00 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8T5K0SG009156 for ; Mon, 28 Sep 2009 22:20:00 -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 n8T5K0WY026307 for ; Tue, 29 Sep 2009 05:20:00 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, 28 Sep 2009 22:19:59 -0700 Received: from [192.168.1.2] ([10.21.66.207]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 22:19:59 -0700 Message-Id: <0EF3B951-BF95-4D1D-8435-37A5EC3A4E16@cisco.com> From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-36-1016491758 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 28 Sep 2009 22:19:58 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Sep 2009 05:19:59.0320 (UTC) FILETIME=[7D493D80:01CA40C4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=136445; t=1254201600; x=1255065600; 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:=20Proposed=20changes=20to=20draft-ietf-lisp-multi cast-02.txt |Sender:=20; bh=5X/ibZvKEIG1wH+DWzZY1rY5AIywQ8ZnNZ/Emzil4NY=; b=Wpe4sv2YKmNDhp7v80L1MlkzI3k4Nc4iz9B6rTiTVcn2ZmUqHAY6imdSvv W1B0iXV0wTeZX4f1olcjFAYNdWSUUgVfjrgtd/vvZdgiEdaT1a8vX9bCDUOy SOEi3XrqPLf0wU4H7rybxk1ZrUhaAIf+UjCJ+X3NJbsj/8Ai6r4d4=; Cc: Stig Venaas , David Meyer Subject: [lisp] Proposed changes to draft-ietf-lisp-multicast-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: Tue, 29 Sep 2009 05:18:53 -0000 --Apple-Mail-36-1016491758 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The changes for the multicast draft are really minor. Changes include: (1) Refer to encapsulating PIM Join/Prune messages in the new Encapsulated Control Message as documented in draft-ietf-lisp-05.txt. (2) Add Document Change Log. (3) Add references to draft-ietf-lisp-05.txt. Diffs and spec attached. Thanks, Dino/Dave/JohnZ/Stig --Apple-Mail-36-1016491758 Content-Disposition: attachment; filename=rfcdiff-lisp-multicast-01-to-02.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-multicast-01-to-02.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-multicast-01.txt draft-ietf-lisp-multicast-02.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                  D. Meyer
Intended status: Experimental                                 J. Zwiebel
Expires: November 29, 2009 April 1, 2010                                         S. Venaas
                                                           cisco Systems
                                                            May
                                                      September 28, 2009

                    LISP for Multicast Environments
                    draft-ietf-lisp-multicast-01.txt
      (PROPOSED) draft-ietf-lisp-multicast-02.txt (NOT POSTED YET)

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 29, 2009. April 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 how inter-domain multicast routing will function
   in an environment where Locator/ID Separation is deployed using the
   LISP architecture.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  6
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Source Addresses versus Group Addresses  . . . . . . . . . . . 12
   6.  Locator Reachability Implications on LISP-Multicast  . . . . . 13
   7.  Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14
   8.  LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16
     8.1.  ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16
       8.1.1.  Multiple RLOCs for an ITR  . . . . . . . . . . . . . . 16
     8.2.  ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17
     8.3.  Replication Locations  . . . . . . . . . . . . . . . . . . 17
   9.  LISP-Multicast Interworking  . . . . . . . . . . . . . . . . . 19
     9.1.  LISP and non-LISP Mixed Sites  . . . . . . . . . . . . . . 19
       9.1.1.  LISP Source Site to non-LISP Receiver Sites  . . . . . 20
       9.1.2.  Non-LISP Source Site to non-LISP Receiver Sites  . . . 21
       9.1.3.  Non-LISP Source Site to Any Receiver Site  . . . . . . 22
       9.1.4.  Unicast LISP Source Site to Any Receiver  Sites  . . . 22
       9.1.5.  LISP Source Site to Any Receiver Sites . . . . . . . . 23
     9.2.  LISP Sites with Mixed Address Families . . . . . . . . . . 23
     9.3.  Making a Multicast Interworking Decision . . . . . . . . . 25
   10. Considerations when RP Addresses are Embedded in Group
       Addresses  . . . . . . . . . . . . . . . . . . . . . . . . . . 26
   11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 27
   12. Mtrace Considerations  . . . . . . . . . . . . . . . . . . . . 28
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 30
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 31
     15.2. Informative References . . . . . . . . . . . . . . . . . . 31
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 33
     A.1.  Changes to draft-ietf-lisp-multicsat-02.txt  . . . . . . . 33
     A.2.  Changes to draft-ietf-lisp-multicsat-01.txt  . . . . . . . 33
     A.3.  Changes to draft-ietf-lisp-multicsat-00.txt  . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 34

1.  Requirements Notation

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

2.  Introduction

   The Locator/ID Separation Architecture [LISP] provides a mechanism to
   separate out Identification and Location semantics from the current
   definition of an IP address.  By creating two namespaces, an EID
   namespace used by sites and a Locator (RLOC) namespace used by core
   routing, the core routing infrastructure can scale by doing
   topological aggregation of routing information.

   Since LISP creates a new namespace, a mapping function must exist to
   map a site's EID prefixes to its associated locators.  For unicast
   packets, both the source address and destination address must be
   mapped.  For multicast packets, only the source address needs to be
   mapped.  The destination group address doesn't need to be mapped
   because the semantics of an IPv4 or IPv6 group address are logical in
   nature and not topology-dependent.  Therefore, this specifications
   focuses on to map a source EID address of a multicast flow during
   distribution tree setup and packet delivery.

   This specification will address the following scenarios:

   1.  How a multicast source host in a LISP site sends multicast
       packets to receivers inside of its site as well as to receivers
       in other sites that are LISP enabled.

   2.  How inter-domain (or between LISP sites) multicast distribution
       trees are built and how forwarding of multicast packets leaving a
       source site toward receivers sites is performed.

   3.  What protocols are affected and what changes are required to such
       multicast protocols.

   4.  How ASM-mode, SSM-mode, and Bidir-mode service models will
       operate.

   5.  How multicast packet flow will occur for multiple combinations of
       LISP and non-LISP capable source and receiver sites, for example:

       A.  How multicast packets from a source host in a LISP site are
           sent to receivers in other sites when they are all non-LISP
           sites.

       B.  How multicast packets from a source host in a LISP site are
           sent to receivers in both LISP-enabled sites and non-LISP
           sites.

       C.  How multicast packets from a source host in a non-LISP site
           are sent to receivers in other sites when they are all LISP-
           enabled sites.

       D.  How multicast packets from a source host in a non-LISP site
           are sent to receivers in both LISP-enabled sites and non-LISP
           sites.

   This specification focuses on what changes are needed to the
   multicast routing protocols to support LISP-Multicast as well as
   other protocols used for inter-domain multicast, such as Multi-
   protocol BGP (MBGP) [RFC4760].  The approach proposed in this
   specification requires no changes to the multicast infrastructure
   inside of a site when all sources and receivers reside in that site,
   even when the site is LISP enabled.  That is, internal operation of
   multicast is unchanged regardless of whether or not the site is LISP
   enabled or whether or not receivers exist in other sites which are
   LISP-enabled.

   Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],
   and PIM-SSM [RFC4607].  Bidir-PIM [RFC5015], which typically does not
   run in an inter-domain environment is not addressed in depth in this
   version of the specification.

   Also, the current version of this specification does not describe
   multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR
   descriptions in [LISP].

3.  Definition of Terms

   The terminology in this section is consistent with the definitions in
   [LISP] but is extended specifically to deal with the application of
   the terminology to multicast routing.

   LISP-Multicast:   a reference to the design in this specification.
      That is, when any site that is participating in multicast
      communication has been upgraded to be a LISP site, the operation
      of control-plane and data-plane protocols is considered part of
      the LISP-Multicast architecture.

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source address field of the first (most inner) LISP
      header of a multicast packet.  The host obtains a destination
      group address the same way it obtains one today, as it would when
      it is a non-LISP site.  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 the host is located in.  An EID can be used by a host to
      refer to another host, as when it joins an SSM (S-EID,G) route
      using IGMP version 3 [RFC4604].  LISP uses Provider Independent
      (PI) blocks for EIDs; such 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.

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

   Ingress Tunnel Router (ITR):   a router which accepts an IP multicast
      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 multicast address opaquely so it doesn't need to
      perform a map lookup on the group address because it is
      topologically insignificant.  The router then prepends an "outer"
      IP header with one of its globally-routable RLOCs as the source
      address field.  This RLOC is known to other multicast receiver
      sites which have used the mapping database to join a multicast
      tree for which the ITR is the root.  In general, an ITR receives
      IP packets from site end systems on one side and sends LISP-
      encapsulated multicast IP packets out all external interfaces
      which have been joined.

      An ITR would receive a multicast packet from a source inside of
      its site when 1) it is on the path from the multicast source to
      internally joined receivers, or 2) when it is on the path from the
      multicast source to externally joined receivers.

   Egress Tunnel Router (ETR):   a router that is on the path from a
      multicast source host in another site to a multicast receiver in
      its own site.  An ETR accepts a PIM Join/Prune message from a site
      internal PIM router destined for the source's EID in the multicast
      source site.  The ETR maps the source EID in the Join/Prune
      message to an RLOC address based on the EID-to-RLOC mapping.  This
      sets up the ETR to accept multicast encapsulated packets from the
      ITR in the source multicast site.  A multicast ETR decapsulates
      multicast encapsulated packets and replicates them on interfaces
      leading to internal receivers.

   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 can be at the
      CE router.

   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 headers and an ETR strips headers.  A LISP encapsulated
      multicast packet will have an "inner" header with the source EID
      in the source field; an "outer" header with the source RLOC in the
      source field: and the same globally unique group address in the
      destination field of both the inner and outer header.

   (S,G) State:   the formal definition is in the PIM Sparse Mode
      [RFC4601] specification.  For this specification, the term is used
      generally to refer to multicast state.  Based on its topological
      location, the (S,G) state resides in routers can be either
      (S-EID,G) state (at a location where the (S,G) state resides) or
      (S-RLOC,G) state (in the Internet core).

   (S-EID,G) State:   refers to multicast state in multicast source and
      receiver sites where S-EID is the IP address of the multicast
      source host (its EID).  An S-EID can appear in an IGMPv3 report,
      an MSDP SA message or a PIM Join/Prune message that travels inside
      of a site.

   (S-RLOC,G) State:   refers to multicast state in the core where S is
      a source locator (the IP address of a multicast ITR) of a site
      with a multicast source.  The (S-RLOC,G) is mapped from (S-EID,G)
      entry by doing a mapping database lookup for the EID prefix that
      S-EID maps to.  An S-RLOC can appear in a PIM Join/Prune message
      when it travels from an ETR to an ITR over the Internet core.

   uLISP Site:   a unicast only LISP site according to [LISP] which has
      not deployed the procedures of this specification and therefore,
      for multicast purposes, follows the procedures from Section 9.

   mPTR:   this is a multicast PTR that is responsible for advertising a
      very coarse EID prefix which non-LISP and uLISP sites can target
      their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP
      source multicast sites can send multicast packets using source
      addresses from the EID namespace. mPTRs act as Proxy ETRs for
      supporting multicast routing in a LISP infrastructure.

   Mixed Locator-Sets:   this is a locator-set for a LISP database
      mapping entry where the RLOC addresses in the locator-set are in
      both IPv4 and IPv6 format.

   Unicast Encapsulated PIM Join/Prune Message:   this is a standard PIM
      Join/Prune message (LISP encapsulated (encapsulated in a LISP Encapsulated Control
      Message with destination UDP port
      4341) 4342) which is sent by ETRs at
      multicast receiver sites to an ITR at a multicast source site.
      This message is sent periodically as long as there are interfaces
      in the oif-list for the (S-EID,G) entry the ETR is joining for.

4.  Basic Overview

   LISP, when used for unicast routing, increases the site's ability to
   control ingress traffic flows.  Egress traffic flows are controlled
   by the IGP in the source site.  For multicast, the IGP coupled with
   PIM can decide which path multicast packets ingress.  By using the
   traffic engineering features of LISP, a multicast source site can
   control the egress of its multicast traffic.  By controlling the
   priorities of locators from a mapping database entry, a source
   multicast site can control which way multicast receiver sites join to
   the source site.

   At this point in time, we don't see a requirement for different
   locator-sets, priority, and weight policies for multicast than we
   have for unicast.

   The fundamental multicast forwarding model is to encapsulate a
   multicast packet into another multicast packet.  An ITR will
   encapsulate multicast packets received from sources that it serves in
   another LISP multicast header.  The destination group address from
   the inner header is copied to the destination address of the outer
   header.  The inner source address is the EID of the multicast source
   host and the outer source address is the RLOC of the encapsulating
   ITR.

   The LISP-Multicast architecture will follow this high-level protocol
   and operational sequence:

   1.  Receiver hosts in multicast sites will join multicast content the
       way they do today, they use IGMP.  When they use IGMPv3 where
       they specify source addresses, they use source EIDs, that is they
       join (S-EID,G).  If the S-EID is a local multicast source host.
       If the multicast source is external to this receiver site, the
       PIM Join/Prune message flows toward the ETRs, finding the
       shortest exit (that is the closest exit for the Join/Prune
       message but it is the closest entrance for the multicast packet
       to the receiver).

   2.  The ETR does a mapping database lookup for S-EID.  If the mapping
       is cached from a previous lookup (from either a previous Join/
       Prune for the source multicast site or a unicast packet that went
       to the site), it will use the RLOC information from the mapping.
       The ETR will use the same priority and weighting mechanism as for
       unicast.  So the source site can decide which way multicast
       packets egress.

   3.  The ETR will build two PIM Join/Prune messages, one that contains
       a (S-EID,G) entry that is unicast to the ITR that matches the
       RLOC the ETR selects, and the other which contains a (S-RLOC,G)
       entry so the core network can create multicast state from this
       ETR to the ITR.

   4.  When the ITR gets the unicast Join/Prune message (see Section 3
       for formal definition), it will process (S-EID,G) entries in the
       message and propagate them inside of the site where it has
       explicit routing information for EIDs via the IGP.  When the ITR
       receives the (S-RLOC,G) PIM Join/Prune message it will process it
       like any other join it would get in today's Internet.  The S-RLOC
       address is the IP address of this ITR.

   5.  At this point there is (S-EID,G) state from the joining host in
       the receiver multicast site to the ETR of the receiver multicast
       site.  There is (S-RLOC,G) state across the core network from the
       ETR of the multicast receiver site to the ITR in the multicast
       source site and (S-EID,G) state in the source multicast site.
       Note, the (S-EID,G) state is the same S-EID in each multicast
       site.  As other ETRs join the same multicast tree, they can join
       through the same ITR (in which case the packet replication is
       done in the core) or a different ITR (in which case the packet
       replication is done at the source site).

   6.  When a packet is originated by the multicast host in the source
       site, it will flow to one or more ITRs which will prepend a LISP
       header by copying the group address to the outer destination
       address field and insert its own locator address in the outer
       source address field.  The ITR will look at its (S-RLOC,G) state,
       where S-RLOC is its own locator address, and replicate the packet
       on each interface a (S-RLOC,G) joined was received on.  The core
       has (S-RLOC,G) so where fanout occurs to multiple sites, a core
       router will do packet replication.

   7.  When either the source site or the core replicates the packet,
       the ETR will receive a LISP packet with a destination group
       address.  It will also decapsulate packets because it has
       receivers for the group.  Otherwise, it would have not received
       the packets because it would not have joined.  The ETR
       decapsulates and does a (S-EID,G) lookup in its multicast FIB to
       forward packets out one or more interfaces to forward the packet
       to internal receivers.

   This architecture is consistent and scalable with the architecture
   presented in [LISP] where multicast state in the core operates on
   locators and multicast state at the sites operates on EIDs.

   Alternatively, [LISP] does present a mechanism where (S-EID,G) state
   can reside in the core through the use of RPF-vectors [RPFV] in PIM
   Join/Prune messages.  However, this will require EID state in core as
   well as the use of RPF-vector formatted Join/Prune messages which are
   not the default implementation choice.  So we choose a design that
   can allow the separation of namespaces as unicast LISP provides.  It
   will be at the expense of creating new (S-RLOC,G) state when ITRs go
   unreachable.  See Section 5 for details.

   However, we have some observations on the algorithm above.  We can
   scale the control plane but at the expense of sending data to sites
   which may have not joined the distribution tree where the
   encapsulated data is being delivered.  For example, one site joins
   (S-EID1,G) and another site joins (S-EID2,G).  Both EIDs are in the
   same multicast source site.  Both multicast receiver sites join to
   the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the
   ITR.  The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the
   site.  The ITR receives (S-RLOC,G) joins and populates the oif-list
   state for it.  Since both (S-EID1,G) and (S-EID2, G) map to the one
   (S-RLOC,G) packets will be delivered by the core to both multicast
   receiver sites even though each have joined a single source-based
   distribution tree.  This behavior is a consequence of the many-to-one
   mapping between S-EIDs and a S-RLOC.

   There is a possible solution to this problem which reduces the number
   of many-to-one occurrences of (S-EID,G) entries aggregating into a
   single (S-RLOC,G) entry.  If a physical ITR can be assigned multiple
   RLOC addresses and these addresses are advertised in mapping database
   entries, then ETRs at receiver sites have more RLOC address options
   and therefore can join different (RLOC,G) entries for each (S-EID,G)
   entry joined at the receiver site.  It would not scale to have a one-
   to-one relationship between the number of S-EID sources at a source
   site and the number of RLOCs assigned to all ITRs at the site, but we
   can reduce the "n" to a smaller number in the "n-to-1" relationship.
   And in turn, reduce the opportunity for data packets to be delivered
   to sites for groups not joined.

5.  Source Addresses versus Group Addresses

   Multicast group addresses don't have to be associated with either the
   EID or RLOC namespace.  They actually are a namespace of their own
   that can be treated as logical with relatively opaque allocation.
   So, by their nature, they don't detract from an incremental
   deployment of LISP-Multicast.

   As for source addresses, as in the unicast LISP scenario, there is a
   decoupling of identification from location.  In a LISP site, packets
   are originated from hosts using their allocated EIDs, those addresses
   are used to identify the host as well as where in the site's topology
   the host resides but not how and where it is attached to the
   Internet.

   Therefore, when multicast distribution tree state is created anywhere
   in the network on the path from any multicast receiver to a multicast
   source, EID state is maintained at the source and receiver multicast
   sites, and RLOC state is maintained in the core.  That is, a
   multicast distribution tree will be represented as a 3-tuple of
   {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the
   3-tuple is the state stored in routers from the source to one or more
   ITRs in the source multicast site, the second element of the 3-tuple
   is the state stored in routers downstream of the ITR, in the core, to
   all LISP receiver multicast sites, and the third element in the
   3-tuple is the state stored in the routers downstream of each ETR, in
   each receiver multicast site, reaching each receiver.  Note that
   (S-EID,G) is the same in both the source and receiver multicast
   sites.

   The concatenation/mapping from the first element to the second
   element of the 3-tuples is done by the ITR and from the second
   element to the third element is done at the ETRs.

6.  Locator Reachability Implications on LISP-Multicast

   Multicast state as it is stored in the core is always (S,G) state as
   it exists today or (S-RLOC,G) state as it will exist when LISP sites
   are deployed.  The core routers cannot distinguish one from the
   other.  They don't need to because it is state that RPFs against the
   core routing tables in the RLOC namespace.  The difference is where
   the root of the distribution tree for a particular source is.  In the
   traditional multicast core, the source S is the source host's IP
   address.  For LISP-Multicast the source S is a single ITR of the
   multicast source site.

   An ITR is selected based on the LISP EID-to-RLOC mapping used when an
   ETR propagates a PIM Join/Prune message out of a receiver multicast
   site.  The selection is based on the same algorithm an ITR would use
   to select an ETR when sending a unicast packet to the site.  In the
   unicast case, the ITR can change on a per-packet basis depending on
   the reachability of the ETR.  So an ITR can change relatively easily
   using local reachability state.  However, in the multicast case, when
   an ITR goes unreachable, new distribution tree state must be built
   because the encapsulating root has changed.  This is more significant
   than an RPF-change event, where any router would typically locally
   change its RPF-interface for its existing tree state.  But when an
   encapsulating LISP-Multicast ITR goes unreachable, new distribution
   state must be rebuilt and reflect the new encapsulator.  Therefore,
   when an ITR goes unreachable, all ETRs that are currently joined to
   that ITR will have to trigger a new Join/Prune message for (S-RLOC,G)
   to the new ITR as well as send a unicast encapsulated Join/Prune
   message telling the new ITR which (S-EID,G) is being joined.

   This issue can be mitigated by using anycast addressing for the ITRs
   so the problem does reduce to an RPF change in the core, but still
   requires a unicast encapsulated Join/Prune message to tell the new
   ITR about (S-EID,G).  The problem with this approach is that the ETR
   really doesn't know when the ITR has changed so the new anycast ITR
   will get the (S-EID,G) state only when the ETR sends it the next time
   during its periodic sending procedures.

7.  Multicast Protocol Changes

   A number of protocols are used today for inter-domain multicast
   routing:

   IGMPv1-v3, MLDv1-v2:   These protocols do not require any changes for
      LISP-Multicast for two reasons.  One being that they are link-
      local and not used over site boundaries and second they advertise
      group addresses that don't need translation.  Where source
      addresses are supplied in IGMPv3 and MLDv2 messages, they are
      semantically regarded as EIDs and don't need to be converted to
      RLOCs until the multicast tree-building protocol, such as PIM, is
      received by the ETR at the site boundary.  Addresses used for IGMP
      and MLD come out of the source site's allocated addresses which
      are therefore from the EID namespace.

   MBGP:   Even though MBGP is not a multicast routing protocol, it is
      used to find multicast sources when the unicast BGP peering
      topology and the multicast MBGP peering topology are not
      congruent.  When MBGP is used in a LISP-Multicast environment, the
      prefixes which are advertised are from the RLOC namespace.  This
      allows receiver multicast sites to find a path to the source
      multicast site's ITRs.  MBGP peering addresses will be from the
      RLOC namespace.

   MSDP:   MSDP is used to announce active multicast sources to other
      routing domains (or LISP sites).  The announcements come from the
      PIM Rendezvous Points (RPs) from sites where there are active
      multicast sources sending to various groups.  In the context of
      LISP-Multicast, the source addresses advertised in MSDP will
      semantically be from the EID namespace since they describe the
      identity of a source multicast host.  It will be true that the
      state stored in MSDP caches from core routers will be from the EID
      namespace.  An RP address inside of site will be from the EID
      namespace so it can be advertised and reached by internal unicast
      routing mechanism.  However, for MSDP peer-RPF checking to work
      properly across sites, the RP addresses must be converted or
      mapped into a routable address that is advertised and maintained
      in the BGP routing tables in the core.  MSDP peering addresses can
      come out of either the EID or a routable address namespace.  And
      the choice can be made unilaterally because the ITR at the site
      will determine which namespace the destination peer address is out
      of by looking in the mapping database service.

   PIM-SSM:   In the simplest form of distribution tree building, when
      PIM operates in SSM mode, a source distribution tree is built and
      maintained across site boundaries.  In this case, there is a small
      modification to the operation of the PIM protocol (but not to any
      message format) to support taking a Join/Prune message originated
      inside of a LISP site with embedded addresses from the EID
      namespace and converting them to addresses from the RLOC namespace
      when the Join/Prune message crosses a site boundary.  This is
      similar to the requirements documented in [MNAT].

   PIM-Bidir:   Bidirectional PIM is typically run inside of a routing
      domain, but if deployed in an inter-domain environment, one would
      have to decide if the RP address of the shared-tree would be from
      the EID namespace or the RLOC namespace.  If the RP resides in a
      site-based router, then the RP address is from the EID namespace.
      If the RP resides in the core where RLOC addresses are routed,
      then the RP address is from the RLOC namespace.  This could be
      easily distinguishable if the EID address were well-known address
      allocation block from the RLOC namespace.  Also, when using
      Embedded-RP for RP determination [RFC3956], the format of the
      group address could indicate the namespace the RP address is from.
      However, refer to Section 10 for considerations core routers need
      to make when using Embedded-RP IPv6 group addresses.  When using
      Bidir-PIM for inter-domain multicast routing, it is recommended to
      use staticly configured RPs so core routers think the Bidir group
      is associated with an ITR's RLOC as the RP address and site
      routers think the Bidir group is associated with the site resident
      RP with an EID address.  With respect to DF-election in Bidir PIM,
      no changes are required since all messaging and addressing is
      link-local.

   PIM-ASM:   The ASM mode of PIM, the most popular form of PIM, is
      deployed in the Internet today is by having shared-trees within a
      site and using source-trees across sites.  By the use of MSDP and
      PIM-SSM techniques described above, we can get multicast
      connectivity across LISP sites.  Having said that, that means
      there are no special actions required for processing (*,G) or
      (S,G,R) Join/Prune messages since they all operate against the
      shared-tree which is site resident.  Just like with ASM, there is
      no (*,G) in the core when LISP-Multicast is in use.  This is also
      true for the RP-mapping mechanisms Auto-RP and BSR.

   Based on the protocol description above, the conclusion is that there
   are no protocol message format changes, just a translation function
   performed at the control-plane.  This will make for an easier and
   faster transition for LISP since fewer components in the network have
   to change.

   It should also be stated just like it is in [LISP] that no host
   changes, whatsoever, are required to have a multicast source host
   send multicast packets and for a multicast receiver host to receive
   multicast packets.

8.  LISP-Multicast Data-Plane Architecture

   The LISP-Multicast data-plane operation conforms to the operation and
   packet formats specified in [LISP].  However, encapsulating a
   multicast packet from an ITR is a much simpler process.  The process
   is simply to copy the inner group address to the outer destination
   address.  And to have the ITR use its own IP address (its RLOC), and
   as the source address.  The process is simpler for multicast because
   there is no EID-to-RLOC mapping lookup performed during packet
   forwarding.

   In the decapsulation case, the ETR simply removes the outer header
   and performs a multicast routing table lookup on the inner header
   (S-EID,G) addresses.  Then the oif-list for the (S-EID,G) entry is
   used to replicate the packet on site-facing interfaces leading to
   multicast receiver hosts.

   There is no Data-Probe logic for ETRs as there can be in the unicast
   forwarding case.

8.1.  ITR Forwarding Procedure

   The following procedure is used by an ITR, when it receives a
   multicast packet from a source inside of its site:

   1.  A multicast data packet sent by a host in a LISP site will have
       the source address equal to the host's EID and the destination
       address equal to the group address of the multicast group.  It is
       assumed the group information is obtained by current methods.
       The same is true for a multicast receiver to obtain the source
       and group address of a multicast flow.

   2.  When the ITR receives a multicast packet, it will have both S-EID
       state and S-RLOC state stored.  Since the packet was received on
       a site-facing interface, the RPF lookup is based on the S-EID
       state.  If the RPF check succeeds, then the oif-list contains
       interfaces that are site-facing and external-facing.  For the
       site-facing interfaces, no LISP header is prepended.  For the
       external-facing interfaces a LISP header is prepended.  When the
       ITR prepends a LISP header, it uses its own RLOC address as the
       source address and copies the group address supplied by the IP
       header the host built as the outer destination address.

8.1.1.  Multiple RLOCs for an ITR

   Typically, an ITR will have a single RLOC address but in some cases
   there could be multiple RLOC addresses assigned from either the same
   or different service providers.  In this case when (S-RLOC,G) Join/
   Prune messages are received for each RLOC, there is a oif-list
   merging action that must take place.  Therefore, when a packet is
   received from a site-facing interface that matches on a (S-EID,G)
   entry, the interfaces of the oif-list from all (RLOC,G) entries
   joined to the ITR as well as the site-facing oif-list joined for
   (S-EID,G) must be part be included in packet replication.  In
   addition to replicating for all types of oif-lists, each oif entry
   must be tagged with the RLOC address, so encapsulation uses the outer
   source address for the RLOC joined.

8.2.  ETR Forwarding Procedure

   The following procedure is used by an ETR, when it receives a
   multicast packet from a source outside of its site:

   1.  When a multicast data packet is received by an ETR on an
       external-facing interface, it will do an RPF lookup on the S-RLOC
       state it has stored.  If the RPF check succeeds, the interfaces
       from the oif-list are used for replication to interfaces that are
       site-facing as well as interfaces that are external-facing (this
       ETR can also be a transit multicast router for receivers outside
       of its site).  When the packet is to be replicated for an
       external-facing interface, the LISP encapsulation header are not
       stripped.  When the packet is replicated for a site-facing
       interface, the encapsulation header is stripped.

   2.  The packet without a LISP header is now forwarded down the
       (S-EID,G) distribution tree in the receiver multicast site.

8.3.  Replication Locations

   Multicast packet replication can happen in the following topological
   locations:

   o  In an IGP multicast router inside a site which operates on S-EIDs.

   o  In a transit multicast router inside of the core which operates on
      S-RLOCs.

   o  At one or more ETR routers depending on the path a Join/Prune
      message exits a receiver multicast site.

   o  At one or more ITR routers in a source multicast site depending on
      what priorities are returned in a Map-Reply to receiver multicast
      sites.

   In the last case the source multicast site can do replication rather
   than having a single exit from the site.  But this only can occur
   when the priorities in the Map-Reply are modified for different
   receiver multicast site so that the PIM Join/Prune messages arrive at
   different ITRs.

   This policy technique, also used in [ALT] for unicast, is useful for
   multicast to mitigate the problems of changing distribution tree
   state as discussed in Section 6.

9.  LISP-Multicast Interworking

   This section will describe the multicast corollary to [INTWORK] which
   describes the interworking of multicast routing among LISP and non-
   LISP sites.

9.1.  LISP and non-LISP Mixed Sites

   Since multicast communication can involve more than two entities to
   communicate together, the combinations of interworking scenarios are
   more involved.  However, the state maintained for distribution trees
   at the sites is the same regardless of whether or not the site is
   LISP enabled or not.  So most of the implications are in the core
   with respect to storing routable EID prefixes from either PA or PI
   blocks.

   Before we enumerate the multicast interworking scenarios, we must
   define 3 deployment states of a site:

   o  A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it
      does today.  The addresses for the site are globally routable.

   o  A site that deploys LISP for unicast routing.  The addresses for
      the site are not globally routable.  Let's define the name for
      this type of site as a uLISP site.

   o  A site that deploys LISP for both unicast and multicast routing.
      The addresses for the site are not globally routable.  Let's
      define the name for this type of site as a LISP-Multicast site.

   We will not consider a LISP site enabled for multicast purposes only
   but do consider a uLISP site as documented in [INTWORK].  In this
   section we don't discuss how a LISP site sends multicast packets when
   all receiver sites are LISP-Multicast enabled; that has been
   discussed in previous sections.

   The following scenarios exist to make LISP-Multicast sites interwork
   with non-LISP-Multicast sites:

   1.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of non-LISP sites and uLISP sites.

   2.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of non-LISP sites and uLISP sites.

   3.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of LISP sites, uLISP sites, and
       non-LISP sites.

   4.  A uLISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

   5.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

9.1.1.  LISP Source Site to non-LISP Receiver Sites

   In the first scenario, a site is LISP capable for both unicast and
   multicast traffic and as such operates on EIDs.  Therefore there is a
   possibility that the EID prefix block is not routable in the core.
   For LISP receiver multicast sites this isn't a problem but for non-
   LISP or uLISP receiver multicast sites, when a PIM Join/Prune message
   is received by the edge router, it has no route to propagate the
   Join/Prune message out of the site.  This is no different than the
   unicast case that LISP-NAT in [INTWORK] solves.

   LISP-NAT allows a unicast packet that exits a LISP site to get its
   source address mapped to a globally routable address before the ITR
   realizes that it should not encapsulate the packet destined to a non-
   LISP site.  For a multicast packet to leave a LISP site, distribution
   tree state needs to be built so the ITR can know where to send the
   packet.  So the receiver multicast sites need to know about the
   multicast source host by its routable address and not its EID
   address.  When this is the case, the routable address is the
   (S-RLOC,G) state that is stored and maintained in the core routers.
   It is important to note that the routable address for the host cannot
   be the same as an RLOC for the site.  Because we want the ITRs to
   process a received PIM Join/Prune message from an external-facing
   interface to be propagated inside of the site so the site-part of the
   distribution tree is built.

   Using a globally routable source address allows non-LISP and uLISP
   multicast receiver to join, create, and maintain a multicast
   distribution tree.  However, the LISP multicast receiver site will
   want to perform an EID-to-RLOC mapping table lookup when a PIM Join/
   Prune message is received on a site-facing interface.  It does this
   because it wants to find a (S-RLOC,G) entry to Join in the core.  So
   we have a conflict of behavior between the two types of sites.

   The solution to this problem is the same as when an ITR wants to send
   a unicast packet to a destination site but needs determine if the
   site is LISP capable or not.  When it is not LISP capable, the ITR
   does not encapsulate the packet.  So for the multicast case, when ETR
   receives a PIM Join/Prune message for (S-EID,G) state, it will do a
   mapping table lookup on S-EID.  In this case, S-EID is not in the
   mapping database because the source multicast site is using a
   routable address and not an EID prefix address.  So the ETR knows to
   simply propagate the PIM Join/Prune message to a external-facing
   interface without converting the (S-EID,G) because it is an (S,G)
   where S is routable and reachable via core routing tables.

   Now that the multicast distribution tree is built and maintained from
   any non-LISP or uLISP receiver multicast site, the way packet
   forwarding model is performed can be explained.

   Since the ITR in the source multicast site has never received a
   unicast encapsulated PIM Join/Prune message from any ETR in a
   receiver multicast site, it knows there are no LISP-Multicast
   receiver sites.  Therefore, there is no need for the ITR to
   encapsulate data.  Since it will know a priori (via configuration)
   that its site's EIDs are not routable, it assumes that the multicast
   packets from the source host are sent by a routable address.  That
   is, it is the responsibility of the multicast source host's system
   administrator to ensure that the source host sends multicast traffic
   using a routable source address.  When this happens, the ITR acts
   simply as a router and forwards the multicast packet like an ordinary
   multicast router.

   There is an alternative to using a LISP-NAT scheme just like there is
   for unicast [INTWORK] forwarding by using Proxy Tunnel Routers
   (PTRs).  This can work the same way for multicast routing as well,
   but the difference is that non-LISP and uLISP sites will send PIM
   Join/Prune messages for (S-EID,G) which make their way in the core to
   PTRs.  Let's call this use of a PTR as a "Multicast PTR" (or mPTR).
   Since the PTRs advertise very coarse EID prefixes, they draw the PIM
   Join/Prune control traffic making them the target of the distribution
   tree.  To get multicast packets from the LISP source multicast sites,
   the tree needs to be built on the path from the mPTR to the LISP
   source multicast site.  To make this happen the mPTR acts as a "Proxy
   ETR" (where in unicast it acts as a "Proxy ITR").

   The existence of mPTRs in the core allows LISP source multicast site
   ITRs to encapsulate multicast packets so the state built between the
   ITRs and the mPTRs is (S-RLOC,G) state.  Then the mPTRs can
   decapsulate packets and forward natively to the non-LISP and uLISP
   receiver multicast sites.

9.1.2.  Non-LISP Source Site to non-LISP Receiver Sites

   Clearly non-LISP multicast sites can send multicast packets to non-
   LISP receiver multicast sites.  That is what they do today.  However,
   discussion is required to show how non-LISP multicast sites send
   multicast packets to uLISP receiver multicast sites.

   Since uLISP receiver multicast sites are not targets of any (S,G)
   state, they simply send (S,G) PIM Join/Prune messages toward the non-
   LISP source multicast site.  Since the source multicast site, in this
   case has not been upgraded to LISP, all multicast source host
   addresses are routable.  So this case is simplified to where a uLISP
   receiver multicast site looks to the source multicast site as a non-
   LISP receiver multicast site.

9.1.3.  Non-LISP Source Site to Any Receiver Site

   When a non-LISP source multicast site has receivers in either a non-
   LISP/uLISP site or a LISP site, one needs to decide how the LISP
   receiver multicast site will attach to the distribution tree.  We
   know from Section 9.1.2 that non-LISP and uLISP receiver multicast
   sites can join the distribution tree, but a LISP receiver multicast
   site ETR will need to know if the source address of the multicast
   source host is routable or not.  We showed in Section 9.1.1 that an
   ETR, before it sends a PIM Join/Prune message on an external-facing
   interface, does a EID-to-RLOC mapping lookup to determine if it
   should convert the (S,G) state from a PIM Join/Prune message received
   on a site-facing interface to a (S-RLOC,G).  If the lookup fails, the
   ETR can conclude the source multicast site is a non-LISP site so it
   simply forwards the Join/Prune message (it also doesn't need to send
   a unicast encapsulated Join/Prune message because there is no ITR in
   a non-LISP site and there is namespace continuity between the ETR and
   source).

9.1.4.  Unicast LISP Source Site to Any Receiver  Sites

   In the last section, it was explained how an ETR in a multicast
   receiver site can determine if a source multicast site is LISP-
   enabled by looking into the mapping database.  When the source
   multicast site is a uLISP site, it is LISP enabled but the ITR, by
   definition is not capable of doing multicast encapsulation.  So for
   the purposes of multicast routing, the uLISP source multicast site is
   treated as non-LISP source multicast site.

   Non-LISP receiver multicast sites can join distribution trees to a
   uLISP source multicast site since the source site behaves, from a
   forwarding perspective, as a non-LISP source site.  This is also the
   case for a uLISP receiver multicast site since the ETR does not have
   multicast functionality built-in or enabled.

   Special considerations are required for LISP receiver multicast sites
   since they think the source multicast site is LISP capable, the ETR
   cannot know if ITR is LISP-Multicast capable.  To solve this problem,
   each mapping database entry will have a multicast 2-tuple (Mpriority,
   Mweight) per RLOC.  When the Mpriority is set to 255, the site is
   considered not multicast capable.  So an ETR in a LISP receiver
   multicast site can distinguish whether a LISP source multicast site
   is LISP-Multicast site from a uLISP site.

9.1.5.  LISP Source Site to Any Receiver Sites

   When a LISP source multicast site has receivers in LISP, non-LISP,
   and uLISP receiver multicast sites, it has a conflict about how it
   sends multicast packets.  The ITR can either encapsulate or natively
   forward multicast packets.  Since the receiver multicast sites are
   heterogeneous in their behavior, one packet forwarding mechanism
   cannot satisfy both.  However, if a LISP receiver multicast site acts
   like a uLISP site then it could receive packets like a non-LISP
   receiver multicast site making all receiver multicast sites have
   homogeneous behavior.  However, this poses the following issues:

   o  LISP-NAT techniques with routable addresses would be required in
      all cases.

   o  Or alternatively, mPTR deployment would be required forcing coarse
      EID prefix advertisement in the core.

   o  But what is most disturbing is that when all sites that
      participate are LISP-Multicast sites but then a non-LISP or uLISP
      site joins the distribution tree, then the existing joined LISP
      receiver multicast sites would have to change their behavior.
      This would create too much dynamic tree-building churn to be a
      viable alternative.

   So the solution space options are:

   1.  Make the LISP ITR in the source multicast site send two packets,
       one that is encapsulated with (S-RLOC,G) to reach LISP receiver
       multicast sites and another that is not encapsulated with
       (S-EID,G) to reach non-LISP and uLISP receiver multicast sites.

   2.  Make the LISP ITR always encapsulate packets with (S-RLOC,G) to
       reach LISP-Multicast sites and to reach mPTRs that can
       decapsulate and forward (S-EID,G) packets to non-LISP and uLISP
       receiver multicast sites.

9.2.  LISP Sites with Mixed Address Families

   A LISP database mapping entry that describes the locator-set,
   Mpriority and Mweight per locator address (RLOC), for an EID prefix
   associated with a site could have RLOC addresses in either IPv4 or
   IPv6 format.  When a mapping entry has a mix of RLOC formatted
   addresses, it is an implicit advertisement by the site that it is a
   dual-stack site.  That is, the site can receive IPv4 or IPv6 unicast
   packets.

   To distinguish if the site can receive dual-stack unicast packets as
   well as dual-stack multicast packets, the Mpriority value setting
   will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format
   details.

   If you consider the combinations of LISP, non-LISP, and uLISP sites
   sharing the same distribution tree and considering the capabilities
   of supporting IPv4, IPv6, or dual-stack, the number of total
   combinations grows beyond comprehension.

   Using some combinatorial math, we have the following profiles of a
   site and the combinations that can occur:

   1.  LISP-Multicast IPv4 Site

   2.  LISP-Multicast IPv6 Site

   3.  LISP-Multicast Dual-Stack Site

   4.  uLISP IPv4 Site

   5.  uLISP IPv6 Site

   6.  uLISP Dual-Stack Site

   7.  non-LISP IPv4 Site

   8.  non-LISP IPv6 Site

   9.  non-LISP Dual-Stack Site

   Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to
   illustrate some combinatorial math below.

   When 1 site talks to another site, the combinatorial is (9 2), when 1
   site talks to another 2 sites, the combinatorial is (9 3).  If sum
   this up to (9 9), we have:

   (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =

     36  +   84  +  126  +  126  +   84  +   36  +   9   +   1

   Which results in the total number of cases to be considered at 502.

   This combinatorial gets even worse when you consider a site using one
   address family inside of the site and the xTRs use the other address
   family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4
   RLOCs).

   To rationalize this combinatorial nightmare, there are some
   guidelines which need to be put in place:

   o  Each distribution tree shared among sites will either be an IPv4
      distribution tree or an IPv6 distribution tree.  Therefore, we can
      avoid head-end replication by building and sending packets on each
      address family based distribution tree.  Even though there might
      be an urge to do multicast packet translation from one address
      family format to the other, it is a non-viable over-complicated
      urge.

   o  All LISP sites on a multicast distribution tree must share a
      common address family which is determined by the source site's
      locator-set in its LISP database mapping entry.  All receiver
      multicast sites will use the best RLOC priority controlled by the
      source multicast site.  This is true when the source site is
      either LISP-Multicast or uLISP capable.  This means that priority-
      based policy modification is prohibited.

   o  When the source site is not LISP capable, it is up to how
      receivers find the source and group information for a multicast
      flow.  That mechanism decides the address family for the flow.

9.3.  Making a Multicast Interworking Decision

   This Multicast Interworking section has shown all combinations of
   multicast connectivity that could occur.  As you might have already
   concluded, this can be quite complicated and if the design is too
   ambitious, the dynamics of the protocol could cause a lot of
   instability.

   The trade-off decisions are hard to make and we want the same single
   solution to work for both IPv4 and IPv6 multicast.  It is imperative
   to have an incrementally deployable solution for all of IPv4 unicast
   and multicast and IPv6 unicast and multicast while minimizing (or
   eliminating) both unicast and multicast EID namespace state.

   Therefore the design decision to go with PTRs for unicast routing and
   mPTRs for multicast routing seems to be the sweet spot in the
   solution space so we can optimize state requirements and avoid head-
   end data replication at ITRs.

10.  Considerations when RP Addresses are Embedded in Group Addresses

   When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a
   technique exists to embed the unicast address of an RP in a IPv6
   group address [RFC3956].  When routers in end sites process a PIM
   Join/Prune message which contain an embedded-RP group address, they
   extract the RP address from the group address and treat it from the
   EID namespace.  However, core routers do not have state for the EID
   namespace, need to extract an RP address from the RLOC namespace.

   Therefore, it is the responsibility of ETRs in multicast receiver
   sites to map the group address into a group address where the
   embedded-RP address is from the RLOC namespace.  The mapped RP-
   address is obtained from a EID-to-RLOC mapping database lookup.  The
   ETR will also send a unicast (*,G) Join/Prune message to the ITR so
   the branch of the distribution tree from the source site resident RP
   to the ITR is created.

   This technique is no different than the techniques described in this
   specification for translating (S,G) state and propagating Join/Prune
   messages into the core.  The only difference is that the (*,G) state
   in Join/Prune messages are mapped because they contain unicast
   addresses encoded in an Embedded-RP group address.

11.  Taking Advantage of Upgrades in the Core

   If the core routers are upgraded to support [RPFV] and [RFC5496],
   then we can pass EID specific data through the core without,
   possibly, having to store the state in the core.

   By doing this we can eliminate the ETR from unicast encapsulating PIM
   Join/Prune messages to the source site's ITR.

   However, this solution is restricted to a small set of workable cases
   which would not be good for general use of LISP-Multicast.  In
   addition to slow convergence properties, it is not being recommended
   for LISP-Multicast.

12.  Mtrace Considerations

   Mtrace functionality must be consistent with unicast traceroute
   functionality where all hops from multicast receiver to multicast
   source are visible.

   The design for mtrace for use in LISP-Multicast environments is to be
   determined but should build upon the mtrace version 2 specified in
   [MTRACE].

13.  Security Considerations

   Refer to the [LISP] specification.

14.  Acknowledgments

   The authors would like to gratefully acknowledge the people who have
   contributed discussion, ideas, and commentary to the making of this
   proposal and specification.  People who provided expert review were
   Scott Brim, Greg Shepherd, and Dave Oran.  Other commentary from
   discussions at Summer 2008 Dublin IETF were Toerless Eckert and
   Ijsbrand Wijnands.

   We would also like to thank the MBONED working group for constructive
   and civil verbal feedback when this draft was presented at the Fall
   2008 IETF in Minneapolis.  In particular, good commentary came from
   Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou,
   Ron Bonica, and Lenny Guardino.

   An expert review of this specification was done by Yiqun Cai and
   Liming Wei. We thank them for their detailed comments.

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

15.  References

15.1.  Normative References

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

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

   [RFC3956]  Savola, P. and B. Haberman, "Embedding the Rendezvous
              Point (RP) Address in an IPv6 Multicast Address",
              RFC 3956, November 2004.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", RFC 4604, August 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, October 2007.

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

15.2.  Informative References

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

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

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-01.txt
              draft-ietf-lisp-05.txt (work in progress), May October 2009.

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

   [MNAT]     Wing, D. and T. Eckert, "Multicast Requirements for a
              Network Address (and  port) Translator (NAT)",
              draft-ietf-behave-multicast-07.txt (work in progress),
              June 2007.

   [MTRACE]   Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace
              Version 2: Traceroute Facility for IP Multicast",
              draft-ietf-mboned-mtrace-v2-03.txt (work in progress),
              March 2009.

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

Appendix A.  Document Change Log

A.1.  Changes to draft-ietf-lisp-multicsat-02.txt

   o  Posted October 2009.

   o  Added Document Change Log appendix.

   o  Specify that the LISP Encapsulated Control Message be used for
      unicasting PIM Join/Prune messages from ETRs to ITRs.

A.2.  Changes to draft-ietf-lisp-multicsat-01.txt

   o  Posted November 2008.

   o  Specified that PIM Join/Prune unicast messages that get sent from
      ETRs to ITRs of a source multicast site get LISP encapsulated in
      destination UDP port 4342.

   o  Add multiple RLOCs per ITR per Yiqun's comments.

   o  Indicate how static RPs can be used when LISP is run using Bidir-
      PIM in the core.

   o  Editorial changes per Liming comments.

   o  Add Mttrace Considersations section.

A.3.  Changes to draft-ietf-lisp-multicsat-00.txt

   o  Posted April 2008.

   o  Renamed from draft-farinacci-lisp-multicast-01.txt.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dino@cisco.com

   Dave Meyer
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   John Zwiebel
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: jzwiebel@cisco.com

   Stig Venaas
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: stig@cisco.com
--Apple-Mail-36-1016491758 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-36-1016491758 Content-Disposition: attachment; filename=draft-ietf-lisp-multicast-02.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-multicast-02.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental J. Zwiebel Expires: April 1, 2010 S. Venaas cisco Systems September 28, 2009 LISP for Multicast Environments (PROPOSED) draft-ietf-lisp-multicast-02.txt (NOT POSTED YET) 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 April 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. Farinacci, et al. Expires April 1, 2010 [Page 1] =0C Internet-Draft LISP for Multicast Environments September 2009 Abstract This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Source Addresses versus Group Addresses . . . . . . . . . . . 12 6. Locator Reachability Implications on LISP-Multicast . . . . . 13 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 16 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 19 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 19 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 20 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 21 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 22 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 22 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 23 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 23 9.3. Making a Multicast Interworking Decision . . . . . . . . . 25 10. Considerations when RP Addresses are Embedded in Group Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 27 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 28 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 15.2. Informative References . . . . . . . . . . . . . . . . . . 31 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 33 A.1. Changes to draft-ietf-lisp-multicsat-02.txt . . . . . . . 33 A.2. Changes to draft-ietf-lisp-multicsat-01.txt . . . . . . . 33 A.3. Changes to draft-ietf-lisp-multicsat-00.txt . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Farinacci, et al. Expires April 1, 2010 [Page 2] =0C Internet-Draft LISP for Multicast Environments September 2009 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]. Farinacci, et al. Expires April 1, 2010 [Page 3] =0C Internet-Draft LISP for Multicast Environments September 2009 2. Introduction The Locator/ID Separation Architecture [LISP] provides a mechanism to separate out Identification and Location semantics from the current definition of an IP address. By creating two namespaces, an EID namespace used by sites and a Locator (RLOC) namespace used by core routing, the core routing infrastructure can scale by doing topological aggregation of routing information. Since LISP creates a new namespace, a mapping function must exist to map a site's EID prefixes to its associated locators. For unicast packets, both the source address and destination address must be mapped. For multicast packets, only the source address needs to be mapped. The destination group address doesn't need to be mapped because the semantics of an IPv4 or IPv6 group address are logical in nature and not topology-dependent. Therefore, this specifications focuses on to map a source EID address of a multicast flow during distribution tree setup and packet delivery. This specification will address the following scenarios: 1. How a multicast source host in a LISP site sends multicast packets to receivers inside of its site as well as to receivers in other sites that are LISP enabled. 2. How inter-domain (or between LISP sites) multicast distribution trees are built and how forwarding of multicast packets leaving a source site toward receivers sites is performed. 3. What protocols are affected and what changes are required to such multicast protocols. 4. How ASM-mode, SSM-mode, and Bidir-mode service models will operate. 5. How multicast packet flow will occur for multiple combinations of LISP and non-LISP capable source and receiver sites, for example: A. How multicast packets from a source host in a LISP site are sent to receivers in other sites when they are all non-LISP sites. B. How multicast packets from a source host in a LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. C. How multicast packets from a source host in a non-LISP site are sent to receivers in other sites when they are all LISP- Farinacci, et al. Expires April 1, 2010 [Page 4] =0C Internet-Draft LISP for Multicast Environments September 2009 enabled sites. D. How multicast packets from a source host in a non-LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. This specification focuses on what changes are needed to the multicast routing protocols to support LISP-Multicast as well as other protocols used for inter-domain multicast, such as Multi- protocol BGP (MBGP) [RFC4760]. The approach proposed in this specification requires no changes to the multicast infrastructure inside of a site when all sources and receivers reside in that site, even when the site is LISP enabled. That is, internal operation of multicast is unchanged regardless of whether or not the site is LISP enabled or whether or not receivers exist in other sites which are LISP-enabled. Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not run in an inter-domain environment is not addressed in depth in this version of the specification. Also, the current version of this specification does not describe multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR descriptions in [LISP]. Farinacci, et al. Expires April 1, 2010 [Page 5] =0C Internet-Draft LISP for Multicast Environments September 2009 3. Definition of Terms The terminology in this section is consistent with the definitions in [LISP] but is extended specifically to deal with the application of the terminology to multicast routing. LISP-Multicast: a reference to the design in this specification. That is, when any site that is participating in multicast communication has been upgraded to be a LISP site, the operation of control-plane and data-plane protocols is considered part of the LISP-Multicast architecture. Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source address field of the first (most inner) LISP header of a multicast packet. The host obtains a destination group address the same way it obtains one today, as it would when it is a non-LISP site. 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 the host is located in. An EID can be used by a host to refer to another host, as when it joins an SSM (S-EID,G) route using IGMP version 3 [RFC4604]. LISP uses Provider Independent (PI) blocks for EIDs; such 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. Routing Locator (RLOC): the IPv4 or IPv6 address of an ingress tunnel router (ITR), the router in the multicast source host's site that encapsulates multicast packets. It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider Assigned (PA) addresses. Multiple RLOCs can be assigned to the same ITR device or to multiple ITR devices at a site. Ingress Tunnel Router (ITR): a router which accepts an IP multicast 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 multicast address opaquely so it doesn't need to perform a map lookup on the group address because it is topologically insignificant. The router then prepends an "outer" IP header with one of its globally-routable RLOCs as the source address field. This RLOC is known to other multicast receiver Farinacci, et al. Expires April 1, 2010 [Page 6] =0C Internet-Draft LISP for Multicast Environments September 2009 sites which have used the mapping database to join a multicast tree for which the ITR is the root. In general, an ITR receives IP packets from site end systems on one side and sends LISP- encapsulated multicast IP packets out all external interfaces which have been joined. An ITR would receive a multicast packet from a source inside of its site when 1) it is on the path from the multicast source to internally joined receivers, or 2) when it is on the path from the multicast source to externally joined receivers. Egress Tunnel Router (ETR): a router that is on the path from a multicast source host in another site to a multicast receiver in its own site. An ETR accepts a PIM Join/Prune message from a site internal PIM router destined for the source's EID in the multicast source site. The ETR maps the source EID in the Join/Prune message to an RLOC address based on the EID-to-RLOC mapping. This sets up the ETR to accept multicast encapsulated packets from the ITR in the source multicast site. A multicast ETR decapsulates multicast encapsulated packets and replicates them on interfaces leading to internal receivers. 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 can be at the CE router. 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 headers and an ETR strips headers. A LISP encapsulated multicast packet will have an "inner" header with the source EID in the source field; an "outer" header with the source RLOC in the source field: and the same globally unique group address in the destination field of both the inner and outer header. (S,G) State: the formal definition is in the PIM Sparse Mode [RFC4601] specification. For this specification, the term is used generally to refer to multicast state. Based on its topological location, the (S,G) state resides in routers can be either (S-EID,G) state (at a location where the (S,G) state resides) or (S-RLOC,G) state (in the Internet core). (S-EID,G) State: refers to multicast state in multicast source and receiver sites where S-EID is the IP address of the multicast source host (its EID). An S-EID can appear in an IGMPv3 report, an MSDP SA message or a PIM Join/Prune message that travels inside Farinacci, et al. Expires April 1, 2010 [Page 7] =0C Internet-Draft LISP for Multicast Environments September 2009 of a site. (S-RLOC,G) State: refers to multicast state in the core where S is a source locator (the IP address of a multicast ITR) of a site with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) entry by doing a mapping database lookup for the EID prefix that S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message when it travels from an ETR to an ITR over the Internet core. uLISP Site: a unicast only LISP site according to [LISP] which has not deployed the procedures of this specification and therefore, for multicast purposes, follows the procedures from Section 9. mPTR: this is a multicast PTR that is responsible for advertising a very coarse EID prefix which non-LISP and uLISP sites can target their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP source multicast sites can send multicast packets using source addresses from the EID namespace. mPTRs act as Proxy ETRs for supporting multicast routing in a LISP infrastructure. Mixed Locator-Sets: this is a locator-set for a LISP database mapping entry where the RLOC addresses in the locator-set are in both IPv4 and IPv6 format. Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM Join/Prune message (encapsulated in a LISP Encapsulated Control Message with destination UDP port 4342) which is sent by ETRs at multicast receiver sites to an ITR at a multicast source site. This message is sent periodically as long as there are interfaces in the oif-list for the (S-EID,G) entry the ETR is joining for. Farinacci, et al. Expires April 1, 2010 [Page 8] =0C Internet-Draft LISP for Multicast Environments September 2009 4. Basic Overview LISP, when used for unicast routing, increases the site's ability to control ingress traffic flows. Egress traffic flows are controlled by the IGP in the source site. For multicast, the IGP coupled with PIM can decide which path multicast packets ingress. By using the traffic engineering features of LISP, a multicast source site can control the egress of its multicast traffic. By controlling the priorities of locators from a mapping database entry, a source multicast site can control which way multicast receiver sites join to the source site. At this point in time, we don't see a requirement for different locator-sets, priority, and weight policies for multicast than we have for unicast. The fundamental multicast forwarding model is to encapsulate a multicast packet into another multicast packet. An ITR will encapsulate multicast packets received from sources that it serves in another LISP multicast header. The destination group address from the inner header is copied to the destination address of the outer header. The inner source address is the EID of the multicast source host and the outer source address is the RLOC of the encapsulating ITR. The LISP-Multicast architecture will follow this high-level protocol and operational sequence: 1. Receiver hosts in multicast sites will join multicast content the way they do today, they use IGMP. When they use IGMPv3 where they specify source addresses, they use source EIDs, that is they join (S-EID,G). If the S-EID is a local multicast source host. If the multicast source is external to this receiver site, the PIM Join/Prune message flows toward the ETRs, finding the shortest exit (that is the closest exit for the Join/Prune message but it is the closest entrance for the multicast packet to the receiver). 2. The ETR does a mapping database lookup for S-EID. If the mapping is cached from a previous lookup (from either a previous Join/ Prune for the source multicast site or a unicast packet that went to the site), it will use the RLOC information from the mapping. The ETR will use the same priority and weighting mechanism as for unicast. So the source site can decide which way multicast packets egress. Farinacci, et al. Expires April 1, 2010 [Page 9] =0C Internet-Draft LISP for Multicast Environments September 2009 3. The ETR will build two PIM Join/Prune messages, one that contains a (S-EID,G) entry that is unicast to the ITR that matches the RLOC the ETR selects, and the other which contains a (S-RLOC,G) entry so the core network can create multicast state from this ETR to the ITR. 4. When the ITR gets the unicast Join/Prune message (see Section 3 for formal definition), it will process (S-EID,G) entries in the message and propagate them inside of the site where it has explicit routing information for EIDs via the IGP. When the ITR receives the (S-RLOC,G) PIM Join/Prune message it will process it like any other join it would get in today's Internet. The S-RLOC address is the IP address of this ITR. 5. At this point there is (S-EID,G) state from the joining host in the receiver multicast site to the ETR of the receiver multicast site. There is (S-RLOC,G) state across the core network from the ETR of the multicast receiver site to the ITR in the multicast source site and (S-EID,G) state in the source multicast site. Note, the (S-EID,G) state is the same S-EID in each multicast site. As other ETRs join the same multicast tree, they can join through the same ITR (in which case the packet replication is done in the core) or a different ITR (in which case the packet replication is done at the source site). 6. When a packet is originated by the multicast host in the source site, it will flow to one or more ITRs which will prepend a LISP header by copying the group address to the outer destination address field and insert its own locator address in the outer source address field. The ITR will look at its (S-RLOC,G) state, where S-RLOC is its own locator address, and replicate the packet on each interface a (S-RLOC,G) joined was received on. The core has (S-RLOC,G) so where fanout occurs to multiple sites, a core router will do packet replication. 7. When either the source site or the core replicates the packet, the ETR will receive a LISP packet with a destination group address. It will also decapsulate packets because it has receivers for the group. Otherwise, it would have not received the packets because it would not have joined. The ETR decapsulates and does a (S-EID,G) lookup in its multicast FIB to forward packets out one or more interfaces to forward the packet to internal receivers. This architecture is consistent and scalable with the architecture presented in [LISP] where multicast state in the core operates on locators and multicast state at the sites operates on EIDs. Farinacci, et al. Expires April 1, 2010 [Page 10] =0C Internet-Draft LISP for Multicast Environments September 2009 Alternatively, [LISP] does present a mechanism where (S-EID,G) state can reside in the core through the use of RPF-vectors [RPFV] in PIM Join/Prune messages. However, this will require EID state in core as well as the use of RPF-vector formatted Join/Prune messages which are not the default implementation choice. So we choose a design that can allow the separation of namespaces as unicast LISP provides. It will be at the expense of creating new (S-RLOC,G) state when ITRs go unreachable. See Section 5 for details. However, we have some observations on the algorithm above. We can scale the control plane but at the expense of sending data to sites which may have not joined the distribution tree where the encapsulated data is being delivered. For example, one site joins (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the same multicast source site. Both multicast receiver sites join to the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the site. The ITR receives (S-RLOC,G) joins and populates the oif-list state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one (S-RLOC,G) packets will be delivered by the core to both multicast receiver sites even though each have joined a single source-based distribution tree. This behavior is a consequence of the many-to-one mapping between S-EIDs and a S-RLOC. There is a possible solution to this problem which reduces the number of many-to-one occurrences of (S-EID,G) entries aggregating into a single (S-RLOC,G) entry. If a physical ITR can be assigned multiple RLOC addresses and these addresses are advertised in mapping database entries, then ETRs at receiver sites have more RLOC address options and therefore can join different (RLOC,G) entries for each (S-EID,G) entry joined at the receiver site. It would not scale to have a one- to-one relationship between the number of S-EID sources at a source site and the number of RLOCs assigned to all ITRs at the site, but we can reduce the "n" to a smaller number in the "n-to-1" relationship. And in turn, reduce the opportunity for data packets to be delivered to sites for groups not joined. Farinacci, et al. Expires April 1, 2010 [Page 11] =0C Internet-Draft LISP for Multicast Environments September 2009 5. Source Addresses versus Group Addresses Multicast group addresses don't have to be associated with either the EID or RLOC namespace. They actually are a namespace of their own that can be treated as logical with relatively opaque allocation. So, by their nature, they don't detract from an incremental deployment of LISP-Multicast. As for source addresses, as in the unicast LISP scenario, there is a decoupling of identification from location. In a LISP site, packets are originated from hosts using their allocated EIDs, those addresses are used to identify the host as well as where in the site's topology the host resides but not how and where it is attached to the Internet. Therefore, when multicast distribution tree state is created anywhere in the network on the path from any multicast receiver to a multicast source, EID state is maintained at the source and receiver multicast sites, and RLOC state is maintained in the core. That is, a multicast distribution tree will be represented as a 3-tuple of {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 3-tuple is the state stored in routers from the source to one or more ITRs in the source multicast site, the second element of the 3-tuple is the state stored in routers downstream of the ITR, in the core, to all LISP receiver multicast sites, and the third element in the 3-tuple is the state stored in the routers downstream of each ETR, in each receiver multicast site, reaching each receiver. Note that (S-EID,G) is the same in both the source and receiver multicast sites. The concatenation/mapping from the first element to the second element of the 3-tuples is done by the ITR and from the second element to the third element is done at the ETRs. Farinacci, et al. Expires April 1, 2010 [Page 12] =0C Internet-Draft LISP for Multicast Environments September 2009 6. Locator Reachability Implications on LISP-Multicast Multicast state as it is stored in the core is always (S,G) state as it exists today or (S-RLOC,G) state as it will exist when LISP sites are deployed. The core routers cannot distinguish one from the other. They don't need to because it is state that RPFs against the core routing tables in the RLOC namespace. The difference is where the root of the distribution tree for a particular source is. In the traditional multicast core, the source S is the source host's IP address. For LISP-Multicast the source S is a single ITR of the multicast source site. An ITR is selected based on the LISP EID-to-RLOC mapping used when an ETR propagates a PIM Join/Prune message out of a receiver multicast site. The selection is based on the same algorithm an ITR would use to select an ETR when sending a unicast packet to the site. In the unicast case, the ITR can change on a per-packet basis depending on the reachability of the ETR. So an ITR can change relatively easily using local reachability state. However, in the multicast case, when an ITR goes unreachable, new distribution tree state must be built because the encapsulating root has changed. This is more significant than an RPF-change event, where any router would typically locally change its RPF-interface for its existing tree state. But when an encapsulating LISP-Multicast ITR goes unreachable, new distribution state must be rebuilt and reflect the new encapsulator. Therefore, when an ITR goes unreachable, all ETRs that are currently joined to that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) to the new ITR as well as send a unicast encapsulated Join/Prune message telling the new ITR which (S-EID,G) is being joined. This issue can be mitigated by using anycast addressing for the ITRs so the problem does reduce to an RPF change in the core, but still requires a unicast encapsulated Join/Prune message to tell the new ITR about (S-EID,G). The problem with this approach is that the ETR really doesn't know when the ITR has changed so the new anycast ITR will get the (S-EID,G) state only when the ETR sends it the next time during its periodic sending procedures. Farinacci, et al. Expires April 1, 2010 [Page 13] =0C Internet-Draft LISP for Multicast Environments September 2009 7. Multicast Protocol Changes A number of protocols are used today for inter-domain multicast routing: IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for LISP-Multicast for two reasons. One being that they are link- local and not used over site boundaries and second they advertise group addresses that don't need translation. Where source addresses are supplied in IGMPv3 and MLDv2 messages, they are semantically regarded as EIDs and don't need to be converted to RLOCs until the multicast tree-building protocol, such as PIM, is received by the ETR at the site boundary. Addresses used for IGMP and MLD come out of the source site's allocated addresses which are therefore from the EID namespace. MBGP: Even though MBGP is not a multicast routing protocol, it is used to find multicast sources when the unicast BGP peering topology and the multicast MBGP peering topology are not congruent. When MBGP is used in a LISP-Multicast environment, the prefixes which are advertised are from the RLOC namespace. This allows receiver multicast sites to find a path to the source multicast site's ITRs. MBGP peering addresses will be from the RLOC namespace. MSDP: MSDP is used to announce active multicast sources to other routing domains (or LISP sites). The announcements come from the PIM Rendezvous Points (RPs) from sites where there are active multicast sources sending to various groups. In the context of LISP-Multicast, the source addresses advertised in MSDP will semantically be from the EID namespace since they describe the identity of a source multicast host. It will be true that the state stored in MSDP caches from core routers will be from the EID namespace. An RP address inside of site will be from the EID namespace so it can be advertised and reached by internal unicast routing mechanism. However, for MSDP peer-RPF checking to work properly across sites, the RP addresses must be converted or mapped into a routable address that is advertised and maintained in the BGP routing tables in the core. MSDP peering addresses can come out of either the EID or a routable address namespace. And the choice can be made unilaterally because the ITR at the site will determine which namespace the destination peer address is out of by looking in the mapping database service. PIM-SSM: In the simplest form of distribution tree building, when PIM operates in SSM mode, a source distribution tree is built and maintained across site boundaries. In this case, there is a small modification to the operation of the PIM protocol (but not to any Farinacci, et al. Expires April 1, 2010 [Page 14] =0C Internet-Draft LISP for Multicast Environments September 2009 message format) to support taking a Join/Prune message originated inside of a LISP site with embedded addresses from the EID namespace and converting them to addresses from the RLOC namespace when the Join/Prune message crosses a site boundary. This is similar to the requirements documented in [MNAT]. PIM-Bidir: Bidirectional PIM is typically run inside of a routing domain, but if deployed in an inter-domain environment, one would have to decide if the RP address of the shared-tree would be from the EID namespace or the RLOC namespace. If the RP resides in a site-based router, then the RP address is from the EID namespace. If the RP resides in the core where RLOC addresses are routed, then the RP address is from the RLOC namespace. This could be easily distinguishable if the EID address were well-known address allocation block from the RLOC namespace. Also, when using Embedded-RP for RP determination [RFC3956], the format of the group address could indicate the namespace the RP address is from. However, refer to Section 10 for considerations core routers need to make when using Embedded-RP IPv6 group addresses. When using Bidir-PIM for inter-domain multicast routing, it is recommended to use staticly configured RPs so core routers think the Bidir group is associated with an ITR's RLOC as the RP address and site routers think the Bidir group is associated with the site resident RP with an EID address. With respect to DF-election in Bidir PIM, no changes are required since all messaging and addressing is link-local. PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is deployed in the Internet today is by having shared-trees within a site and using source-trees across sites. By the use of MSDP and PIM-SSM techniques described above, we can get multicast connectivity across LISP sites. Having said that, that means there are no special actions required for processing (*,G) or (S,G,R) Join/Prune messages since they all operate against the shared-tree which is site resident. Just like with ASM, there is no (*,G) in the core when LISP-Multicast is in use. This is also true for the RP-mapping mechanisms Auto-RP and BSR. Based on the protocol description above, the conclusion is that there are no protocol message format changes, just a translation function performed at the control-plane. This will make for an easier and faster transition for LISP since fewer components in the network have to change. It should also be stated just like it is in [LISP] that no host changes, whatsoever, are required to have a multicast source host send multicast packets and for a multicast receiver host to receive multicast packets. Farinacci, et al. Expires April 1, 2010 [Page 15] =0C Internet-Draft LISP for Multicast Environments September 2009 8. LISP-Multicast Data-Plane Architecture The LISP-Multicast data-plane operation conforms to the operation and packet formats specified in [LISP]. However, encapsulating a multicast packet from an ITR is a much simpler process. The process is simply to copy the inner group address to the outer destination address. And to have the ITR use its own IP address (its RLOC), and as the source address. The process is simpler for multicast because there is no EID-to-RLOC mapping lookup performed during packet forwarding. In the decapsulation case, the ETR simply removes the outer header and performs a multicast routing table lookup on the inner header (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is used to replicate the packet on site-facing interfaces leading to multicast receiver hosts. There is no Data-Probe logic for ETRs as there can be in the unicast forwarding case. 8.1. ITR Forwarding Procedure The following procedure is used by an ITR, when it receives a multicast packet from a source inside of its site: 1. A multicast data packet sent by a host in a LISP site will have the source address equal to the host's EID and the destination address equal to the group address of the multicast group. It is assumed the group information is obtained by current methods. The same is true for a multicast receiver to obtain the source and group address of a multicast flow. 2. When the ITR receives a multicast packet, it will have both S-EID state and S-RLOC state stored. Since the packet was received on a site-facing interface, the RPF lookup is based on the S-EID state. If the RPF check succeeds, then the oif-list contains interfaces that are site-facing and external-facing. For the site-facing interfaces, no LISP header is prepended. For the external-facing interfaces a LISP header is prepended. When the ITR prepends a LISP header, it uses its own RLOC address as the source address and copies the group address supplied by the IP header the host built as the outer destination address. 8.1.1. Multiple RLOCs for an ITR Typically, an ITR will have a single RLOC address but in some cases there could be multiple RLOC addresses assigned from either the same or different service providers. In this case when (S-RLOC,G) Join/ Farinacci, et al. Expires April 1, 2010 [Page 16] =0C Internet-Draft LISP for Multicast Environments September 2009 Prune messages are received for each RLOC, there is a oif-list merging action that must take place. Therefore, when a packet is received from a site-facing interface that matches on a (S-EID,G) entry, the interfaces of the oif-list from all (RLOC,G) entries joined to the ITR as well as the site-facing oif-list joined for (S-EID,G) must be part be included in packet replication. In addition to replicating for all types of oif-lists, each oif entry must be tagged with the RLOC address, so encapsulation uses the outer source address for the RLOC joined. 8.2. ETR Forwarding Procedure The following procedure is used by an ETR, when it receives a multicast packet from a source outside of its site: 1. When a multicast data packet is received by an ETR on an external-facing interface, it will do an RPF lookup on the S-RLOC state it has stored. If the RPF check succeeds, the interfaces from the oif-list are used for replication to interfaces that are site-facing as well as interfaces that are external-facing (this ETR can also be a transit multicast router for receivers outside of its site). When the packet is to be replicated for an external-facing interface, the LISP encapsulation header are not stripped. When the packet is replicated for a site-facing interface, the encapsulation header is stripped. 2. The packet without a LISP header is now forwarded down the (S-EID,G) distribution tree in the receiver multicast site. 8.3. Replication Locations Multicast packet replication can happen in the following topological locations: o In an IGP multicast router inside a site which operates on S-EIDs. o In a transit multicast router inside of the core which operates on S-RLOCs. o At one or more ETR routers depending on the path a Join/Prune message exits a receiver multicast site. o At one or more ITR routers in a source multicast site depending on what priorities are returned in a Map-Reply to receiver multicast sites. In the last case the source multicast site can do replication rather than having a single exit from the site. But this only can occur Farinacci, et al. Expires April 1, 2010 [Page 17] =0C Internet-Draft LISP for Multicast Environments September 2009 when the priorities in the Map-Reply are modified for different receiver multicast site so that the PIM Join/Prune messages arrive at different ITRs. This policy technique, also used in [ALT] for unicast, is useful for multicast to mitigate the problems of changing distribution tree state as discussed in Section 6. Farinacci, et al. Expires April 1, 2010 [Page 18] =0C Internet-Draft LISP for Multicast Environments September 2009 9. LISP-Multicast Interworking This section will describe the multicast corollary to [INTWORK] which describes the interworking of multicast routing among LISP and non- LISP sites. 9.1. LISP and non-LISP Mixed Sites Since multicast communication can involve more than two entities to communicate together, the combinations of interworking scenarios are more involved. However, the state maintained for distribution trees at the sites is the same regardless of whether or not the site is LISP enabled or not. So most of the implications are in the core with respect to storing routable EID prefixes from either PA or PI blocks. Before we enumerate the multicast interworking scenarios, we must define 3 deployment states of a site: o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it does today. The addresses for the site are globally routable. o A site that deploys LISP for unicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a uLISP site. o A site that deploys LISP for both unicast and multicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a LISP-Multicast site. We will not consider a LISP site enabled for multicast purposes only but do consider a uLISP site as documented in [INTWORK]. In this section we don't discuss how a LISP site sends multicast packets when all receiver sites are LISP-Multicast enabled; that has been discussed in previous sections. The following scenarios exist to make LISP-Multicast sites interwork with non-LISP-Multicast sites: 1. A LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 2. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 3. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. Farinacci, et al. Expires April 1, 2010 [Page 19] =0C Internet-Draft LISP for Multicast Environments September 2009 4. A uLISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. 5. A LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. 9.1.1. LISP Source Site to non-LISP Receiver Sites In the first scenario, a site is LISP capable for both unicast and multicast traffic and as such operates on EIDs. Therefore there is a possibility that the EID prefix block is not routable in the core. For LISP receiver multicast sites this isn't a problem but for non- LISP or uLISP receiver multicast sites, when a PIM Join/Prune message is received by the edge router, it has no route to propagate the Join/Prune message out of the site. This is no different than the unicast case that LISP-NAT in [INTWORK] solves. LISP-NAT allows a unicast packet that exits a LISP site to get its source address mapped to a globally routable address before the ITR realizes that it should not encapsulate the packet destined to a non- LISP site. For a multicast packet to leave a LISP site, distribution tree state needs to be built so the ITR can know where to send the packet. So the receiver multicast sites need to know about the multicast source host by its routable address and not its EID address. When this is the case, the routable address is the (S-RLOC,G) state that is stored and maintained in the core routers. It is important to note that the routable address for the host cannot be the same as an RLOC for the site. Because we want the ITRs to process a received PIM Join/Prune message from an external-facing interface to be propagated inside of the site so the site-part of the distribution tree is built. Using a globally routable source address allows non-LISP and uLISP multicast receiver to join, create, and maintain a multicast distribution tree. However, the LISP multicast receiver site will want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ Prune message is received on a site-facing interface. It does this because it wants to find a (S-RLOC,G) entry to Join in the core. So we have a conflict of behavior between the two types of sites. The solution to this problem is the same as when an ITR wants to send a unicast packet to a destination site but needs determine if the site is LISP capable or not. When it is not LISP capable, the ITR does not encapsulate the packet. So for the multicast case, when ETR receives a PIM Join/Prune message for (S-EID,G) state, it will do a mapping table lookup on S-EID. In this case, S-EID is not in the Farinacci, et al. Expires April 1, 2010 [Page 20] =0C Internet-Draft LISP for Multicast Environments September 2009 mapping database because the source multicast site is using a routable address and not an EID prefix address. So the ETR knows to simply propagate the PIM Join/Prune message to a external-facing interface without converting the (S-EID,G) because it is an (S,G) where S is routable and reachable via core routing tables. Now that the multicast distribution tree is built and maintained from any non-LISP or uLISP receiver multicast site, the way packet forwarding model is performed can be explained. Since the ITR in the source multicast site has never received a unicast encapsulated PIM Join/Prune message from any ETR in a receiver multicast site, it knows there are no LISP-Multicast receiver sites. Therefore, there is no need for the ITR to encapsulate data. Since it will know a priori (via configuration) that its site's EIDs are not routable, it assumes that the multicast packets from the source host are sent by a routable address. That is, it is the responsibility of the multicast source host's system administrator to ensure that the source host sends multicast traffic using a routable source address. When this happens, the ITR acts simply as a router and forwards the multicast packet like an ordinary multicast router. There is an alternative to using a LISP-NAT scheme just like there is for unicast [INTWORK] forwarding by using Proxy Tunnel Routers (PTRs). This can work the same way for multicast routing as well, but the difference is that non-LISP and uLISP sites will send PIM Join/Prune messages for (S-EID,G) which make their way in the core to PTRs. Let's call this use of a PTR as a "Multicast PTR" (or mPTR). Since the PTRs advertise very coarse EID prefixes, they draw the PIM Join/Prune control traffic making them the target of the distribution tree. To get multicast packets from the LISP source multicast sites, the tree needs to be built on the path from the mPTR to the LISP source multicast site. To make this happen the mPTR acts as a "Proxy ETR" (where in unicast it acts as a "Proxy ITR"). The existence of mPTRs in the core allows LISP source multicast site ITRs to encapsulate multicast packets so the state built between the ITRs and the mPTRs is (S-RLOC,G) state. Then the mPTRs can decapsulate packets and forward natively to the non-LISP and uLISP receiver multicast sites. 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites Clearly non-LISP multicast sites can send multicast packets to non- LISP receiver multicast sites. That is what they do today. However, discussion is required to show how non-LISP multicast sites send multicast packets to uLISP receiver multicast sites. Farinacci, et al. Expires April 1, 2010 [Page 21] =0C Internet-Draft LISP for Multicast Environments September 2009 Since uLISP receiver multicast sites are not targets of any (S,G) state, they simply send (S,G) PIM Join/Prune messages toward the non- LISP source multicast site. Since the source multicast site, in this case has not been upgraded to LISP, all multicast source host addresses are routable. So this case is simplified to where a uLISP receiver multicast site looks to the source multicast site as a non- LISP receiver multicast site. 9.1.3. Non-LISP Source Site to Any Receiver Site When a non-LISP source multicast site has receivers in either a non- LISP/uLISP site or a LISP site, one needs to decide how the LISP receiver multicast site will attach to the distribution tree. We know from Section 9.1.2 that non-LISP and uLISP receiver multicast sites can join the distribution tree, but a LISP receiver multicast site ETR will need to know if the source address of the multicast source host is routable or not. We showed in Section 9.1.1 that an ETR, before it sends a PIM Join/Prune message on an external-facing interface, does a EID-to-RLOC mapping lookup to determine if it should convert the (S,G) state from a PIM Join/Prune message received on a site-facing interface to a (S-RLOC,G). If the lookup fails, the ETR can conclude the source multicast site is a non-LISP site so it simply forwards the Join/Prune message (it also doesn't need to send a unicast encapsulated Join/Prune message because there is no ITR in a non-LISP site and there is namespace continuity between the ETR and source). 9.1.4. Unicast LISP Source Site to Any Receiver Sites In the last section, it was explained how an ETR in a multicast receiver site can determine if a source multicast site is LISP- enabled by looking into the mapping database. When the source multicast site is a uLISP site, it is LISP enabled but the ITR, by definition is not capable of doing multicast encapsulation. So for the purposes of multicast routing, the uLISP source multicast site is treated as non-LISP source multicast site. Non-LISP receiver multicast sites can join distribution trees to a uLISP source multicast site since the source site behaves, from a forwarding perspective, as a non-LISP source site. This is also the case for a uLISP receiver multicast site since the ETR does not have multicast functionality built-in or enabled. Special considerations are required for LISP receiver multicast sites since they think the source multicast site is LISP capable, the ETR cannot know if ITR is LISP-Multicast capable. To solve this problem, each mapping database entry will have a multicast 2-tuple (Mpriority, Mweight) per RLOC. When the Mpriority is set to 255, the site is Farinacci, et al. Expires April 1, 2010 [Page 22] =0C Internet-Draft LISP for Multicast Environments September 2009 considered not multicast capable. So an ETR in a LISP receiver multicast site can distinguish whether a LISP source multicast site is LISP-Multicast site from a uLISP site. 9.1.5. LISP Source Site to Any Receiver Sites When a LISP source multicast site has receivers in LISP, non-LISP, and uLISP receiver multicast sites, it has a conflict about how it sends multicast packets. The ITR can either encapsulate or natively forward multicast packets. Since the receiver multicast sites are heterogeneous in their behavior, one packet forwarding mechanism cannot satisfy both. However, if a LISP receiver multicast site acts like a uLISP site then it could receive packets like a non-LISP receiver multicast site making all receiver multicast sites have homogeneous behavior. However, this poses the following issues: o LISP-NAT techniques with routable addresses would be required in all cases. o Or alternatively, mPTR deployment would be required forcing coarse EID prefix advertisement in the core. o But what is most disturbing is that when all sites that participate are LISP-Multicast sites but then a non-LISP or uLISP site joins the distribution tree, then the existing joined LISP receiver multicast sites would have to change their behavior. This would create too much dynamic tree-building churn to be a viable alternative. So the solution space options are: 1. Make the LISP ITR in the source multicast site send two packets, one that is encapsulated with (S-RLOC,G) to reach LISP receiver multicast sites and another that is not encapsulated with (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to reach LISP-Multicast sites and to reach mPTRs that can decapsulate and forward (S-EID,G) packets to non-LISP and uLISP receiver multicast sites. 9.2. LISP Sites with Mixed Address Families A LISP database mapping entry that describes the locator-set, Mpriority and Mweight per locator address (RLOC), for an EID prefix associated with a site could have RLOC addresses in either IPv4 or IPv6 format. When a mapping entry has a mix of RLOC formatted addresses, it is an implicit advertisement by the site that it is a Farinacci, et al. Expires April 1, 2010 [Page 23] =0C Internet-Draft LISP for Multicast Environments September 2009 dual-stack site. That is, the site can receive IPv4 or IPv6 unicast packets. To distinguish if the site can receive dual-stack unicast packets as well as dual-stack multicast packets, the Mpriority value setting will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format details. If you consider the combinations of LISP, non-LISP, and uLISP sites sharing the same distribution tree and considering the capabilities of supporting IPv4, IPv6, or dual-stack, the number of total combinations grows beyond comprehension. Using some combinatorial math, we have the following profiles of a site and the combinations that can occur: 1. LISP-Multicast IPv4 Site 2. LISP-Multicast IPv6 Site 3. LISP-Multicast Dual-Stack Site 4. uLISP IPv4 Site 5. uLISP IPv6 Site 6. uLISP Dual-Stack Site 7. non-LISP IPv4 Site 8. non-LISP IPv6 Site 9. non-LISP Dual-Stack Site Lets define (m n) =3D m!/(n!*(m-n)!), pronounced "m choose n" to illustrate some combinatorial math below. When 1 site talks to another site, the combinatorial is (9 2), when 1 site talks to another 2 sites, the combinatorial is (9 3). If sum this up to (9 9), we have: (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =3D 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 Which results in the total number of cases to be considered at 502. Farinacci, et al. Expires April 1, 2010 [Page 24] =0C Internet-Draft LISP for Multicast Environments September 2009 This combinatorial gets even worse when you consider a site using one address family inside of the site and the xTRs use the other address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 RLOCs). To rationalize this combinatorial nightmare, there are some guidelines which need to be put in place: o Each distribution tree shared among sites will either be an IPv4 distribution tree or an IPv6 distribution tree. Therefore, we can avoid head-end replication by building and sending packets on each address family based distribution tree. Even though there might be an urge to do multicast packet translation from one address family format to the other, it is a non-viable over-complicated urge. o All LISP sites on a multicast distribution tree must share a common address family which is determined by the source site's locator-set in its LISP database mapping entry. All receiver multicast sites will use the best RLOC priority controlled by the source multicast site. This is true when the source site is either LISP-Multicast or uLISP capable. This means that priority- based policy modification is prohibited. o When the source site is not LISP capable, it is up to how receivers find the source and group information for a multicast flow. That mechanism decides the address family for the flow. 9.3. Making a Multicast Interworking Decision This Multicast Interworking section has shown all combinations of multicast connectivity that could occur. As you might have already concluded, this can be quite complicated and if the design is too ambitious, the dynamics of the protocol could cause a lot of instability. The trade-off decisions are hard to make and we want the same single solution to work for both IPv4 and IPv6 multicast. It is imperative to have an incrementally deployable solution for all of IPv4 unicast and multicast and IPv6 unicast and multicast while minimizing (or eliminating) both unicast and multicast EID namespace state. Therefore the design decision to go with PTRs for unicast routing and mPTRs for multicast routing seems to be the sweet spot in the solution space so we can optimize state requirements and avoid head- end data replication at ITRs. Farinacci, et al. Expires April 1, 2010 [Page 25] =0C Internet-Draft LISP for Multicast Environments September 2009 10. Considerations when RP Addresses are Embedded in Group Addresses When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a technique exists to embed the unicast address of an RP in a IPv6 group address [RFC3956]. When routers in end sites process a PIM Join/Prune message which contain an embedded-RP group address, they extract the RP address from the group address and treat it from the EID namespace. However, core routers do not have state for the EID namespace, need to extract an RP address from the RLOC namespace. Therefore, it is the responsibility of ETRs in multicast receiver sites to map the group address into a group address where the embedded-RP address is from the RLOC namespace. The mapped RP- address is obtained from a EID-to-RLOC mapping database lookup. The ETR will also send a unicast (*,G) Join/Prune message to the ITR so the branch of the distribution tree from the source site resident RP to the ITR is created. This technique is no different than the techniques described in this specification for translating (S,G) state and propagating Join/Prune messages into the core. The only difference is that the (*,G) state in Join/Prune messages are mapped because they contain unicast addresses encoded in an Embedded-RP group address. Farinacci, et al. Expires April 1, 2010 [Page 26] =0C Internet-Draft LISP for Multicast Environments September 2009 11. Taking Advantage of Upgrades in the Core If the core routers are upgraded to support [RPFV] and [RFC5496], then we can pass EID specific data through the core without, possibly, having to store the state in the core. By doing this we can eliminate the ETR from unicast encapsulating PIM Join/Prune messages to the source site's ITR. However, this solution is restricted to a small set of workable cases which would not be good for general use of LISP-Multicast. In addition to slow convergence properties, it is not being recommended for LISP-Multicast. Farinacci, et al. Expires April 1, 2010 [Page 27] =0C Internet-Draft LISP for Multicast Environments September 2009 12. Mtrace Considerations Mtrace functionality must be consistent with unicast traceroute functionality where all hops from multicast receiver to multicast source are visible. The design for mtrace for use in LISP-Multicast environments is to be determined but should build upon the mtrace version 2 specified in [MTRACE]. Farinacci, et al. Expires April 1, 2010 [Page 28] =0C Internet-Draft LISP for Multicast Environments September 2009 13. Security Considerations Refer to the [LISP] specification. Farinacci, et al. Expires April 1, 2010 [Page 29] =0C Internet-Draft LISP for Multicast Environments September 2009 14. Acknowledgments The authors would like to gratefully acknowledge the people who have contributed discussion, ideas, and commentary to the making of this proposal and specification. People who provided expert review were Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from discussions at Summer 2008 Dublin IETF were Toerless Eckert and Ijsbrand Wijnands. We would also like to thank the MBONED working group for constructive and civil verbal feedback when this draft was presented at the Fall 2008 IETF in Minneapolis. In particular, good commentary came from Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, Ron Bonica, and Lenny Guardino. An expert review of this specification was done by Yiqun Cai and Liming Wei. We thank them for their detailed comments. This work originated in the Routing Research Group (RRG) of the IRTF. The individual submission [MLISP] was converted into this IETF LISP working group draft. Farinacci, et al. Expires April 1, 2010 [Page 30] =0C Internet-Draft LISP for Multicast Environments September 2009 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 15.2. Informative References [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-01.txt (work in progress), May 2009. [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-00.txt (work in progress), May 2009. [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, et al. Expires April 1, 2010 [Page 31] =0C Internet-Draft LISP for Multicast Environments September 2009 "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-05.txt (work in progress), October 2009. [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt (work in progress), November 2008. [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a Network Address (and port) Translator (NAT)", draft-ietf-behave-multicast-07.txt (work in progress), June 2007. [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace Version 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-03.txt (work in progress), March 2009. [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), February 2008. Farinacci, et al. Expires April 1, 2010 [Page 32] =0C Internet-Draft LISP for Multicast Environments September 2009 Appendix A. Document Change Log A.1. Changes to draft-ietf-lisp-multicsat-02.txt o Posted October 2009. o Added Document Change Log appendix. o Specify that the LISP Encapsulated Control Message be used for unicasting PIM Join/Prune messages from ETRs to ITRs. A.2. Changes to draft-ietf-lisp-multicsat-01.txt o Posted November 2008. o Specified that PIM Join/Prune unicast messages that get sent from ETRs to ITRs of a source multicast site get LISP encapsulated in destination UDP port 4342. o Add multiple RLOCs per ITR per Yiqun's comments. o Indicate how static RPs can be used when LISP is run using Bidir- PIM in the core. o Editorial changes per Liming comments. o Add Mttrace Considersations section. A.3. Changes to draft-ietf-lisp-multicsat-00.txt o Posted April 2008. o Renamed from draft-farinacci-lisp-multicast-01.txt. Farinacci, et al. Expires April 1, 2010 [Page 33] =0C Internet-Draft LISP for Multicast Environments September 2009 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA USA Email: dino@cisco.com Dave Meyer cisco Systems Tasman Drive San Jose, CA USA Email: dmm@cisco.com John Zwiebel cisco Systems Tasman Drive San Jose, CA USA Email: jzwiebel@cisco.com Stig Venaas cisco Systems Tasman Drive San Jose, CA USA Email: stig@cisco.com Farinacci, et al. Expires April 1, 2010 [Page 34] =0C --Apple-Mail-36-1016491758 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-36-1016491758-- From root@core3.amsl.com Tue Sep 29 18:00:01 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 58FDA3A690A; Tue, 29 Sep 2009 18:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090930010001.58FDA3A690A@core3.amsl.com> Date: Tue, 29 Sep 2009 18:00:01 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-05.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, 30 Sep 2009 01:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : D. Farinacci, et al. Filename : draft-ietf-lisp-05.txt Pages : 73 Date : 2009-09-29 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-29175037.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Sep 29 18:00:01 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6CB503A6A04; Tue, 29 Sep 2009 18:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090930010001.6CB503A6A04@core3.amsl.com> Date: Tue, 29 Sep 2009 18:00:01 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-multicast-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: Wed, 30 Sep 2009 01:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP for Multicast Environments Author(s) : D. Farinacci, et al. Filename : draft-ietf-lisp-multicast-02.txt Pages : 34 Date : 2009-09-29 This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-multicast-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-multicast-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-29175521.I-D@ietf.org> --NextPart-- From jari.arkko@piuha.net Wed Sep 30 05:58: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 243293A6905 for ; Wed, 30 Sep 2009 05:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 w9NaFjwvOxvR for ; Wed, 30 Sep 2009 05:58:42 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 044CB3A6A75 for ; Wed, 30 Sep 2009 05:58:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 50037D4932 for ; Wed, 30 Sep 2009 16:00:04 +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 nq0TRxeItycF for ; Wed, 30 Sep 2009 16:00:03 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 21164D4900 for ; Wed, 30 Sep 2009 16:00:02 +0300 (EEST) Message-ID: <4AC35651.30303@piuha.net> Date: Wed, 30 Sep 2009 16:00:01 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] experimental RFCs X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 30 Sep 2009 12:58:43 -0000 Several people have asked me what difference it makes that we produce experimental RFCs in this working group. For instance, do we have a lower bar for these RFCs than we might have for standards track RFCs? For what it is worth, here's my opinion on this. An experimental RFC indeed has a lower acceptance bar when it comes to technical solutions, applicability, and ability to deal with various conditions in the Internet. For a standards track RFC, we would like to be very sure that it works well in almost all conditions that we can encounter in the Internet. An experimental RFC might only work well in some specific situations, or we would need testing to ensure that it works well in all situations. There might not be IETF-wide consensus that the solution is the one and only right solution for the problem in question. The solution may be technically insufficient in some way, e.g., lack management tools or scalability problems. However, even an experimental RFC needs to satisfy some basic technical and process principles and be safe to use. In particular: - We still need to believe that the idea is potentially good. - The working group needs to have consensus behind the design choices in the document. We are not here to publish a spec as it was in its individual stage; the point of the working group is that the working group has useful input to the document. - Truth in advertising: the spec may be deficient in some manner, or, perhaps more likely, we do not understand how well it works. These cases need to be clearly documented in the specification. Its OK to say "we don't know if this works well". - The specification cannot rewrite rules that were laid out in standard track specifications. - The specification needs to be fulfill some basic safety rules, mostly about not making things worse and not hurting the rest of the Internet. For instance, even experimental RFCs need to deal with congestion avoidance. - The specification must be up to a reasonable level of engineering. For instance, it should be fully specified, implementable, address security in some form, etc. The exact ambition level beyond these basic requirements is largely up to the working group. My understanding is that people have high hopes for Lisp. I would expect you to shoot pretty high and not leave too many problems in the specification. Otherwise it would be hard to move from an experimental RFC to a standards track RFC, and any actual deployment would hit issues. But in any case, fulfilling at leas the basic requirements is essential for a successful RFC publication. There has been situations where even experimental work has been stuck for years in the final IETF and IESG review stage, because the working group did not produce work that was acceptable to the rest of the IETF. So take care of this early, and talk to your chairs, ADs and technical advisors if there's any doubt about what's necessary in your documents. Jari From vaf@cisco.com Wed Sep 30 09:06: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 D92713A6995 for ; Wed, 30 Sep 2009 09:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 x6Y-ITc-aF0m for ; Wed, 30 Sep 2009 09:06:54 -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 720943A69B5 for ; Wed, 30 Sep 2009 09:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=43986; q=dns/txt; s=sjiport06001; t=1254326898; x=1255536498; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Vince=20Fuller=20|Subject:=20upda te=20to=20LISP-MS=20(draft-ietf-lisp-ms-03.txt)|Date:=20W ed,=2030=20Sep=202009=2009:00:31=20-0700|Message-ID:=20<2 0090930160031.GD19727@vaf-lnx1>|To:=20lisp@ietf.org |MIME-Version:=201.0; bh=xcfU/mPonCZzDsj+1U6aPCjBdklNqD8QGvupkx9ZAk4=; b=oRWYGsPCuW36aYCi0IIDxirdpKD5GLXU0IPfp/PrxF51nFuG6ySdjNJx TmvPiYCUnwD1Sn9Y/F/Ha819xZ1/jxn+AjCieyMLheqWGea7qpxuE37DY Y3Zr3BP4biAqLS5AanWbwvfeEe0tY9oq6yO8M7rLZdR/hdZu+eX+v0lEZ I=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (partially verified [43960 bytes] [TEST]) header.i=vaf@cisco.com X-Files: rfcdiff-lisp-ms-02-to-03.html, draft-ietf-lisp-ms-03.txt : 20270, 21787 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkGALcfw0qrR7PE/2dsb2JhbACCIjK+LYhbASaPYAaEJw X-IronPort-AV: E=Sophos;i="4.44,481,1249257600"; d="txt'?html'217?scan'217,208,217";a="399387899" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Sep 2009 16:08:17 +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 n8UG8Hxf031590 for ; Wed, 30 Sep 2009 09:08:17 -0700 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n8UG8HTO004457 for ; Wed, 30 Sep 2009 16:08:17 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 n8UG0VT0020422 for ; Wed, 30 Sep 2009 09:00:31 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n8UG0VZR020419 for lisp@ietf.org; Wed, 30 Sep 2009 09:00:31 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Wed, 30 Sep 2009 09:00:31 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20090930160031.GD19727@vaf-lnx1> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="DrWhICOqskFTAXiy" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=43960; t=1254326897; x=1255190897; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20update=20to=20LISP-MS=20(draft-ietf-lisp-ms-03. txt) |Sender:=20; bh=kfmfRG2spe5pBEUn0OFvynG1t07v6eakBPbCvc2ffGg=; b=TDk4pZacZtEIYqxUNsf6ncE8uBOkEvDupUwzHY1RGeDRSd2KeM8aMPIA1v mQ2BGhh9gERupcd8bZM62fmfyd2in2Gbb9Xnc//BBQSxaVC6R9iIVBEfMliK blsm4WYQ5u; Subject: [lisp] update to LISP-MS (draft-ietf-lisp-ms-03.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, 30 Sep 2009 16:06:58 -0000 --DrWhICOqskFTAXiy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Changed to match main LISP specification (draft-ietf-lisp-05.txt). Only one significant change: use of port 4342 instead of port 4341 for Encapsulated Map Requests. Also updated spec reference. I plan to post this to the IETF drafts repository first thing Friday morning. Diffs and new document attached below. --Vince --DrWhICOqskFTAXiy Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="rfcdiff-lisp-ms-02-to-03.html" wdiff draft-ietf-lisp-ms-02.txt draft-ietf-lisp-ms-03.txt 
Network Working Group                                          V. Fuller
Internet-Draft                                              D. Farinacci
Intended status: Experimental                              cisco Systems
Expires: March 8, April 2, 2010                                September 4, 29, 2009

                            LISP Map Server
                       draft-ietf-lisp-ms-02.txt
                       draft-ietf-lisp-ms-03.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 March 8, April 2, 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  . . . . . . . . . . . . . . . . .  9
       5.4.1.  Anycast Map-Resolver Operation . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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. 4342.  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 on a Map-Server by sending LISP
   Map-Register messages.  A Map-Register message is authenticated using
   an IPSec Authentication Header (AH) as defined in [RFC2402], with
   SHA-1 or SHA-256 as the authentication HMAC.  Prior to sending a 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 SHA-1 or SHA-256.  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-04.txt
              draft-ietf-lisp-05.txt (work in progress) (work in
              progress), 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
--DrWhICOqskFTAXiy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-lisp-ms-03.txt" Network Working Group V. Fuller Internet-Draft D. Farinacci Intended status: Experimental cisco Systems Expires: April 2, 2010 September 29, 2009 LISP Map Server draft-ietf-lisp-ms-03.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 April 2, 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. Fuller & Farinacci Expires April 2, 2010 [Page 1] Internet-Draft LISP Map Server September 2009 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 . . . . . . . . . . . . . . . . . 9 5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Fuller & Farinacci Expires April 2, 2010 [Page 2] Internet-Draft LISP Map Server September 2009 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]. Fuller & Farinacci Expires April 2, 2010 [Page 3] Internet-Draft LISP Map Server September 2009 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. Fuller & Farinacci Expires April 2, 2010 [Page 4] Internet-Draft LISP Map Server September 2009 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 4342. 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]. Fuller & Farinacci Expires April 2, 2010 [Page 5] Internet-Draft LISP Map Server September 2009 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. Fuller & Farinacci Expires April 2, 2010 [Page 6] Internet-Draft LISP Map Server September 2009 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 on a Map-Server by sending LISP Map-Register messages. A Map-Register message is authenticated using Fuller & Farinacci Expires April 2, 2010 [Page 7] Internet-Draft LISP Map Server September 2009 an IPSec Authentication Header (AH) as defined in [RFC2402], with SHA-1 or SHA-256 as the authentication HMAC. Prior to sending a 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. Fuller & Farinacci Expires April 2, 2010 [Page 8] Internet-Draft LISP Map Server September 2009 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. Fuller & Farinacci Expires April 2, 2010 [Page 9] Internet-Draft LISP Map Server September 2009 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. Fuller & Farinacci Expires April 2, 2010 [Page 10] Internet-Draft LISP Map Server September 2009 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 SHA-1 or SHA-256. 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. Fuller & Farinacci Expires April 2, 2010 [Page 11] Internet-Draft LISP Map Server September 2009 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-05.txt (work in progress) (work in progress), 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. Fuller & Farinacci Expires April 2, 2010 [Page 12] Internet-Draft LISP Map Server September 2009 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. Fuller & Farinacci Expires April 2, 2010 [Page 13] Internet-Draft LISP Map Server September 2009 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 Fuller & Farinacci Expires April 2, 2010 [Page 14] --DrWhICOqskFTAXiy--