Date: Mon, 12 Aug 2002 15:34:04 -0400
From: Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| It's more than just autoconfig. Right now, End sites can expect to get
| a /48, and they get use the 16 bits between a /48 and /64 anyway they
| care. If a site switches providers, it knows it will get 16 bits
| again, and it konws that it needs to (only) renumber the upper 48
| bits. This is both simple and powerful.
Yes, it is. But it is the /48 which is the crucial number there.
Not /64 - that one is irrelevant.
| This comes in large part from the uniform /64 boundary between the
| adddress and the IID.
no it doesn't. The only influence that had was on the value "48".
The need for some nice fixed boundary for the purpose you elucidate
is the driver for the fixed "48". If it weren't for that (and the
way the earlier argument went) we'd be allocating /56's to small
organisations - not because the /64 could be moved, but because 8
bits of subnet (an old class B remember) is enough for many organisations.
| If that were removed, it would potentially
| reopen discussion about which bits and end site should get for subnet
| addressing, with different people possibly being given different
| ranges and (even worse) different amounts.
no it wouldn't. No-one is even contemplating removing the /64 from
being required for autoconfig on an ethernet (and other LANs). That
means that all a site is ever going to need to do is say "I want to
use 802.x" (for any x > 2) and then they need /64 for that. Then,
nothing here is influencing the expectation of 16 bit SLA space. So,
there's no way that argument could happen again.
| I think this would be a bad
| direction for us to go in. I don't see what the benefit would be, but
| I can surely see a number of non-productive areas we'd surely rathole
| on.
Sure, but no-one is suggesting that, so why waste time arguing against it?
| This is a key question. Just because operators are doing this, doesn't
| mean they should or that we should just give in and say "I guess we
| should give in to reality".
No. But unless you're planning on rewriting 2026 before this gets
advanced to DS, don't you think you could at least pretend that you're
going to do what it requires?
Features that aren't implemented must be removed from the spec.
It really is very simple.
If you (the whole WG) like, that can get put in some other doc as a
new PS, that can just sit in PS status, until you can actually find
implementations of it ...
| There is a cost/benefit of sticking with
| the /64 boundary. Before moving away from it, we really need to
| understand the cost/benefit of the alternative.
The major benefit is that we avoid people pretending they're able to
look inside my addresses and deduce meaning there - and then complain
that I'm not obeying some standard when they're wrong. The cost?
Well, I'm having a hard time finding one at all, or a measurable one
anyway.
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
