Re: [Int-area] Probably ignorant question about <http://www.ietf.org/id/draft-briscoe-intarea-ipv4-id-reuse-00.txt>

Bob Briscoe <bob.briscoe@bt.com> Fri, 22 July 2011 11:33 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C57421F876F for <int-area@ietfa.amsl.com>; Fri, 22 Jul 2011 04:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.483
X-Spam-Level:
X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc7AOD0HY-FT for <int-area@ietfa.amsl.com>; Fri, 22 Jul 2011 04:33:50 -0700 (PDT)
Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id CD58A21F8764 for <int-area@ietf.org>; Fri, 22 Jul 2011 04:33:49 -0700 (PDT)
Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jul 2011 12:33:47 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jul 2011 12:33:47 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1311334425456; Fri, 22 Jul 2011 12:33:45 +0100
Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6MBXjUF014278; Fri, 22 Jul 2011 12:33:45 +0100
Message-Id: <201107221133.p6MBXjUF014278@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 22 Jul 2011 12:33:44 +0100
To: Andrew Sullivan <ajs@crankycanuck.ca>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <20110329122510.GG88058@shinkuro.com>
References: <20110329122510.GG88058@shinkuro.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 22 Jul 2011 11:33:47.0372 (UTC) FILETIME=[387F22C0:01CC4863]
Cc: int-area@ietf.org
Subject: Re: [Int-area] Probably ignorant question about <http://www.ietf.org/id/draft-briscoe-intarea-ipv4-id-reuse-00.txt>
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jul 2011 11:33:50 -0000

Andrew,

If you'll forgive me for replying 4 months late - while looking for 
something else, I just found this in my spam box (sorry). Inline...

At 13:25 29/03/2011, Andrew Sullivan wrote:
>Hi,
>
>I was going to ask a question about
>draft-briscoe-intarea-ipv4-id-reuse-00.txt in the meeting today, but
>we didn't have time.  This is probably a know-nothing question, so
>feel free to point and laugh.
>
>Over in DNS-land, we twist ourselves into funny shapes not to change
>things because we always feel that we simply don't know what people
>might be doing with things that were once legal.  There are plenty of
>things we'd like to get rid of, and things we'd like to require, but
>in all cases we can't because we don't know what people have relied
>on.  Effectively, in the DNS, once something is defined we have to
>live with it more or less forever, no matter how much better we know
>we could make it.
>
>As someone said in the meeting, the bit being proposed to reuse is in
>fact set now.

If you mean the bits in the ID field, yes all combinations are 
already used, and the idea is to get a probabilistic protocol out of 
it if bit-48 is not set, or deterministic if it is.

If you mean bit 48 is already set, then no. It's reserved and must be 
zero. Sensible people interpret as "must be set to zero when 
sending", but some interpret as "when forwarding if it's not zero 
discard," or worse "when forwarding revert it to zero". We have to 
cater for all of those. We can't just assert that people should all 
agree with what we think sensible means. That's why this proposal is 
in two stages, without setting bit-48 in the first stage.

If you mean some people might be setting bit-48 to one for other 
purposes, I'm sure they might be. But:
- if they didn't bother to get it standardised we can't hold back 
from standardising setting a reserved bit to one in case we trample 
over what someone has already done without asking.
- if they're prior unofficial use screws up our attempts, we'll only 
find out by trying it out
- from limited tests if anyone is setting bit-48 to 1, it's not 
visible on the public Internet

Yes, of course we wouldn't do this if we had some other options. DNS 
is tight, but it has a lot more room for manouevre the the IPv4 
header. Therefore, when trying to make space in the IP header, 
perhaps we will at least get somewhere if we relax the requirement to 
be perfectly rigourous about possible collisions with unofficial 
prior activity.

HTH


Bob


>So how do you know that changing the rules about that
>bit won't break anything?  (This is not a rhetorical question.  This
>topic isn't really my comfy place in the stack, and I don't know.)  I
>guess this is partly addressed in section 6, but that's just facing
>the middlebox case, I think.
>
>Best regards,
>
>A
>
>--
>Andrew Sullivan
>ajs@crankycanuck.ca
>_______________________________________________
>Int-area mailing list
>Int-area@ietf.org
>https://www.ietf.org/mailman/listinfo/int-area

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design