http://www.ietf.org/id/draft-briscoe-intarea-ipv4-id-reuse-00.txt>

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 <at> crankycanuck.ca
>_______________________________________________
>Int-area mailing list
>Int-area <at> ietf.org
>https://www.ietf.org/mailman/listinfo/int-area

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design