On 15-aug-2007, at 23:48, Mark Smith wrote:
I'm don't think I'm going down it. You seemed to be questioning why
subnets were fixed length,
How are subnets fixed in size??
The discussion we were having was whether DHCPv6 in particular or any
mechanism in general should distribute a subnet size in the form of a
prefix length along with IP addresses. This discussion is only
relevant when the size isn't fixed.
Although there is that infamous line about 64-bit interface
identifiers for everything except ::/3 in RFC 3513 (the origin of
which nobody has been able to explain so far despite my repeated
requests), IPv6 has always been classless with no assumptions about
the structure of addresses.
I think that shows that when there is the opportunity to
have fixed length node addressing it is very desirable, and has been
chosen by many protocol designers (DECNET Phase IV has it too, IIRC)
Note though that all these protocols were designed for networks with
a limited scope, unlike IP which was more or less designed and then
became the protocol for all devices in the whole world.
The problem with a fixed length is that it's always either too large
or too small. So when we get around to designing the successor of
IPv6, we really need to use variable length addresses for that.
I like that IPv6 can place the boundary between the network and node
portion anywhere within the address, unlike IPX and Appletalk. It
future proofs the protocol, ensuring that should the network or node
portions not be big enough they can be changed
Right. It means that whatever we do, we'll never run out of IPv6
address space because if needed, we could run the entire network on a
single /64. That's still 32 more bits than IPv4 has.
OTOH, I don't like _unnecessary_ complexity. Currently,
we don't need to engage any of the complexity of non-fixed network and
node portion boundaries in IPv6, so let's not until we need to.
Allowing for something doesn't mean you must use it.
"Use it or lose it." If you run a network with a defacto boundary at /
64 for a decade, don't be surprised when you can't move that boundary
without breaking stuff.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
