RE: draft-bourbaki-6man-classless-ipv6-00

["Manfredi, Albert E" <[e-mail]>]

-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of [e-mail]

> What _problem_ does changing the 64 bit boundary solve for _you_?

A category of problems, such as creating hotspots with smartphones that have been allocated a single /64. A real-world situation, in which there's no conceivable reason to have to go hat in hand to service provider, asking for more /64s. And in fact, from an operator's point of view, would not a user asking for more /64s be a bigger pain than a user subnetting his own /64, with no consequence at all to the operator?

I do acknowledge the "race to the bottom" potential. Then again, being overly stingy with /64s amounts to the same thing. Operators can make things bad, no matter what solution you adopt. Allowing the boundary to move gives users and app designers more flexibility and independence. For some players, that's a good thing.

Plus, I oppose the idea of artificially declaring that a fixed IID length is associated with each link type. This is a legacy notion, driven by rationales no longer valid. It's an unnecessary constraint. Or if stated, add a historical note as to why you have stated it.

If part of what makes IPv6 wonderful is SLAAC, then I don't think it's wise to cripple non-/64 solutions by artificially mandating that SLAAC be only possible with /64s. The smartphone hotspot example is one in which a non-/64 SLAAC would work great. And there's simply no reason to state that SLAAC can only work with /64s. It's not true!

Using RECOMMENDED for /64s? IMO, that RECOMMENDED would only apply to operators. It should be RECOMMENDED that ISPs not hand out /128s, or other overly long prefixes. I would almost rather use the word "typical." The "typical" prefix at the "operator to user boundary" may be /64 (or /56 perhaps). But app designers and users? No, there should be no such recommendations.

Bert