Reasonable points, though I think it was more about easing hardware implementations of the stack than about dealing specifically with memory-constraints. That said, I would still protest anything that breaks SLAAC; SLAAC is very useful. If you want to describe how SLAAC would operate in a completely classless system, I wouldn't mind discussing it.

What are these incorrect assumptions you describe, and can you point to some of the examples of them coming up? (Just honestly curious)

You are aware that all major IPv6 stacks have IPSec support? Forget that the standard doesn't explicitly require it...Linux, *BSD and Windows have long shipped with working versions.

You still haven't given any technical reason why "prefix-length === 64" should be dropped; you've called it stupid and unnecessary, and the best you've done is indicate you don't care that doing so would break SLAAC. I like and use SLAAC, which depends on that 64-bit minimum subnet size; your 'unnecessary' argument doesn't hold in that context.

Why?

To begin with, DHCPv6 runs counter to privacy extensions. That rather sucks. Also, I recommend actually reading RFC 4941. There's more to privacy extensions than it appears you realize.

It's also worth noting that those 16 bits between your MAC address and the width of a /64 are used for encoding type information. That makes it a useful diagnostic, and not something to be discarded lightly.

You do realize that breaks SLAAC, right?

You have to have multicast routing set up between you and the networks you want multicast to go to...and the clients have to 'subscribe' to your multicast group. They won't hear anything from you until they tell their local multicast router they want to talk to you.

So, yeah, multicast doesn't generally work unless you're on the same subnet. That said, here's a fun one to run under Linux:
ping6 -c2 ff02::1%eth0

Any hosts configured to respond to ICMP6 echo requests will send a reply. I once counted several hundred hosts on my VPS provider's network that way.

Just curious: Where do you fit privacy extensions in that scheme?

Set up an application-layer proxy on a host with both addresses, same as you would with IPv4.

So, set up a machine running Squid, where that machine has IPs from both your upstream ISPs. All your internal clients can use that Squid proxy to get out. SIP? No problem; use a SIP proxy.

Since you're pushing the 'logical, not physical' link angle, you can go one step further and set up a tunnel to another endpoint on the Internet, and use that as another possible route. (i.e. I have IPv6 access because I use a proto41 tunnel from Hurricane Electric)

If you don't want to go that route, have radvd announce both prefixes on your internal network, and allow clients to select which source address they use. Use short 'preferred' lifetimes, and you can have some daemon tweak your radvd configuration whenever you decide you want to favor one prefix over the other.

But, really, an application-layer proxy is your best option.

Tracking ability is going to be driven more by browser request headers than by IP address, anyway.

I expect ISPs will get beyond /64s within a year or two. Being stuck with only a single /64 is BS; I have my home wired and wireless networks on different subnets for pretty simple (but entirely valid) reasons:

• Broadcast and multicast traffic on a gigabit link doesn't risk flooding the far-slower wireless link
• It makes it trivially easy to partition off wireless clients from wired clients, reducing the vulnerability my wireless network gives me. I'll be able to do even better once I split off to two SSIDs, one for guests and one for trusted users; guests wouldn't get access to any of the rest of the network.

Heck, multi-SSID behaviors with varying trust levels are finding their way into consumer routers already (while I'm wardriving, I see a lot of -guest networks coming from residences...even a very non-technical friend of mine has a -guest network that came up by default with their consumer router.), but that can't work if the routers don't have enough address space to work with.

ULA addresses are good for having 'private' address ranges. Don't rely on link-local. As sexy as it sounds, a lot of tools (especially browsers) don't handle them well; they get hung up on the concept that an IP address may be valid only when combined with an interface.

Look up IPv6 privacy extensions.

Also, realize that corporate environments are probably going to push you through an HTTP proxy server...which will then appear to be the origination point for traffic. Your workstations don't need to be exposed.

Look up ULA addresses. You're going to love them.

What makes you think networks are all about hardware?

Nope. The class's name was geography. Once upon a time, they also taught some geology under those classes. That I remember.

Not a heat issue, it's a pressure issue. The fluid rock in the mantle squezes up into magma cavities underneath under the volcanos.

Now, it's possible to have a solid rock cap on top of such a cavity, but that results in massive explosions of smoke and ash (see pictures of cone-type volcanos) rather than long flows of very fluid magma (see pictures of shield-type volcanos).

Granted, it's been a couple decades since I covered any of this in a geography class, so I could be wrong.