Re: [lisp] #16: map versioning resolution
Luigi Iannone <luigi@net.t-labs.tu-berlin.de> Wed, 02 September 2009 10:59 UTC
Return-Path: <luigi@net.t-labs.tu-berlin.de>
X-Original-To: lisp@core3.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 <lisp@core3.amsl.com>; 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 <lisp@core3.amsl.com>; 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 <lisp@ietf.org>; 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: <BC6CC04B-A296-4C2B-8C5C-FFE44DB78E4E@net.t-labs.tu-berlin.de>
From: Luigi Iannone <luigi@net.t-labs.tu-berlin.de>
To: Sam Hartman <hartmans-ietf@mit.edu>
In-Reply-To: <tsleiqxz4of.fsf@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: Wed, 02 Sep 2009 12:57:05 +0200
References: <tsleiqxz4of.fsf@mit.edu>
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 <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=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
- [lisp] #16: map versioning resolution Sam Hartman
- Re: [lisp] #16: map versioning resolution Sam Hartman
- Re: [lisp] #16: map versioning resolution Luigi Iannone
- Re: [lisp] #16: map versioning resolution Dino Farinacci
- Re: [lisp] #16: map versioning resolution Joel M. Halpern
- Re: [lisp] #16: map versioning resolution Sam Hartman
- Re: [lisp] #16: map versioning resolution Dino Farinacci
- Re: [lisp] #16: map versioning resolution Dino Farinacci
- Re: [lisp] #16: map versioning resolution Dino Farinacci
- Re: [lisp] #16: map versioning resolution Sam Hartman
- Re: [lisp] #16: map versioning resolution Dino Farinacci
- Re: [lisp] #16: map versioning resolution Sam Hartman
- Re: [lisp] #16: map versioning resolution Joel M. Halpern
- Re: [lisp] #16: map versioning resolution Noel Chiappa
- Re: [lisp] #16: map versioning resolution Noel Chiappa
- Re: [lisp] #16: map versioning resolution Margaret Wasserman
- Re: [lisp] #16: map versioning resolution Noel Chiappa
- Re: [lisp] #16: map versioning resolution Margaret Wasserman
- Re: [lisp] #16: map versioning resolution Noel Chiappa
- Re: [lisp] #16: map versioning resolution Margaret Wasserman
- Re: [lisp] #16: map versioning resolution Eliot Lear
- Re: [lisp] #16: map versioning resolution Noel Chiappa
- Re: [lisp] #16: map versioning resolution Dino Farinacci
- Re: [lisp] #16: map versioning resolution Margaret Wasserman
- Re: [lisp] #16: map versioning resolution Dino Farinacci
- Re: [lisp] #16: map versioning resolution Luigi Iannone
- Re: [lisp] #16: map versioning resolution Luigi Iannone
- Re: [lisp] #16: map versioning resolution Sam Hartman
- [lisp] Consensus call on LISP 04 header Sam Hartman
- Re: [lisp] #16: map versioning resolution Luigi Iannone