<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 5, 2019, at 13:36 , <a href="mailto:bzs@theworld.com" class="">bzs@theworld.com</a> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">On October 4, 2019 at 15:26 <a href="mailto:owen@delong.com" class="">owen@delong.com</a> (Owen DeLong) wrote:<br class=""><blockquote type="cite" class=""><br class="">OK… Let’s talk about how?<br class=""><br class="">How would you have made it possible for a host that only understands 32-bit addresses to exchange traffic with a host that only has a 128-bit address?<br class=""></blockquote><br class="">A bit in the header or similar (version field) indicating extending<br class="">addressing (what we call IPv6, or similar) is in use for this packet.<br class=""><br class=""></div></div></blockquote><div><br class=""></div>This still requires you to basically rewrite the L3 stack to accommodate the new addresses.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">They may not be able to talk but rather than a whole new stack it<br class="">would have just been an extension of the commonly used IPv4 stack,<br class="">more like a (e.g.) new ICMP option.<br class=""></div></div></blockquote><div><br class=""></div>Uh, no, it would still have required reimplementing the entire L3 stuff at pretty much the same</div><div>work level as the current IPv6 mechanism. You would still have needed to update:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>All L4->L3 binding code</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>All Name Resolution code</div><div><br class=""></div><div>You’d still be faced with all the really hard problems that came with IPv4->IPv6 transition:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Updating your applications to understand 128-bit addresses in logs, etc.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Updating your provisioning systems to track 128-bit addresses.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>etc.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">Or even an octet indicating how many octets in this address, default<br class="">would be four (or even a nybble indicating how many 16-bit words.)<br class=""></div></div></blockquote><div><br class=""></div>This doesn’t make transition any easier and it makes ASIC processing of</div><div>packet forwarding a heck of a lot harder.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Something simple like that could have, at least in the early stages<br class="">(which we're still in w/ IPv6 unfortunately), have been entirely<br class="">handled in userspace in the software.<br class=""></div></div></blockquote><div><br class=""></div>Nope… It really couldn’t and that would actually be worse… Right now, the biggest hurdles</div><div>to IPv6 adoption aren’t the kernel level changes for a new stack, they’re the legacy application</div><div>changes needed to support bigger addresses.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">IPv4? Do the usual. Extended addressing? Hand to a userspace<br class="">library. A minor poke to the drivers plus the userspace software. In<br class="">many cases wouldn't even require a reboot to install, but at worst a<br class="">quick reboot to install the low-level driver that knows to switch<br class="">extended addressing packets to userspace.<br class=""></div></div></blockquote><div><br class=""></div>I think you’re very confused about where the pain points with IPv6 are and what it would</div><div>take to actually implement what you are suggesting here.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Particularly if the low 32 bits indicated the same IPv4 interface w/in<br class="">a campus so primarily only the routers needed to interpret the rest of<br class="">the address.<br class=""></div></div></blockquote><div><br class=""></div>Uh, so a packet arrives at your 32-bit only application and you can’t tell whether you</div><div>need to reply to the student’s laptop on the other side of the room or the linear</div><div>accelerator 3,000 miles away because that’s all included in the 96 bits you didn’t even</div><div>see that got spirited away to some user-space translator layer.</div><div><br class=""></div><div>What am I missing?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">So it'd get to the right router who'd hand it off to the right<br class="">(32-bit) host. Only a problem if your campus happened to have 4B+<br class="">hosts (or maybe 2B+), not likely.<br class=""></div></div></blockquote><div><br class=""></div>Or if you need to communicate both within and outside of your campus (far more likely).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">It's similar to IPv4v6 stacks but the host would return the full<br class="">address in the (extended) IP packet.<br class=""></div></div></blockquote><div><br class=""></div>How’s the host supposed to do that if the host hasn’t been updated to handle extended</div><div>addressing? If the host has been updated, then there’s no difference from the current</div><div>situation with IPv6… The need to update every host (and these days, more relevant,</div><div>the need to update every application).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">In current IPv4v6 stacks (NAT et al) the router has to keep track and<br class="">interpolate by rewriting the packets or similar. In what I describe<br class="">that's not necessary as each packet retains the full address as it<br class="">passes through the host.<br class=""></div></div></blockquote><div><br class=""></div>Yeah, except, you’re assuming every host gets updated with the necessary software to</div><div>handle essentially IPv6 addressing without adding the IPv6 stack. This sounds like more</div><div>pain for less gain to me.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Well, basically your question asks for a complete stack design right<br class="">here right now, is that really where we want to go?<br class=""></div></div></blockquote><div><br class=""></div>My point is that the changes to implement IPv6 on a given host (at the kernel level) are</div><div>not significantly more than the changes you are proposing to do what you want. Difference</div><div>is that they’ve mostly been done for the vast majority of hosts for IPv6 whereas yours would</div><div>be a new implementation.</div><div><br class=""></div><div>It still doesn’t yield any greater compatibility because you’ve still got the difficulty of coping</div><div>with the applications that simply can’t understand a larger internet (which is the biggest hurdle</div><div>with IPv6 right now).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">But the sort of thing I suggest was suggested.<br class=""></div></div></blockquote><div><br class=""></div>And did not gain consensus for the same reasons I outline above, I suspect.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Some of the considerations as to why not do it this way were good,<br class="">such as get some other bugs/limitations out of IPv4. And some not so<br class="">good like bit-level performance and compatibilty considerations that<br class="">have changed considerably since 1990.<br class=""></div></div></blockquote><div><br class=""></div>Hindsight always yields what seems like errant judgment calls 30 years ago.</div><div><br class=""></div><div>At the time, they seemed like a good idea.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Were the 36-bit'ers still at the table in 1990? Probably.<br class=""></div></div></blockquote><div><br class=""></div>36-bits would have been a terrible idea, frankly. Look how long it’s taken for IPv6</div><div>to get any real traction? Think about how painful it will be if we have to try and</div><div>change the address format again?</div><div><br class=""></div><div>Far better to go for such an excessive number of addresses as to obviate the problem</div><div>as permanently as possible. It’s not that I think IPv6 will last for ever, I’m just hoping that</div><div>it’s something other than address shortage that leads to its obsolescence. In fact, if we</div><div>don’t have an address shortage, the next protocol might be able to continue using IPv6</div><div>addresses and reduce the transition pain.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">And CGNAT et al wasn't really conceived of yet or not very completely<br class="">so it was assumed this would all be so urgent as to propel itself into<br class="">the mainstream.<br class=""></div></div></blockquote><div><br class=""></div>Frankly, I’m not convinced we wouldn’t all be better off if CGNAT hadn’t been conceived</div><div>and implemented and this had been so urgent as to propel itself into the mainstream.</div><div>It certainly would have been a higher level of pain in the short run, but it also would have</div><div>led to a much shorter period of pain.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">How would you have made a 128-bit address more human-readable? Does it really matter?<br class=""></blockquote><br class="">That really depends on your priorities. If the priority was, as with<br class="">ipv4, location independence so all bits are equally meaningful (i.e.,<br class="">necessary to know what's desired), then it's difficult.<br class=""><br class="">If it were actually treated as a potential problem then more defaults<br class="">may have been engineered in.<br class=""><br class="">But since this is a human interface problem I lean towards better<br class="">software to view and manipulate addrs and let the engineers do what<br class="">they need to do.<br class=""></div></div></blockquote><div><br class=""></div>Seems reasonable, but I think what we’ve got is reasonably good.</div><div><br class=""></div><div>I have found that with a little experience and a good subnetting plan, IPv6</div><div>addresses can become quite human readable when it matters.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">It's the tail wagging the dog or perhaps the dog returning to its, um,<br class="">whatever.<br class=""><br class="">We developed, w/ IPv4, this entire culture and software regime which<br class="">thought it was reasonable to sometimes enter/read IPv4 addrs because<br class="">they weren't too hard and then carried that over to IPv6 (not in<br class="">theory, in practice.)<br class=""></div></div></blockquote><div><br class=""></div>Yes, but I’d argue that the difficulty people have understanding CIDR in IPv4</div><div>and getting net masks and their implications right are a clear indication that</div><div>decimal-coded-octets were NOT the right choice for address readability.</div><div>Further, an IPv6 address using the same scheme would look something like:</div><div><font face="Monaco" class=""><span style="font-style: normal;" class=""><br class=""></span></font></div><div><font face="Monaco" class=""><span style="font-style: normal;" class="">38.32.0.0.144.48.0.0.0.0.0.0.32.0:0.2</span></font></div><div><font face="Monaco" class=""><span style="font-style: normal;" class=""><br class=""></span></font></div><div><font face="Monaco" class="">If my math is correct, that’s the equivalent of:</font></div><div><font face="Monaco" class="">38.32.0.0.144.48.0.0.0.0.0.0.32.0:0.2</font></div><div><font face="Monaco" class=""><span style="font-style: normal;" class=""> 2620: 0: 0930: 0: 0: 0: 200: 2 (keeping the : aligned with the corresponding decimal)</span></font></div><div><font face="Monaco" class=""><span style="font-style: normal;" class="">2620:0:930::200:2 (Human readable form)</span></font></div><div><font face="Monaco" class=""><span style="font-style: normal;" class=""><br class=""></span></font></div><div><font face="Monaco" class="">I don’t know about you, but that looks more like an SNMP OID</font></div><div><font face="Monaco" class="">than anything useful to me. I find the hex representation</font></div><div><font face="Monaco" class="">much easier.</font></div><div><font face="Monaco" class=""><br class=""></font></div><div><font face="Monaco" class="">It doesn’t get better for addresses containing letters, either.</font></div><div><font face="Monaco" class=""><br class=""></font></div><div><font face="Monaco" class="">Consider:</font></div><div><font face="Monaco" class=""><br class=""></font></div><div><font face="Monaco" class="">2620:0:930::dead:beef</font></div><div><font face="Monaco" class=""> 2620: 0: 0930: 0: 0: 0: dead: beef</font></div><div><font face="Monaco" class="">38.32.0.0.144.48.0.0.0.0.0.0.208.173.190.239</font></div><div><font face="Monaco" class=""><br class=""></font></div><div><font face="Monaco" class="">I’ll take the 2620:0:930::dead:beef version any day.</font></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Meaning, for example, if DNS isn't working for you then you're often<br class="">left to entering raw IP addresses manually, and "you" can often be<br class="">non-technical users. IPv4, not a big deal, IPv6, challenging.<br class=""></div></div></blockquote><div><br class=""></div>Well, entering a 128-bit number is going to be challenging no matter how</div><div>you format it. Humans just don’t cope well with large numbers.</div><div><br class=""></div><div>If you’ve got an idea for a better format, I’m all ears. But grousing about the</div><div>fact that 128 bit numbers are bigger than 32 bit numbers isn’t particularly</div><div>helpful, since 32-bit numbers can’t represent the necessary number of hosts.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Mere cut+paste no doubt helps.<br class=""></div></div></blockquote><div><br class=""></div>Certainly one solution. DNS failures aren’t all that common these days in my</div><div>experience, either.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">IPv4 is not particularly human readable. How many hosts do you keep IPv4 addresses in your head for? How long does it take you to get someone at the other end of a support call to correctly transcribe an IPv4 address?<br class=""></blockquote><br class="">IPv4 is not that much more difficult than a phone number. IPv6 is.<br class=""></div></div></blockquote><div><br class=""></div>That depends… Are you including all variations of all international phone numbers in that calculation, or, just NANP numbers</div><div>(e.g. +1.408.555.1212)?</div><div><br class=""></div><div>For NANP, sure, they’re relatively easy, but it’s an 11 digit number where the first digit is always 1.</div><div><br class=""></div><div>That supports a total of 10,000,000,000 devices, which is a bit more than IPv4 since it’s a true decimal number</div><div>and doesn’t suffer from the octet-encoding overhead (0-255 instead of 000-999), so in 12 digits, you only get</div><div>4 billion instead of 10 in effectively 10 digits.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">IPv4 benefits from chunking, like phone numbers.<br class=""></div></div></blockquote><div><br class=""></div>IPv6 has chunking too. The separator is a : and not a - or ., but so what?</div><div><br class=""></div><div>I don’t think 2620.0.930..200.2 is significantly easier to read or better</div><div>chunked than 2620:0:930::200:2.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">If I have an idea of the "net", by which I mean the part which comes<br class="">up repeatedly (such as w/in a campus) often the first two numbers,<br class="">then all I really have to remember anew is the last two numbers, maybe<br class="">only the last. For IPv6 it can be more difficult to commit a prefix to<br class="">memory even if it's used somewhat regularly.<br class=""></div></div></blockquote><div><br class=""></div>I don’t know… I don’t find 2620:0:930:: any harder to remember than</div><div>192.159.10, but perhaps that’s just me.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">But I'd agree this is mostly a red herring, better human interface<br class="">software should help and that might take time to evolve.<br class=""></div></div></blockquote><div><br class=""></div>I think what we have now is reasonably good, actually. It takes some getting</div><div>used to, but I bet you’ve had more years getting used to IPv4 than most of us</div><div>have with IPv6.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">All of this is mostly absurd as DNS names are human readable regardless of whether they point to A, AAAA, or both records.<br class=""></blockquote><br class="">As I said it often comes up precisely because, for some reason, DNS<br class="">isn't available or not working correctly.<br class=""></div></div></blockquote><div><br class=""></div>Well… I don’t run into this very often any more, but I guess if you have a poorly run DNS environment, it might be more of an</div><div>issue.</div><div><br class=""></div><div>Owen</div><div><br class=""></div><br class=""></body></html>