Mark Smith a écrit :
On Wed, 18 Feb 2009 22:16:33 +0100 Alexandru Petrescu
<[email protected]> wrote:
Mark Smith a écrit :
On Wed, 18 Feb 2009 21:03:54 +0100 Alexandru Petrescu
<[email protected]> wrote:
Dunn, Jeffrey H. a écrit :
Alex,
While I believe that Suresh is correct in the case of RFC
2464, I am very interested in the Ethernet implementation
that supports non-64 bit IID. Do you have a reference for
this implementation? Further, are you interested in
supporting non-64 bit network prefixes? If so, let me know
offline and we can discuss.
Hi Jeff, this (non-rfc2464 IIDs) is possible for other reasons,
but hasn't been implemented. I'm happy interest is expressed.
In the previous mail I meant to say typical 64bit Ethernet IIDs
but shorter prefix (shorter than 64bit, for example 56bit).
This implementation is what I meant I know exists.
Why is this useful? BEcause it is easier to send RAs with a
prefix length that reflects the prefix length really assigned
to that router.
Isn't a /64 big enough for all conceivable and practical subnets
?
Well yes. I think /64 is big enough, maybe more than necessary.
But if I'm allocated a /48 and do a few subnetting I arrive to
around /56 or /60 to my edge networks. Thus I don't understand why
forcing them to be /64.
Some people want to make that longer because they consider it to
be way too much!
Well yes, I have even crazier ideas - non-contiguous prefixes
(reuse the wasted fffe space in the middle of the IID), but here
I'm not complaining about that. It'll never fly at IETF anyways.
Actually I'm very surprised to learn people seem to agree all
Ethernet links should have precisely 64bit prefixes in the RAs.
It's all links, not just Ethernet, because it's simpler to work
with. If every subnet is a constant /64, then you never need to
specify it, and nobody can ever make configuration errors.
Variable length node addresses in IPv4 make sense because IPv4's
address space is small and tight. With 128 bit IPv6 addresses,
there isn't that issue, so operational simplicity becomes more
important.
Well operational simplicity may be apparent, sometimes not :-)
It's no apparent to me - I've run IPX networks, so I *know* it's
simpler :-) Learning IPv4 and it's subnetting was hardwork after
having "learned" or just had work IPX networking. But that was the
difference between protocols designed in the late 1970s vs the mid to
late 1980s.
Ah yes, that sounds right :-)
A typical dialogue goes like this: "how much IPv6 space do you need
for your network?"
That question generally isn't really intended to be asked anymore.
Yet it pops up in so many settings I see regularly when building new
networks :-) I don't think it will ever go away.
The common case intent is that most people will always get enough
address space for what they need - actually far more than what they
need, so that they rarely if ever need to come back and ask for more.
IPv6 address space is really "cheap", so it doesn't hurt to give
people much more than what they need, so they don't have to come back
for more.
Well somewhere here there's a paradox. An operator gives me a /64
telling me it's more than I'd ever need. Which is true, it could
accommodate 2^64 nodes.
Yet I can't subnet it. Only one subnet! Which of course can't support
2^64 nodes because the link layer can't support that.
Were that /64 prefix of the Ethernet SLAAC be more flexible (the prefix,
not the IID), the operator would be more aware of this impossibility to
subnet.
Alex
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
