Print

[dodecatec]

For ease of administration and easier hierarchical design, we want to use longer prefixes on our subnets.
For example, we want /120 subnets for small networks and so forth.
Cisco equipment seems to have no problem with this.  However, Windows (XP, 2003, Vista, and 2008) all seem to want to use /64 only, which leads to routing problems.  These machines can communicate fine on their local subnet, but cannot communicate with other hosts that would have otherwise been on the same /64 but are not on their local /120 vlan.

Example:

Subnet 1: AAAA:BBBB:CCCC::0/120
Subnet 2: AAAA:BBBB:CCCC::100/120

Router 1: AAAA:BBBB:CCCC::1/120
Router 2: AAAA:BBBB:CCCC::101/120

Host 1: AAAA:BBBB:CCCC::2/64
Host 2: AAAA:BBBB:CCCC::102/64

Routers are at separate sites, connected via a GRE tunnel.
The routers can ping each other's ethernet interfaces through the tunnel and both networks show up in both routers' tables (using EIGRP as routing protocol).
The routers can also ping the hosts local to them.
However, as expected, given the prefixes, the hosts cannot reach each other, since they do not bother to talk to the router.

When I try to set the addresses for the hosts as:
Host 1:AAAA:BBBB:CCCC::2/120
Host 2:AAAA:BBBB:CCCC::102/120
Windows just sets the prefixes back to /64.

How can I alter this behavior, or is it even possible on Windows?

Thanks

[jimb]

Interesting.  You may want to poke around in the netsh interface and see if you can see anything which allows this.  

One thing I've never gotten an answer on from anybody is the question of whether /64s are just a sort of default, allowing auto-configuration, or if they're actually mandated by some RFC as the longest prefix possible.

If you can't get windows to play, then it's really a moot question.  You'll have to adjust your numbering plan to use /64s as longest.

[dodecatec]

That's where I started looking, after about 30 minutes of googling and getting no results about what I wanted.
I poked around in netsh for a while and found the siteprefixlength property of a few items, but it doesn't seem to change this behavior.

There's really no problem in adjusting to use /64s, but I just like the idea of being able to do AAAA:BBBB:CCCC::1:2:101/120 for the router of the second subnet of the third building of the second site.
Using /64s out of the /48, I'd have to revert to subnet numbers alone, which would mean a chart.  With the private 10.0.0.0/8 IPv4 range, I can organize it hierarchically like this.  Cisco equipment seems to be able to handle the same with IPv6.  I don't understand why other implementations (or, I sure hope not) the standard would prohibit less than 64 bits in the host portion of the address.
If the standard really is that badly written, sure we just gained a ton of address space, but when billions and billions of nanomachines start wanting their own addresses, that's going to suddenly seem like a remarkably stupid idea and we're going to have to make sweeping changes to address allocation.

And don't say it won't happen.  We are all here implementing IPv6 for a reason, aren't we? ;-)

I give it 15 years.

[jimb]

Yeah I had similar reactions when I first saw the standard of using /64s for subnets under v6.  It seemed like a huuuge waste of address space, and the only justification I can see for it is IPv6 autoconfiguration which calls for an EUI-64.

I was somewhat taken aback by seeing, for instance, how HE uses /64s for tunnel endpoint "transit"  addresses.  Under v4 we would typically use /30s for something like that, since it only requires two IPs.  I expected to see /126s (/127s?) for this sort of thing under v6, but nope, full 18.5-million-trillion host /64s .

[kcochran]

Even if the practice of using /64s for p-t-p address ranges becomes a problem, IPv6 allocations are only coming out of 2000::/3.  We have 7 more /3s to work with and do it better the next time, and without having to change the underlying protocol.

[jimb]

Even if the practice of using /64s for p-t-p address ranges becomes a problem, IPv6 allocations are only coming out of 2000::/3.  We have 7 more /3s to work with and do it better the next time, and without having to change the underlying protocol.

Yeah granted, the V6 space is mind bogglingly enormous.  But the whole /64 thing bugs me a bit because it seems like such a huge waste of those lower 64 bits.  

Also, note that I'm not criticizing HE here!  It seems like it's SOP.  I was just surprised to find it was SOP when learning about IPv6.

[brad]

For ease of administration and easier hierarchical design, we want to use longer prefixes on our subnets.
For example, we want /120 subnets for small networks and so forth.

Personally I don't buy your rationalization for doing this. Yes I have read all the opinions in the world about being as conservative as possible even when implementing v6, but you're not working with some ridiculously finite resource like with v4. Plus you can't use anything longer than /64 if using RA. I do agree with the longer prefixes for PtP links, tunnels, etc. but at the same time I wouldn't be making a big deal out of using /64's either.