Date: Sat, 10 Aug 2002 23:52:46 -0700
From: "Michel Py" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| I do not agree. When designing IPv6 ASICs, one might like the hard limit
| at /64, for example.
In that case, the ASIC won't be able to handle routing to anything on
a local link, will it? All addresses on the link would look the same.
That's going to make it a pretty slow router for sending to local
addresses, while fast on things just passing through to somewhere else.
You can buy a router like that if you like, I know I won't ever.
My /112's aren't going to bother your router with its /64 assumption, and
the routers I use aren't going to be bothered by my /112's.
So this "64 bit is faster" argument is nonsense (or, if you prefer, FUD).
| You are trying to use the 'u' bit as a scapegoat. If there was
| compelling reasons to remove the hard /64 boundary, I don't think the
| 'u' bit would be much of a problem.
No. The only possible reason for keeping the 64 bit boundary is
because that 'u' bit is there, and someone might want to interpret it.
If it weren't for that, and the bits in my addresses had absolutely
no interpretation available to you, then whether or not I am using a
64 bit prefix or longer is, and always will be, 100% irrelevant to you.
There's no justification at all for the standard saying that everyone
must do something that has no impact on anything at all.
Not that it matters, as people would simply ignore it anyway. No-one
outside their site would ever be able to tell the difference.
The 'u' bit is the one problem for this - if people were to seriously
expect to be able to look at someone else's address, and draw some kind
of conclusions based upon the state of the 'u' bit, then that bit simply
has to be in the IID part, it couldn't be in the prefix. That means
that if we could justify keeping 'u', the hard /64 would have to stay.
But it seems that even you have given up on support for 'u' ...
| This is not the way it works, IMHO. If the draft is there it's because
| it has reached consensus. The consensus question is about the changes
| you suggest, not the current state of the draft.
The draft is just a draft. The RFC it is replacing received consensus.
Now it is being updated and changed. That's normal when a draft moves
from PS to DS. We get a chance to review the doc, and discard the parts
that have, with implementation experience, been seen to be wrong, or
usless, or unimplementable.
That is what is happening here, the current draft is just a work in
progress, towards that update.
| I am using /64s for ptp links. They work fine. The argument that I am
| wasting precious address space is fud, as my site gets a /48 anyway.
Who ever argued that you are wasting address space. If you want to
use /64's for p2p's and they work for you, that's just fine. No-one here
is attempting to require you to change that. From where did you get
that impression? Or is it just easier to argue against points that weren't
made than ones that were?
| Only for the very few sites that actually require more than a /48 can
| there be a gain using longer prefixes,
If you reword that as "require more than a /48 because of they have lots
of p2p links, and someone is claiming that /64 is mandatory", then yes.
But the University of Melbourne, by any normal standard, will fit in a /48
just fine, it fits in a /16 for IPv4, and hasn't run out of addresses yet
(things are sometimes a bit tight, and the college residences now all have
numbers from other address spaces I believe, but we manage - and without NAT).
If 2^16 addresses work for us now, I am pretty sure that we should be
able to manage with 2^80 forever... (even using /64's for all our
LAN type links, now and into the future).
So, we "don't actually require" more than a /48 - you just want to force
us to consume more.
Why? What are you gaining from this?
| and most of the time that gain is
| null as well because sites that require more than a /48 do have internal
| aggregation,
Of course.
| and there again the /64 point to point links are lost into
| the internal addressing structure.
No, if they're included in it, they dwarf it, and that's what would cause
the "require more than a /48".
Instead, the p2p links have their own aggregation hierarchy (which then
can be included in the wider organisation hierarchy).
That works, because it is usual for lots of p2p links to terminate at
or about the same place (at one large router, headend, ...). All the
routing system needs to see (other than at that box) is one route to it,
for all of its p2p links. Only inside that box are its hundreds (or
thousands) of p2p links ever visible (and at the far end of each
individual link of course, but routing there is generally "default and me").
| For ISPs/operators, assigning /64s to ptp links wastes 1/64k of their
| customer address space, peanuts.
If it is all in one /48 of their /32 (which limits them to absolute max
of 64K p2ps of course, which isn't a big customer base really) - but then
they're going to have to be shipping around explicit routes to all of those
p2p prefixes (/64's) or they're going to have to do some kind of
internal aggregation inside the SLA, which of course, means less
available addresses, and more wastage.
It might seem like peanuts, but it all starts to count.
Now if there was some technical justification for why it needed to be
this way, then perhaps we could say, OK, we will be wasting some addresses,
but here's what we gain from that ...
Like to complete that paragraph?
Currently the answer is "nothing".
| Here is where I stand: the RFC says that you should use /64. The only
| real argument to use longer prefixes is conservation, and it's fud. The
| potential 25% savings in 1% of situations is not worth modifying the
| addressing architecture document, as respecting it costs no more than
| not doing it, and as it has reached consensus.
That is, the technical argument for it is that we once thought that it was
correct, and even though no-one now is able to explain how we reached that
conclusion, we did it, and hence it must be correct forever.
In that case, why aren't you opposing the proposed change of the subnet
local SLA field from 16 bits to 54 (or however many it is). We once decided
that 16 was the right number, and all the other bits had to be 0. The
RFC says that. The potential problems with the tiny number of sites that
can't fit in a 16 bit SLA is not worth modifying the addressing architecture
document, ...
Really!
We are modifying the doc. We are producing a replacement doc. The new
one will obsolete the old one.
There's no cost anyone has been able to enumerate to making the change.
(If one wanted to be petty, one could show that the RFC will be a couple
of K bytes smaller, and so by making the change we're both making it
easier to read and understand, and saving that disc space...)
And no, that isn't a good argument for doing the change.
The better argument is that the current doc is unimplementable,
untestable, and meaningless. It is quite simply, wrong.
And then we also have to follow 2026 process rules. That means documenting
that all the features of the protocol are actually implemented - otherwise
that MUST be removed when the doc advances to DS. Those are the rules.
This stuff isn't enforced anywhere (the /64). The 'u' bit (other than the
way it us used during autoconfig, which is fine, and should remain) is unused
anywhere.
If we want this doc to have a chance to advance, assuming the IESG follows
the IETF's rules, we *have* to remove those parts.
If we thought they were worth keeping, we'd be putting them in a new doc,
and making that one be a PS, and leaving it there until either the parts
find uses, and so qualify for advancement, or the whole thing gets ignored,
and in 10 or 15 years, someone wake up, and causes the doc to move to
historic.
If we just think it might be a cute idea for people to play with, we'd
make it be experimental (like, say A6 ... remember how that had consensus,
and was documented in an RFC, and was actually implemented and used, and
what happened to it???)
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]
--------------------------------------------------------------------
