Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

[Simon Hobson <[e-mail]>]

Mark Smith <[e-mail]> wrote:

> Do we have to purposely make something hard and costly to use before we can make it easy and cheap to use?

Turning that around, do we have to hard-code limitations in that we cannot know the consequences of ?
Even hard-coding /64 doesn't remove the need to be able to work with variable length prefixes in all but the most trivial of systems, and given modern hardware capabilities, the processing cost can hardly be called expensive (even on the most basic of processors). Bear in mind that it's now hard to buy a processor that isn't orders of magnitude more powerful (and resource endowed) than the computers that first put men on the moon.

EVERY router must possess the ability to work with variable length prefixes. Every protocol stack in any OS/firmware that "might" ever be used for routing mist therefore support variable prefix lengths. So in the general case, there will be very little (if any) saving in software costs. In fact, having a /64 hard coded MAY allow a different code structure - but this is likely to be in addition to the variable prefix length code, and thus increase the amount of code to be written and maintained.

All this is supposed to be transparent to the end user - so it shouldn't matter to them. And anyone working with networks will need to understand variable length prefixes (48 =/= 56 =/= 60 =/= 64) so unless no-one gets anything but a /64 from their ISP then the argument about not having to learn about variable prefix lengths goes out the window as well. So now we have a default of a single /64/customer - and needing customer involvement if all those nice things (Homenet ?) that want multiple /64s are to work for them.


> Do we have to treat IPv6 addresses like diamonds, before eventually accepting the *maths* that shows they're at least as common as grains of sand.

Just this week, over on the ISC DHCP users list, there was a question regarding changing PD sizes which turned out to be a bug in the server package. However, this ISP defaults to offering a single /64 with the option to switch to a /56.
I did ask why not to default to /56 - the answer being that they've hit a small number of CPE routers that couldn't handle anything but a /64 PD. Given the choice between something that "works for most people out of the box" and having to take support calls and explain why their cheap-n-nasty router didn't work - they chose the option of a single /64 by default.

I'd suggest that this is a side effect of the "/64 everywhere" mantra. Someone inexperienced has picked up a spec, seen that "everything is /64", so they've (incorrectly) assumed all they need to deal with is a /64.
You can argue that the person/group responsible for this pile of rubbish didn't read the specs correctly. That may well be the case. But when so many documents all read as though /64 is set in stone, it's not hard to see why someone reading them quickly (as in manager has told them they have a short bit of time to learn the subject and bash out some code) might miss the subtlety.

I can see the argument for "make it simple", but that is a recipe for hardcoding in constraints in the future. Some kit (or bits of software) goes on and on for a long time. I recall getting bitten a long time ago when (many years after classless addressing was history) I came across a bit of kit that enforced class rules - specifically wouldn't allow a 192.168.nn.nn/23 address to be configured. As a result, I had to renumber the network into the 172.16/12 block to accommodate this bit of code. The unit itself wasn't very old (in manufacturing terms), but the design and the code in it was.


> People who believe IPv4 addressing that we have today is an ideal that we should be aiming for in IPv6 are probably unlikely to be aware of IPv4 history of addressing evolution, or the research or proof-of-concept network context it was originally designed and chosen for. IPv6 is really the first true Internet protocol, and should not be artificially inhibited by the legacy of IPv4's design context, practices, constraints and workarounds.

I think you are disingenuous labelling the argument in such terms.

I'm not arguing against having /64 as the default - but I am arguing against hardcoding in assumption that may well turn out to be incorrect, and hard to correct due to having been hardcoded into various implementations (that might not even be supported by the vendor any more).

I'm sure many developers (or at least, their managers) once thought that their code would never be used into the year 2000 - that turned out to be an incorrect assumption. The history of computing is littered with similar examples where people went for the 'easy" option, only to hardcode in something which later turned around to bite their backside. I keep seeing an argument for the easy option of "/64 everywhere" which is ALREADY causing problems.