A few thoughts: 1. What global organization has the ability to impose a tax on any nation’s citizens? 2. Do you not see an issue with making everyone worldwide get rid of every device that supports v4? Kind of a burden for a developing country, no? Also, a bit of an e-waste problem I would think. 3. Do you think that any organization with the power to tax some Internet usage (like v6) will stop there and not figure a way of continuing the cash flow forever? 4. The FCC and other standardization organizations often have statutory authority to manage things like spectrum management and consumer safety. What would be their authority to mandate v6 usage? 5. Why not just get carriers to make v4 service an optional extra just like static address requests? There is no reason to empower government more than they already are. Simple economic pressure would work. 6. Why is your issue more important than any other so-called global issue like carbon taxes, endangered species, human trafficking, etc? Do you want to go to a world government to encourage adoption of IPv6? Why should anyone care about that other than us engineers working under the hood 7. If someone like say Botswana says we are not paying your tax, do you intend to send in UN Peacekeeping Forces to collect the money owed? Are we going to war with North Korean if they won’t let us check their routers for the presence of v4 addresses? 8. What is the economic or social reasoning behind obsoleting ipV6? Is this really an existential global issue or are you just inconvenienced by dealing with both address families? While we think it a big deal here on NANOG, do you really think that the public sees that issue somewhere in their top 20 priorities? I doubt it. 9. Some world government enforcing global network standard migrations? What could possibly go wrong there ☺. Do permanent UN Security Council members retain the right to veto these standards? 10. I think at one time the US Government demanded POSIX compliance for all of their systems. That did not even work on the scale of the US Government managing their own systems. Why would this work any better? Governments are notoriously bad at managing their own IT systems, I don’t think we want them managing all of ours as well. Steven Naslund Chicago IL From: NANOG <nanog-bounces@nanog.org> On Behalf Of Antonios Chariton Sent: Wednesday, October 2, 2019 11:38 AM To: NANOG <nanog@nanog.org> Subject: Re: IPv6 Thought Experiment To clarify that further, this would be a monthly tax. So $2 / month. On 2 Oct 2019, at 19:33, Antonios Chariton <daknob.mac@gmail.com<mailto:daknob.mac@gmail.com>> wrote: Dear list, First of all, let me apologize if this post is not allowed by the list. To my best interpretation of the guidelines [1] it is allowed, but may be in a gray area due to rule #7. I would like to propose the following thought experiment about IPv6, and I would like your opinion on what you believe would happen in such a case. Feel free to reply on or off list. What if, globally, and starting at January 1st, 2020, someone (imagine a government or similar, but with global reach) imposed an IPv4 tax. For every IPv4 address on the Global Internet Routing Table, you had to pay a tax. Let’s assume that this can be imposed, must be paid, and cannot be avoided using some loophole. Let’s say that this tax would be $2, and it would double, every 3 or 6 months. What do you think would happen? Would it be the only way to reach 100% IPv6 deployment, or even that wouldn’t be sufficient? And for bonus points, consider the following: what if all certification bodies of equipment, for certifications like FCC’s or CE in Europe, for applications after Jan 1st 2023 would include a “MUST NOT support IPv4”.. What I am trying to understand is whether deploying IPv6 is a pure financial problem. If it is, in this scenario, it would very very soon become much more pricey to not deploy it. I know there are a lot of gaps in this, for example who imposes this, what is the "Global Internet Routing Table", etc. but let’s try to see around them, to the core idea behind them. Thanks, Antonis ------- Links ------- 1: https://nanog.org/resources/usage-guidelines/<https://urldefense.proofpoint.com/v2/url?u=https-3A__nanog.org_resources_usage-2Dguidelines_&d=DwMFaQ&c=ZyuC0pi8BQ0JtN0UhY3DPMRPQOzp-0mvXzAggKz74wI&r=ZOBJlMbaeeVccIxR59VB6LkI6RgrNZbvYF8H4DSvu2w&m=4rR7Ud6Vljd1pXdLAh2nQP63Hs8tI2xouHDLGEJ6sZQ&s=sM3SUK1qHxNP7ddTtji3wFHI-AL8Rrh4T4EZpNaMbEI&e=>

And for bonus points, consider the following: what if all certification bodies of equipment, for certifications like FCC’s or CE in Europe, for applications after Jan 1st 2023 would include a “MUST NOT support IPv4”..

I think a good start would be: "MUST support IPv6"!

It's certainly financial but it's not just companies being cheap. For example for smaller companies with a limited staff and small margins. They may want to have v6 everywhere but lack the resources to do it. It would for certain speed up the process but there would be collateral damage in the process. Here is the question being dealt with in the corporate environment. Why should I prioritize moving everything to IPv6 now instead of my other zillion IT projects that actually are visible to my customers and business users? It is simply, almost always, a cost benefit question. I would have to convince the company that it is in their financial best interest to go that route. I think over time the migration happens organically as more people are familiar with v6 and all the equipment and setup schemes start using v6 as the default. I would be hard pressed to come up with a reason for a hard deadline. Making life easier for NANOG engineers is not high on most corporate priority lists ☺ Steven Naslund Chicago IL

On Wed, Oct 2, 2019 at 3:46 PM John Levine <johnl@iecc.com> wrote:

In article <CAHdm834jbwky2sPpH6HmJoYu= Rcjz0Hb1bCq2zy1hsdYOSN9sQ@mail.gmail.com> you write:

...

For a small organization with limited staff and small margins, I'm curious where the actual burden in supporting IPv6 lies. In my experience, it's not any more costly than deploying IPv4 is ...

Right, but that means it doubles your deployment costs since IPv4 isn't going away any time soon. First you have to get IPv6 into your

I'd strongly disagree that it anywhere near doubles costs. Ultimately you're buying hardware X and it's going to cost whatever it costs. So what more do you really need to do to support IPv6? Well, let's say you're using OSPF. This means you'll also need to use OSPFv3, but that's not hard because your OSPFv3 configs are going to basically mirror your OSPF configs. You'll need to run IPv6 over iBGP, perhaps, and over eBGP to your peers and transits, but that's just another set of addresses bound to interfaces, sessions that mirror the IPv4 ones, and policy rules/filters. If you're doing super heavy TE, then the filter configs might take some effort, but if we're talking about smaller shops, doing heavy TE is unlikely. At that point, you just add a v6 address to your layer3 interfaces and you're good to go for the network side. Most of the time you spend configuring things won't be v4 or v6 specific, and the v4 specific configurations can be copy/pasted with a quick string swap to support v6 in a lot of cases. network, directly or through a tunnel (thanks, HE.) Then you have to

assign IPv6 addresses to every device that has a name, put that in your DNS and configure the devices, either by whatever means the device has (typically a web control panel) or maybe by a DHCP entry,

But once you have the basics down - your layer3 gateways, routing protocols, etc - this process of getting the hosts on board can take as long as you'd like. The only deadlines are ones you impose. if the device can be persuaded to use DHCP rather than SLAAC. In

many cases, notably web servers, you need yet more configuration to connect each v6 address with whatever service the v6 adddress is supposed to provide.

I've done this plenty of times and never found it to be particularly difficult or time-consuming. If you have a lot of systems, hopefully you have some sort of automation or configuration management which will allow you to test and deploy to production in at least a less-manual fashion. If you don't have a lot of systems, then you can just iterate through them and take 10-15 minutes each to get a v6 address bound and firewall rules updated.

Then you have to set up firewall rules to match your v4 firewall rules.

Which usually means copy/pasting and a quick string swap.

Then you spin it all up, and you have to check that every device actually does respond on its IPv6 address, and that it acts reasonably to mixed v4 and v6 requests (so-called happy eyeballs.)

Or just throw it in the monitoring system you already have, but again, this can all be part of a process that happens over as long a course of time as you need it to.

None of this is impossible, I've done it all, but I've also often asked myself what exactly is the benefit of doing all this. On my home network the v4 stuff is behind a NAT so v6 allows me access to devices from the outside (carefully managed with the firewall) but on my hosted servers which have v4 addresses for everything, meh.

I think ultimately the perception of the work required to deploy IPv6 is a much greater hurdle to IPv6 adoption than the actual work required to deploy IPv6.

In my experience, the biggest hurdle to installing a pure IPv6 has nothing to do with network gear or network engineers. That stuff I expect to support v6. This biggest hurdle is the dumb stuff like machinery interfaces, surveillance devices, the must have IP interface on such and such of an obsolete appliance, etc. The dumb legacy app that supports the ancient obsolete pen plotter that we must keep forever, etc. The next largest hurdle is trying to explain to your server guys that you are going to go with all dynamically assigned addressing now and explaining to your system admin that can’t get a net mask in v4 figured out, how to configure their systems for IPv6. There are a lot of people in the IT industry who are not nearly ready for v6. In large enterprise networks, there is lots of East/West communications between systems and that is very difficult to transition through a dual stack process without tripping over a bug or serious incident. It is really hard to look at cost difference in v6/v4 but there will be a definite learning curve with the associate oops moments and re-education that all costs time/money/downtime. The simply reality is that there are more IT people that understand v4 and do not understand v6 yet. Steven Naslund Chicago IL

I'd strongly disagree that it anywhere near doubles costs. Ultimately you're buying hardware X and it's going to cost whatever it costs. So what more do you really need to do to support IPv6? >Well, let's say you're using OSPF. This means you'll also need to use OSPFv3, but that's not hard because your OSPFv3 configs are going to basically mirror your OSPF configs. You'll need to >run IPv6 over iBGP, perhaps, and over eBGP to your peers and transits, but that's just another set of addresses bound to interfaces, sessions that mirror the IPv4 ones, and policy rules/filters. If >you're doing super heavy TE, then the filter configs might take some effort, but if we're talking about smaller shops, doing heavy TE is unlikely. At that point, you just add a v6 address to your >layer3 interfaces and you're good to go for the network side.

Most of the time you spend configuring things won't be v4 or v6 specific, and the v4 specific configurations can be copy/pasted with a quick string swap to support v6 in a lot of cases.

On 10/2/19 3:03 PM, Naslund, Steve wrote:

The next largest hurdle is trying to explain to your server guys that you are going to go with all dynamically assigned addressing now

Completely false, but a very common misconception. There is nothing about IPv6 that prevents you from assigning static addresses.

and explaining to your system admin that can’t get a net mask in v4 figured out, how to configure their systems for IPv6.

If they only need an outbound connection, they probably don't need any configuration. The instructions for assigning a static address for inbound connections vary by OS, but I've seen a lot of them, and none of them are more than 10 lines long. Regarding the previous comments about all the drama of adding DNS records, etc.; that is what IPAM systems are for. If you're small enough that you don't need an IPAM for IPv4, you almost certainly don't for IPv6. IPv6 is different, but it's not any more difficult to learn than IPv4. (You weren't born understanding IPv4 either.) Doug

A long time ago, in another country, JANET had a mail list to discuss email, in a world before DNS. And, when DNS emerged, JANET mail list made a *deliberate* decision to make the domain order of UK email domains the reverse of every other country worldwide. A DELIBERATE decision. (I was there, on this list. Others may disagree with my interpretation of acts done and motivations, but I want to be clear I didn't "hear this second hand" -I was receiving the mailflows discussing this in public. I am sure there are other private conversations I didnt see) It wasn't a consensus decision. It wasn't an entirely rational decision. OTOH it was a research network, email was a research activity, and in some ways, it made sense to find out what happened. That the decision had repercussions which echoed down the years, and marginalized some communications Uk and internationally, is perhaps, the real lesson. IPv6 had an opportunity to consider designs which were intermediate, (IPv4-and-a-bit) and backwards compatible. And, like JANET and domain order, people decided not to do it, believing it was interesting and research-y. I too wish we had selected TUBA, or had thought more about interop with IPv4. I sometimes wish I understood why SRC was the first element off the wire, and not DST, Since rational ASIC/FPGA hardware can latch early on the SRC and begin routing faster if it appears in natural bit order first. Or, why we even have SRC in the header: it does not inform routing. These are heresies. Counterfactuals dog Historians. Some love them, some hate them. We don't have time machines. This is the world we live in, we have to make the best of it we can. IPv6 globally is rising, IPv6 in Asia is rising. IPv6 in India is basically ubiquitous, IPv6 in America is ubiquitous. We are going to live in a mixed protocol global internet for the forseeable future. We can plan to extend V4, or end V4, or deprecate V4, or end v6, and favour CGN but we can't end either V4 or V6 entirely, easily, soon. -G

On Thu, Oct 3, 2019 at 11:39 AM Doug Barton <dougb@dougbarton.us> wrote:

Yes, IPv6 suffers from Second System Syndrome. No this is not news, neither is it malleable (no matter how much whinging about roads not taken occurs).

Which is why I said:

On 10/2/19 6:30 PM, George Michaelson wrote:

...

This is the world we live in, we have to make the best of it we can.

G

On Thu, Oct 3, 2019 at 12:12 PM Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:

George Michaelson wrote:

...

Or, why we even have SRC in the header: it does not inform routing.

Primarily for ICMP.

Could look inside beyond first header state to see DST as payload. optimisation for ICMP feels like premature optimisation. But, its semi-rational. Frag which dropped this, was going to make IP difficult for any real use anyway, not bothered by the corner-case breaks. Coulda Woulda Shoulda -G

A fair comment would be "you massively mis-remember" and in both JANET-Email and IPv6 terms, I would not disagree. We're talking about things done, decisions made 35 or more years ago, to 25 years ago and my brain has had many fine beers since then. But the intent remains the same: we made choices, we have to live with them. The choices are maybe looking unwise but we cannot easily unwind them to any intent. Personally, I choose to favour continued deployment of IPv6. I believe in TCO and other terms, its a rational choice. I do not favour the CGN v4 forever model, but its going to go on for a long, long time. I ceased worrying which protocol I am using some years ago. Its not important to me, either seem to work. _G

hi, the old UK reverse name notation actually comes from some sensible ideas - firstly from the big-endian processing methods - but also the most important part of the address comes first - ideal for global routing decisions early. who cares about the actual hostname , get to the actual TLD ;-) anyway, a little unfair as that decision was made before the Internet domain standard was agreed/established. hey, competing systems...one of them usually wins. in this case the other one did ;-) as for IPv6, the topic of this thread. having done campus IPv6 deployments, working out addressing schemes, sorting out kit upgrades (and broken by many 'oh, IPv6 is in a future release' or 'its on our roadmap' vendor promises) a few things. it gives us native end to end on a network that is now too big to handle that with IPv4 - NAT etc causing all kinds of new things to be cooked up to ensure things dont break. deploying it is trivial-ish (these days) - you have so much choice...and eventually decent routers doing SLAAC will finally be able to serve other details such as DNS/time/etc via SLAAC - servers? give them static addresses...simple ones that dont populate all the last half... that gets me on to my small annoyance... /64 bit subnet masks for local networks. really? ALL of that address space and then throw such a large range away on subnets commonly populated with no more than a couple of hundred clients...maybe a few thousand at worst. what a mistake. I come from a background where we had IPv4/DECNET/AppleTalk/IPX all around the place - to be honest, 2 fairly simply IP protocols being handled/routed has never kept me up at night and I enjoyed many times of cleaning things up and getting people to realise what access their systems needed...a quick refresh of access rules (on hosts and in network kit) and monitoring ('you monitor that service on its IPV4...why not IPv6' was said way too many times) address format? at least you can put :c01d:c0ff:ee and dead:beef etc in your addresses... as others have said, IPv4 is only a number in a superficial sense (who HASNT been burnt by an engineer putting a few 0's into IP address boxes on kit that forces all fields to be populated? we had A6 and AAAA mess, things took a while to iron out and just like BSD dying, IPv6 deployment (and DNSSEC!) just really hasnt been 'completed' yet. but thats okay, because I'm still curious why the US techies didnt just bite the bullet and got for IPv8 ;-) alan

In article <CAOVYXj-DWX0FhcEJdPMBfec6HcykWtRrErC8wDuBDYYFmE_cWQ@mail.gmail.com> you write:

that gets me on to my small annoyance... /64 bit subnet masks for local networks. really?

Yup.

ALL of that address space and then throw such a large range away on subnets commonly populated with no more than a couple of hundred clients...maybe a few thousand at worst. what a mistake.

Nope. The whole point of 128 bit addresses is that you can waste bits with wild abandon. My upstream originally assigned me a /64 but since I have two network segments, they gave me a /48, of which I am using two /64s. Since they have a /32, they won't run short of /48's until they have 65,000 clients with multi segment networks, which will take a very long time. In the unlikely event that happens, they can upgrade their /32 to a /31, since ARIN allocates the /32's with slop between them. The programming and configuration is much easier since we can always assume that every network will have a /64 and no more and no less.

I come from a background where we had IPv4/DECNET/AppleTalk/IPX all around the place -

Unlike all of them, one mistake that IPv6 did *not* make was to make addresses too short. In the same way, IPv6 ULAs are a lot better than IPv4 RFC1918 space. So long as you follow the spec and pick a truly random ULA prefix, even if your networks later merge with others the chances of ULAs colliding rounds to zero.

Another misconception. Humans (by and large) count in decimal, base 10. IPv4 is not that. It only LOOKS like that. In fact, the similarity to familiar decimal numbers is one of the reasons that people who are new to networking stumble early on, find CIDR challenging, etc. I do understand that the hex thing presents a (small) learning curve. But work with it for a little while and it will become familiar, just like IPv4 did. In fact, once you get past a few basic concepts, the network'y bits should be familiar to you (pun intended). CIDR works the same way, the only real differences there are that a /64 is your basic network unit, and is roughly equivalent to an IPv4 /22 in the sense that ~1,000 hosts per network/VLAN is pretty much your limit. The other thing to keep in mind is that due to the massive size of the address space, it's rarely useful to allocate on anything other than a nibble boundary (that is, divisible by 4). There are two reasons, sparse allocation, and the fact that reverse DNS is much easier if you keep things in that framework. Now I do admit that the whole RA/SLAAC vs. DHCPv6 thing is more complicated than it should be. Some of us fought very hard for the concept that SLAAC should be optional, and restricted to network and gateway; but we lost to the "SLAAC must be the new DHCP!" crowd. Sucks that you have to do both, but since you're already doing DHCP for end-user hosts anyway, and you're already configuring the router for the IPv6 network info, the marginal cost isn't really that high. Take a look at https://dougbarton.us/IPv4_and_IPv6_Network_Structure_Planning-20190519.xls if you're interested in learning more. I have some cheat sheets that will help you understand assignment strategy, sparse allocation, nibble boundaries, etc. It also has handy calculators that allow you to plan for IPv4 and IPv6 networking based on the number of different types/sizes of offices, data centers, etc. in each region. Enjoy, Doug On 10/2/19 5:54 PM, Matt Hoppes wrote:

I disagree on that. Ipv4 is very human readable. It is numbers.

Ipv6 is not human numbers. It’s hex, which is not how we normally county.

It is all water under the bridge now, but I really feel like ipv6 could have been made more human friendly and ipv4 interoperable.

...

On Oct 2, 2019, at 8:49 PM, Doug Barton <dougb@dougbarton.us> wrote:

...

On 10/2/19 3:03 PM, Naslund, Steve wrote: The next largest hurdle is trying to explain to your server guys that you are going to go with all dynamically assigned addressing now

Completely false, but a very common misconception. There is nothing about IPv6 that prevents you from assigning static addresses.

...

and explaining to your system admin that can’t get a net mask in v4 figured out, how to configure their systems for IPv6.

If they only need an outbound connection, they probably don't need any configuration. The instructions for assigning a static address for inbound connections vary by OS, but I've seen a lot of them, and none of them are more than 10 lines long.

Regarding the previous comments about all the drama of adding DNS records, etc.; that is what IPAM systems are for. If you're small enough that you don't need an IPAM for IPv4, you almost certainly don't for IPv6.

IPv6 is different, but it's not any more difficult to learn than IPv4. (You weren't born understanding IPv4 either.)

Doug

On Thu, Oct 03, 2019 at 03:20:50PM +0000, Naslund, Steve wrote:

Can you imagine keeping those v6 addresses in your head the same way?

I don't have to imagine, I do it on a daily basis. Doesn't seem to cause me any grief. In my experience, IPv4 addresses which need to be used directly on a regular basis tend to follow certain patterns or rules of thumb ("default gateway is on the (first|last) address in the range", for instance), and the same thing tends to happen with similarly situated IPv6 addresses. - Matt

Another misconception. Humans (by and large) count in decimal, base 10. IPv4 is not that. It only LOOKS like that. In fact, the similarity to familiar decimal numbers is one of the reasons that people who are new to networking stumble early on, find CIDR challenging, etc.

Go ahead and read your v4 address over the phone and then do the same with your v6 address. Which is easier? I do understand all about these addresses both being binary underneath ( I've been doing this for over 30 years now). However it is much easier to communicate using four decimal octets.

I do understand that the hex thing presents a (small) learning curve. But work with it for a little while and it will become familiar, just like IPv4 did.

The question here is how do I convince an enterprise of the need to feel the pain of learning it and do I want to be the guy going under the bus the first time someone screws up and takes some business critical system down. People generally do not like change and being forced to learn something new. That is just human nature. You have to give them a reason to want to do it (more money, better service, less long term cost, etc.). It is hard to make the case to eliminate v4 in use cases where it is working perfectly fine (especially RFC1918 inside an enterprise). Steven Naslund Chicago IL

Thank God for DNS ;) -aaron -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Alan Buxey Sent: Thursday, October 3, 2019 2:22 PM To: Naslund, Steve Cc: nanog@nanog.org Subject: Re: IPv6 Pain Experiment hi,

Go ahead and read your v4 address over the phone and then do the same with your v6 address. Which is easier? I do understand all about these addresses both being binary underneath ( I've been doing this for over 30 years now). However it is much easier to communicate using four decimal octets.

::1 so much quicker than 127.0.0.1 ;-)

People generally do not like change and being forced to learn something new.

some people dont... but its called progress. I'd have to worry about someone whose only experience is of TCP/IP networking (and only IPv4 at that). do they also get wobbly when their data is now on a big broadcast collision domain network after all those years of moving it to a switched system?

That is just human nature. You have to give them a reason to want to do it (more money, better service, less long term cost, etc.).

the ability to communicate to the rest of the growing world where IPv4 addresses just arent there anymore?

It is hard to make the case to eliminate v4 in use cases where it is working perfectly fine (especially RFC1918 inside an enterprise).

2 things on this. just an internal network? yes, you could say 'why bother'? I *could* think about being in that camp....but actually, i'd stick the security hat on and say, just like I did with wireless 'we dont have any wireless' - oh really? without being in the domain and having kit that will detect it/trace its source etc how will you know int he IPv6 world...if you arent the one controlling it on your network (and reporting on it) then you will have clients happily talking to each other on it, tunnelling it around the place (hello all those TEREDO tunnels) and being the router for traffic. all the fun with ff02::1 on your local segment ;-) alan

On Oct 2, 2019, at 17:54 , Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:

I disagree on that. Ipv4 is very human readable. It is numbers.

Ipv6 is not human numbers. It’s hex, which is not how we normally county.

It is all water under the bridge now, but I really feel like ipv6 could have been made more human friendly and ipv4 interoperable.

...

On Oct 2, 2019, at 8:49 PM, Doug Barton <dougb@dougbarton.us> wrote:

...

On 10/2/19 3:03 PM, Naslund, Steve wrote: The next largest hurdle is trying to explain to your server guys that you are going to go with all dynamically assigned addressing now

Completely false, but a very common misconception. There is nothing about IPv6 that prevents you from assigning static addresses.

...

and explaining to your system admin that can’t get a net mask in v4 figured out, how to configure their systems for IPv6.

If they only need an outbound connection, they probably don't need any configuration. The instructions for assigning a static address for inbound connections vary by OS, but I've seen a lot of them, and none of them are more than 10 lines long.

Regarding the previous comments about all the drama of adding DNS records, etc.; that is what IPAM systems are for. If you're small enough that you don't need an IPAM for IPv4, you almost certainly don't for IPv6.

IPv6 is different, but it's not any more difficult to learn than IPv4. (You weren't born understanding IPv4 either.)

Doug

OK… Let’s talk about how? 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? How would you have made a 128-bit address more human-readable? Does it really matter? 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? All of this is mostly absurd as DNS names are human readable regardless of whether they point to A, AAAA, or both records. Owen

On Fri, Oct 04, 2019 at 11:48:33PM +0000, Michel Py wrote:

...

Owen DeLong wrote : 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?

With some kind of NAT mechanism, naturally.

That word "naturally" is doing an *awful* lot of work there.

...

How would you have made a 128-bit address more human-readable? Does it really matter?

I have found it difficult to talk hex with people from other countries.

Try to say FACEB00C to someone who does not speak your langage. Foxtrox Alpha Charlie Echo Bravo Zero Zero Charlie does not go through either. 250.206.176.192 works all the time. Everyone gets the numbers.

That word "Everyone" is doing an *awful* lot of work there. All this hand-waving is creating quite a breeze. Think I'll put on a sweater. - Matt

On Oct 4, 2019, at 20:23 , Owen DeLong <owen@delong.com> wrote:

...

On Oct 4, 2019, at 16:48 , Michel Py <michel.py@tsisemi.com> wrote:

...

Owen DeLong wrote : 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?

With some kind of NAT mechanism, naturally. Which is not possible with the current IPv6 address format, if you want something stateless and that does not rely on DNS.

Well, what address format would you propose that would make it better? Let’s talk actual workable detailed proposals rather than just hand-waving.

We already have a number of such solutions: NAT64 464XLAT B4/AFTR etc.

...

...

How would you have made a 128-bit address more human-readable? Does it really matter?

I have found it difficult to talk hex with people from other countries.

Sorry, hit send too soon. Won’t rehash previously posted content, but here’s what got missed… In addition, hex makes it MUCH easier to do subnetting. Each digit aligns with a nibble boundary, so instead of having to memorize/calculate 8 different powers of two ranging from 1-128, you only need to memorize 4 ranging from 0-8. Further, given the bountiful amount of IPv6 space available, you shouldn’t really need to subnet off nibble boundaries unless you really want to. How many people do you know (as a percentage) that divide RFC-1918 space into non-octet-aligned subnets? Remember the handy subnet calculators for IPv4 that broke down all the net mask possibilities: / 9, /17, /25 — .0/.128 (0-127 and 128-255) /10, /18, /26 — .0/.64/.128/.192 (0-63, 64-127, 128-191, 192-255) … /15, /23, /31 — .0/.2/.4/.6/.8/.10/.12/.14/.16/… Yeah, compare that to: /n % 4 = 0 — Aligns with nibble boundary. 1 — 0/8 (0-7, 8-f) 2 — 0/4/8/c (0-3, 4-7, 8-b, c-f) 3 — 0/2/4/6/8/a/c/e (0-1, 2-3, 4-5, 6-7, 8-9, a-b, c-d, e-f) Subnetting is MUCH MUCH MUCH simpler in IPv6, especially if you follow the intended architecture/recommendations. Owen

On Fri, Oct 4, 2019 at 4:48 PM Michel Py <michel.py@tsisemi.com> wrote:

...

Owen DeLong wrote : 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?

With some kind of NAT mechanism, naturally.

I want to divert from the current flame war to make my biennial semi-serious reminder that it was at least theoretically possible to expand the IPv4 address space rather than make a whole new protocol. That we did not do so was a failure of imagination. http://bill.herrin.us/network/ipxl.html

...

How would you have made a 128-bit address more human-readable? Does it really matter?

Everyone gets the numbers.

Everyone thinks they get numbers. Until they try to compute a netmask or perform any other non-rote IP networking task. The people who get hex tend to actually get numbers. Both ways. If you want to know for sure whether the other person understood you, explain it in hex. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On Mon, Oct 7, 2019 at 11:34 AM Michel Py <michel.py@tsisemi.com> wrote:

...

William Herrin wrote : I want to divert from the current flame war to make my biennial semi-serious reminder that it was at least theoretically possible to expand the IPv4 address space rather than make a whole new protocol. That we did not do so was a failure of imagination. http://bill.herrin.us/network/ipxl.html

That could have worked. Eventually, some form of IPv4 with "just" more bits could surface, but it will take a decade or more. When did you write this ? I read it before, just can't remember how long ago.

2007. Half of IPv6's lifetime ago. It came out of an ARIN PPML thread titled "The myth of IPv6-IPv4 interoperation." On one side of the argument, folks saying that the need to manage two configurations impairs IPv6's deployment. On the other, an individual whose thesis was the IPv6 could not have been designed to be backwards compatible with IPv4 in a way that required no new configuration, just incremental, backward-compatible software upgrades. -Bill -- William Herrin bill@herrin.us https://bill.herrin.us/

...

...

Michel Py wrote : When did you write this ? I read it before, just can't remember how long ago.

...

William Herrin wrote : 2007. Half of IPv6's lifetime ago. It came out of an ARIN PPML thread

...

On one side of the argument, folks saying that the need to manage two configurations impairs IPv6's deployment. On the other, an individual whose thesis was the IPv6 could not have been designed to be backwards compatible with IPv4 in a way that required no new configuration, just incremental, backward-compatible software upgrades.

Why did you choose this route, instead of encapsulating the packet with

On Mon, Oct 7, 2019 at 3:32 PM Michel Py <michel.py@tsisemi.com> wrote: titled "The myth of IPv6-IPv4 interoperation." the extended address into an IPv4 packet ? I was out to prove a point. I needed a technique that, at least in theory, would start working as a result of software upgrades alone, needing no configuration changes or other operator intervention. If I couldn't do that, my debate opponent was right -- a greenfield approach to IPv6 made more sense despite the deployment challenge. Map-encap, where you select a decapsulator (consult the map) and then send a tunneled packet (encapsulated) does some cool stuff, but it's a pretty significant change to the network architecture. Definitely not configuration-free. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On Mon, Oct 7, 2019 at 5:31 PM Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote:

William Herrin wrote:

...

I was out to prove a point. I needed a technique that, at least in theory, would start working as a result of software upgrades alone, needing no configuration changes or other operator intervention.

I think TCPng/UDPng with 32/48 bit port numbers combined with NAT/A+P, which is obviously fully operational with existing IPv4 backbone, is better.

Not a fan of port numbers. If we're going to replace TCP and UDP, initiate the link with a name (e.g. dns name), negotiate a connection ID and continue with the connection ID. No ports, no port scanning. QUIC comes pretty close to getting it right. -Bill -- William Herrin bill@herrin.us https://bill.herrin.us/

On Oct 7, 2019, at 23:59 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:

William Herrin wrote:

...

...

I think TCPng/UDPng with 32/48 bit port numbers combined with NAT/A+P, which is obviously fully operational with existing IPv4 backbone, is better.

...

Not a fan of port numbers.

Separation between address and port is vague.

Explain that to ICMP packets.

...

If we're going to replace TCP and UDP, initiate the link with a name (e.g. dns name),

The point of TCP use IP address for identification is hosts can confirm IP address is true by 3 way handshaking.

And UDP? Owen

On Oct 8, 2019, at 02:29 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:

Owen DeLong wrote:

...

...

Separation between address and port is vague. Explain that to ICMP packets.

Why do you think ICMP any different?

Just as usual IP packets, inner IP packets contained in ICMPv4 error packets contain port numbers just after IP headers.

Show me the port number in a type 8 or type 0 packet.

Moreover, unlike stupid ICMPv6, ICMPv4 error packets are guaranteed to contain 8B of inner packet payload (enough for 32 bit port number) after IP header.

You’re selecting a very limited subset of ICMP that happens to contain a portion of a packet that happens to contain a port number (or two).

...

...

...

If we're going to replace TCP and UDP, initiate the link with a name (e.g. dns name),

The point of TCP use IP address for identification is hosts can confirm IP address is true by 3 way handshaking. And UDP?

Applications over UDP may or may not confirm by 3 way handshaking or some other mechanism.

That's UDP.

Yes, but the context in which you proposed this as a be-all end-all solution doesn’t allow for the existing things that brea when you make the assumptions you’ve obviously made.

That's very elementary explanations on ICMP and UDP.

Yes, thanks for yet another condescending comment proving that you completely missed the point of my post. It’s always a pleasure. Owen

On Wed, 09 Oct 2019 18:51:12 +0900, Masataka Ohta said:

Owen DeLong wrote:

...

Yes, thanks for yet another condescending comment proving that you completely missed the point of my post. It's always a pleasure.

You should really feel indebted to me because it's not a pleasure for me to answer questions having no valid points.

Of course, if you missed the point, by definition you won't find any valid points. And yes, you *did* totally miss Owen's point, which was that not all ICMP packets contain port information. As another data point, enough IP options will push some or all of TCP or UDP header information out of the returned data.

Owen DeLong wrote:

...

It is merely that you don't understand ICMP at all.

Really, it's not, but I know you like to feel smug and superior, so enjoy that.

Are you saying you are so great that only the greatest can be superior to you, which must be enjoyable? Then, you are wrong.

...

You should really feel indebted to me because it's not a pleasure for me to answer questions having no valid points.

Rest assured that I will not feel slighted in any way if you were to stop doing so. Please feel free to stop at any time.

If only you have humbly asked properly targeted question as:

Explain that to ICMP ECHO packets.

you could have been answered properly. Instead, you intentionally vaguely asked:

Explain that to ICMP packets.

trying to trick me with your poor understanding on ICMP and UDP. As a result, you are properly rewarded to make a fool of yourself in public. Masataka Ohta

Owen DeLong wrote:

...

As a result, you are properly rewarded to make a fool of yourself in public.

If I have, it certainly won’t be the first time.

Enjoy it, if you can. PERIOD. Masataka Ohta

William Herrin wrote:

...

The point of TCP use IP address for identification is hosts can confirm IP address is true by 3 way handshaking.

Yeah, but that touches one of the central flaws of the design of IP, v4 and v6.

We are talking about design of TCP, not IP.

No part of identifying and authenticating communication should reside at layer 3.

That's why we have port numbers for TCP, though you may call something equivalent to them SPIs for IPsec.

The IP address shouldn't identify anything. It should reflect only the host's current position in the network.

You are saying IP address should identify current position in the network.

The address should be as ephemerally attached to the endpoint as the layer 2 MAC address and as quickly changeable. Without disrupting upper layer communication. It would be a crying shame to replace the layer 4 protocols without doing something about that flaw.

Just say "IP mobility". And it's layer 3 issue.

I actually came up with a solution to BGP scalability. If you abandon stability of the layer 3 address, just throw it out the window, it turns out to be relatively easy to build a routing protocol which constructs ephemeral address hierarchies that represent the current state of connections in the network even though the physical network itself is still a general graph. The ephemeral hierarchies aggregate well reducing the worldwide routing table to a few tens of thousands of routes.

Then, you need two sets of IP addresses, one for physical network another for virtual network. Former needs large routing table. With IP mobility, the latter needs no routing table or BGP.

...

Only to replace well known port numbers by well known connection IDs and port scanning by connection ID scanning?

Easy to make this impractical. QUIC has.

It can be made so by sparsely populated port number space. So, when all what needed are more bits for address and port, don't try to put all the complicated features someone might have thought useful. Masataka Ohta

Folks should be aware that if you do not assume extreme pressure (which is what it is taking to get IPv6 deployed), it turns out to be quite hard to get the deployment incentives and structures for a map-and-encaps scheme to actually work for Internet-wide deployment. It does work for a range of special cases. Yours, Joel On 10/7/2019 10:58 PM, Michel Py wrote:

...

William Herrin wrote : I was out to prove a point. I needed a technique that, at least in theory, would start working as a result of software upgrades alone, needing no configuration changes or other operator intervention. If I couldn't do that, my debate opponent was right -- a greenfield approach to IPv6 made more sense despite the deployment challenge.

I think that, 12 years ago, you had the best mouse trap.

...

Map-encap, where you select a decapsulator (consult the map) and then send a tunneled packet (encapsulated) does some cool stuff, but it's a pretty significant change to the network architecture. Definitely not configuration-free.

I am so painfully aware of this.

Michel.

TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...

On Oct 7, 2019, at 20:16 , bzs@theworld.com wrote:

Well if you all really want your heads to explode I was invited to give a talk a few years ago in Singapore at the local HackerSpace.

It called for something creative and different, not really an IETF sort of crowd.

So I proposed we dump numeric addresses entirely and use basically URLs in IP packets and elsewhere.

I really meant something like 'IP://www.TheWorld.com' in the source/dest addr, possibly more specific for multiple interfaces but whatevs.

It doesn’t break my brain, but it really doesn’t make a lot of sense when you get down to it. You’re basically producing a numeric address that is limited in character scope is all. An octet can represent 8 bits of a binary address, period. It’s up to you whether you display that to the human as ASCII characters (limited printable selection), Unicode (even more overhead and wastage), numeric (current practice and zero waste in hex form), or otherwise.

Leave out the implied 'IP://' and my example is 16 chars just like IPv6.

Yeah, but it doesn’t tell the whole story because the domain name needs to map (in some cases) to multiple on-the-wire addresses so you’re either going to have mass confusion in that you’e got service names and service addresses that look like names underneath that aren’t actually names, or, you’re going to be back to having addresses that could look like names, but don’t for sanity’s sake and then you’re back to unreadable addresses.

Routers could of course do what they like with those internally such as maintain a hash table to speed look-ups. Not anyone outside of router software developers' problem.

There’s also the issue that prefixes of that address format don’t tend to aggregate well. I’m betting that not all of the WWW addresses go to the same ASN.

If one agreed on a standard hash algorithm further performance improvements could be realized (e.g., inter-router comm could add the hashes, who cares, implementation nit.)

So the question is how long would these be on average and even if it was a little longer would anyone care? Is a nanosecond saved really a nanosecond earned?

In some applications, yes. In others, not so much.

We're already kind of committed to IP addresses not really meaning anything (that is, no routing info implied), they are mostly only a way to pick the next interface to push the packet out of and only need to be unique, sort of, with exceptions (umm, multicast.)

Well, yes and no. In the theoretical world, sure. However, as a practical matter, we depend a great deal on prefix aggregation and being able to carry only summary routes for large chunks of address space in distal routing tables.

BITS IS BITS. They're just bits either way. And in my proposal pretty easy to remember bits.

Until they aren’t because at some point, there needs to be a decoupling between the human-readable form you give and the actual network hierarchy necessary for managing a functional internet.

And Look Ma! No more DNS! Or a much reduced role.

You say that as if it’s a good thing. I remain rather thoroughly unconvinced.

I'd agree the idea is several RFCs short of an internet but hey it's something to think about.

I suppose if one is attempting to find a way to drum up business for the NSAID manufacturers, sure. Owen

On Tue, Oct 8, 2019 at 12:01 PM <bzs@theworld.com> wrote:

My main point is, as I said, Bits is Bits, whether they're human readable (for some value of "human") like URLs or long hex strings which perhaps are less human readable.

Bits aren't just bits. Bits with useful properties (such as aggregability which coincides with the routing structure) are better bits. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On Tue, Oct 8, 2019 at 12:38 PM <bzs@theworld.com> wrote:

On October 8, 2019 at 12:04 bill@herrin.us (William Herrin) wrote:

...

On Tue, Oct 8, 2019 at 12:01 PM <bzs@theworld.com> wrote: My main point is, as I said, Bits is Bits, whether they're human readable (for some value of "human") like URLs or long hex strings which perhaps are less human readable.

Bits aren't just bits. Bits with useful properties (such as aggregability which coincides with the routing structure) are better bits.

Yet somehow we manage to start with URLs (for example.)

URLs have lots of useful properties. None of them facilitate network routing but they facilitate lots of other useful stuff.

My point is whatever is used it can be mapped to something perhaps more efficient given some design goals, such as the DNS does. And for that matter route lookup tables w/in routers.

Mapped by who? The genius of the Internet's design lies in its answer to that question: the end to end principle. The end to end principle says that the endpoints (not middleboxes) should resolve those mappings so that the middleboxes need not manage abstractions. Packet switching is just fancy statistical multiplexing of a circuit-switched network... until you remove stateful management of the connections from the data path and keep it on the endpoints. Then it's more. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On Tue, 08 Oct 2019 19:12:30 -0000, Nicholas Warren said:

Sweet deals, would you kindly share your vendor?

Well, I just type "128G DIMM" into google, and the very first hit tells me that I can get a 128G DIMM for $1,398, that and 8 DiMM slots gets me to 1T just over $11K. If I have 16 DIMM slots like a decent server-class board should have, I can do 64G cards for $308 and I'm done for under $5k. I didn't dig further, because I already had evidence to support the claim:

It's not 1990 any more, a TB of RAM now costs a few thousand dollars and is dropping rapidly (similar for fancy router RAM)

processor chips with 64 cores available practically off the shelf for under $10K (32-core literally off the shelf, try any Microcenter),

AMD 32-core Ryzen Threadripper is $1,799. Find a 2-socket motherboard and you're at 64 cores for well under $5K for the chipsets. https://www.newegg.com/amd-ryzen-threadripper-2990wx/p/N82E16819113541

Nicholas Warren wrote:

It's not 1990 any more, a TB of RAM now costs a few thousand dollars

Maybe.

and is dropping rapidly (similar for fancy router RAM),

Definitely not. It's not 2010 any more. Masataka Ohta

On October 8, 2019 at 23:51 owen@delong.com (Owen DeLong) wrote: (responding to my P.S.)

P.S. My prediction?

The world's major telcos et al, having had enough of various problems, from address exhaustion to non-stop security disasters, and the chaotic responses, propose and begin implementing an alternative. And that won't be through the IETF or similar.

I tend to doubt it.

While I don’t discount what you say about telcos below, the thing to remember is that insisted that VOIP would never displace TDM in the average enterprise.

When was the last time you saw a business phone system using TDM and not IP phones?

Sorry, I was referring to telcos as the major so-called "tier 1" and long line providers, the cell phone service providers (along with the likes of comcast but there aren't many like that), and in many countries the monopoly providers of the whole, pardon the expression, cloud of comm services, rather than their voice function which has largely become just another app. The big capitalization and generally government embedded infrastructure players. The problem is two-fold. First they (the collective group I describe) honestly believe they can manage large-scale engineering projects w/o the help of a lot of volunteers beyond /fait accompli/ -- please stamp this new technology we collectively have agreed to as a "standard". Compare and contrast 5G for example. Second are the liability issues. They may generally manage to escape direct liability e.g. for business damage due to address exhaustion or security problems etc but insurance companies, banks, et al, can't and those are big players with sway over the "telcos" to do something about services they are paying collectively many billions per month for and incurring damages from. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

In article <23963.65395.763065.591307@gargle.gargle.HOWL> you write:

So I proposed we dump numeric addresses entirely and use basically URLs in IP packets and elsewhere.

I really meant something like 'IP://www.TheWorld.com' in the source/dest addr, possibly more specific for multiple interfaces but whatevs.

Leave out the implied 'IP://' and my example is 16 chars just like IPv6.

Routers could of course do what they like with those internally such as maintain a hash table to speed look-ups. Not anyone outside of router software developers' problem. ...

This is more or less equivalent to using device MAC addresses everywhere. I think that if you talk to people who build routers, you will find that they depend really heavily on the detail that every IP address has a network part and a host part, and they route using the network part. Ethernet switches send traffic to arbitrary MAC addresses, at the cost of remembering every MAC address they've seen, typically in a table with a few thousand entries. I know you've been on the net long enough to remember the good old days when there were only a few thousand URLs, but I fear it's unlikely we'll go back there. R's, John

On Oct 9, 2019, at 14:43 , bzs@theworld.com wrote:

OK OK OK.

Can I summarize the current round of objections to my admittedly off-beat proposal (use basically URLs rather than IP addresses in IP packet src/dest) as:

We can't do that! It would require changing something!

No… You can summarize it as “Doing things that way would break lots of useful things without yielding much in the way of practical benefit.”

I've no doubt many here are comfortable with the current architecture.

Well, sure, but I bet most of us would jump at the chance for something better if we actually saw such a thing. I’m all for trying out the wild and crazy ideas that might yield benefit. I just don’t think that what you have proposed so far actually qualifies on that last part.

Bits is bits.

Yes and no. At the lowest possible layer, a bit is a bit is a bit. However, when you add abstraction and assign meaning, such as ASCII characters, double-precision floating point, URLs, IPv6 (or if you must, IPv4) addresses, OSPF Areas, Autonomous System Numbers, etc., then groups of bits start to take on additional significance. It matters how we represent, process, interpret, store, and manage those bits. Different methodologies of each of those tasks are more or less appropriate for each given application. For example, a straight twos-compliment binary numeric interpretation of a 64-bit wide field with the MSb for sign and the remaining bits as significant digits is fantastic for integer arithmetic, but nearly useless for arbitrary precision manipulation of fractions. On the other hand, IEEE 754 floating point format of 32 bits where the MSb is for sign, the next 8 bits represent the exponent, and the remaining 23 bits represent the significant digits (“fraction” in IEEE terms) is very useful for arbitrary precision manipulation of fractions, but not at all good at integer math, especially for integer numbers that require low order precision, but have values greater than 2^23. Similarly, the current structure of IPv6 (and if you must, IPv4) addresses provides tremendous utility for moving packets about the internet. It’s not great at providing human-readable destination addresses. It’s also not great at providing geographic location information. Both of those are tasks for which those particular representations were never intended. There’s a reason that we have compact cars and B-trains (double trailer tractor-trailer rigs). A compact car is lousy at moving massive quantities of products. OTOH, a B-Train doesn’t fit in the average parking space very well and is hard to maneuver down most residential streets. (It also gets really lousy gas mileage for single-person transportation). We purpose build things in different ways to optimize them for different tasks throughout human history. Addresses are no different.

URLs are, to a machine, just bit strings though they do incorporate a hierarchical structure which isn't that dissimilar from current network/host parts of IP addresses.

Well, yes and no. For example, it’s not uncommon for a domain, say toyota.com, to be widely distributed across multiple networks of wildly different topologies. With the exceptions of anycast and multicast, it’s very unusual (I’d even venture to say unheard of) for a globally scoped address to be usefully deployed on multiple connected disparate networks without some sort of translator in the middle). Neither end of a URL provides anything resembling network topological hierarchy.

URLs are an obvious candidate to consider because they're in use, seem to basically work to identify routing endpoints, and are far from a random, out of thin air, choice.

In reality, you’re not really talking about URLs here, even. You’re talking about DNS host names. (The part before the // isn’t really part of what you want to consider in your network routing scenario, neither is anything that comes after the first /). It’s not that we couldn’t use some form of hierarchically structured human- readable name for this purpose… It’s that using DNS host names _REALLY_ wouldn’t work well.

Given the vast improvements in hardware since we last seriously thought about this (ca. 1990, IPv6) perhaps this worship of bit-twiddling and bit-packing may be a bit (haha) like those who once objected to anything but machine language programming because HLLs were so inefficient!

Or, perhaps, it’s not actually a love of bit-twiddling so much as a recognition that there are serious flaws with the idea of trying to use DNS host names for routing decisions. Come back with a more useful naming scheme that takes topology into consideration and lines up where routing decisions need to, and let’s discuss it more seriously. Continue pounding on DNS host names and you’re not going to make much headway because, well, it’s not quite the dumbest thing I’ve ever heard, but it isn’t that far off.

P.S. It was from a talk I gave in Singapore to the local HackerSpace and intended to provoke thought and discussion but not just "no, we can't do that because that's not the way we do things.”

I think dismissing the comments here as “no… that’s not how we do things” really fails to take proper heed of some of the comments. Owen

On Oct 9, 2019, at 18:43 , Matt Harris <matt@netfire.net> wrote:

On Wed, Oct 9, 2019 at 5:28 PM Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:

...

URLs are an obvious candidate to consider because they're in use, seem to basically work to identify routing endpoints, and are far from a random, out of thin air, choice.

In reality, you’re not really talking about URLs here, even. You’re talking about DNS host names. (The part before the // isn’t really part of what you want to consider in your network routing scenario, neither is anything that comes after the first /).

It’s not that we couldn’t use some form of hierarchically structured human- readable name for this purpose… It’s that using DNS host names _REALLY_ wouldn’t work well.

Except what if we used basic textual representations for addresses that kind of looked like DNS names, but didn't actually try to use DNS names? Let's even assume we keep DNS largely unchanged, but introduced "B records" to handle the new addressing scheme, similar to how we introduced AAAA records to handle translating between names and IPv6 addresses. Perhaps we also add a special-case "TLD-alike" called .address to indicate when we want to connect to the specified address and not do a DNS lookup of the name we've requested?

For example, let's say my internet domain is nanog.org <http://nanog.org/>. I might have DNS setup for nanog.org <http://nanog.org/>, but I may also claim addressing space under nanog.org <http://nanog.org/>. Since my ASN is 64500, I will use it to advertise "nanog.org <http://nanog.org/>" to my peers: so when you check a looking glass for nanog.org <http://nanog.org/>, you'll see that it's routing to AS 64500 just like any IPv4 or IPv6 announcement.

Except that’s not how it works for IPv4 or IPv6 announcements. You don’t route to an ASN (for better or worse, worse IMHO, but hard to fix at this point). You route to a next-hop (NLRI) and ASNs are primarily for loop detection/prevention and demarcation of boundaries of administrative control. Other than what you do in policy based on the AS PATH or other AS-related attributes, they really have zero significance in forwarding decisions.

Now if you want to visit a website called www.nanog.org <http://www.nanog.org/>, and you punch that into your web browser, it's going to do a DNS lookup. Assuming this addressing scheme is preferred over IPv4 or IPv6, the first thing your browser will do is a DNS lookup for a B record for "www.nanog.org <http://www.nanog.org/>" - and in my nanog.org <http://nanog.org/> zone, I'll have one or more B records pointing to the address hosting the site, for example: www.nanog.org <http://www.nanog.org/>. IN B webserver1.nanog.org <http://webserver1.nanog.org/> Upon receiving this, your browser will then initiate a port 443 TCP connection (or UDP for QUIC or whatever its protocol of choice is, in this, the year 3305) to webserver1.nanog.org <http://webserver1.nanog.org/>, which is what will be in the packet headers. Its upstream router will see this and route it until it reaches a member of the DFZ at which point that DFZ router will then determine that "webserver1.nanog.org <http://webserver1.nanog.org/>" is part of "nanog.org <http://nanog.org/>" and that "nanog.org <http://nanog.org/>" is announced by AS64500 which is available from two transit providers, prefer one of them based on whatever traffic engineering rules are the norm in 3305, and send the packet on to the next hop for that route.

Well, I’m not wild about the addressing scheme and I think it creates tremendous potential for confusion (and some serious implementation challenges for fast packet switching), but, I do like the idea of DFZ routing being based on destination ASN and candidate routes rather than on specific IPv4/IPv6 next-hop addresses. Also, you state two transit providers as if that is a simple router-implementable concept. That’s very hand-wavy in today’s world. Consider the following… Let’s say we have transit providers A and B. You are ISP Q. You have border routers numbered Q01 to Q50 scattered around the world. Let’s say that each of these routers peers with at least one of {A,B} and that some of them peer with both. For a packet arriving on any Qn router, the answer is relatively simple (pass it to a local peering session and you’re done.). Now, consider the scenario where 25% of your routers peer with A and 25% peer with B, but the two groups have a 50% overlap (12.5% of your total routers peer with A and B). The packet arrives at one of your routers Qn that is not a member of that 37.5% total (12.5% A only, 12.5% B only, 12.5% both) routers that are peered with either A or B. However, you have an indirect path on Qn via another transit AS Z that is announcing both A and B as reachable via its network. Do you forward the packet internally to a router that can reach A or B? Do you pass the packet directly to Z? What existing or new knobs in BGP are used to control this? What are the default behaviors? Today, the answer is simplified because you have a “Next-hop IP address” for each route and you forward the packet to the next hop of the best path received for that destination. In your proposal, there are multiple “paths” to the same AS, but you haven’t allowed for the tracking/management of the multiple next-hops. Of course, there’s also the issue of what happens when you forward a packet internally past a BGP-unaware router that doesn’t know about destinations {A,B} and thinks its best path is back towards where it came from, but that’s something we grapple with in today’s environment when faced with non-adjacent (indirect) next-hop information, so I would presume the same topological solutions would apply there.

On the other hand, if you wish to simply load whatever comes up when you make an HTTPS request to port 443 on webserver1.nanog.org <http://webserver1.nanog.org/>, you might enter "https://webserver1.nanog.org.address/ <https://webserver1.nanog.org.address/>" which will then skip the DNS check and simply try connecting to webserver1.nanog.org <http://webserver1.nanog.org/>.

When I think about it, this actually seems shockingly reasonable, potentially massive RAM requirements for routers aside (we're getting there anyway!). Am I missing something?

I think you’re missing several things, but the most glaring one is the one I outlined above. Owen

On Wed, 09 Oct 2019 17:43:00 -0400, bzs@theworld.com said:

URLs are an obvious candidate to consider because they're in use, seem to basically work to identify routing endpoints, and are far from a random, out of thin air, choice.

So explain in detail how a router gets from "URL" to "which interface to send the packet on". Include in your discussion how anycast works, and how to deal with things like www.google.com, which currently uses DNS and geolocation so not every host on the internet has the same view of what server(s) to contact. Problem example: My employer moved something from a 128.173/16 address to a 198.82/16 address without changing the name. How would your scheme address the fact that the routing may have changed, when the URL/hostname remains the same? Hint: If URLS or hostnames actually identified routing endpoints, we'd not have DNS.

On Wed, Oct 9, 2019 at 4:30 PM John R. Levine <johnl@iecc.com> wrote:

...

Can I summarize the current round of objections to my admittedly off-beat proposal (use basically URLs rather than IP addresses in IP packet src/dest) as:

We can't do that! It would require changing something!

Nope. You can summarize it as "it doesn't scale", which is what has killed endless numbers of superficially plausible bad ideas.

And Barry's been around long enough to know this. What's up Barry? What's the meta-argument you're trying to make here 'cause "bits is bits" is about as smart as telling a chef that "food is food." Regards, Bill -- William Herrin bill@herrin.us https://bill.herrin.us/

John R. Levine wrote:

There's only a few thousand top level domains, so routers should he able to handle this with no problem.  Whaddaya think?

Hierarchy inconsistent with network topology is useless for routing. Masataka Ohta

Bits is bits.

A fixed length bit field and a variable length bit field are incredibly different beasts at the hardware level. Knowing exactly after how many bits you can make a routing or switching decision is ... pretty darned useful. Kevin Menzel Infrastructure Analyst Sheridan College -----Original Message----- From: NANOG <nanog-bounces@nanog.org> On Behalf Of bzs@theworld.com Sent: Wednesday, October 9, 2019 5:43 PM To: John Levine <johnl@iecc.com> Cc: nanog@nanog.org; bzs@theworld.com Subject: Re: worse than IPv6 Pain Experiment OK OK OK. Can I summarize the current round of objections to my admittedly off-beat proposal (use basically URLs rather than IP addresses in IP packet src/dest) as: We can't do that! It would require changing something! I've no doubt many here are comfortable with the current architecture. Bits is bits. URLs are, to a machine, just bit strings though they do incorporate a hierarchical structure which isn't that dissimilar from current network/host parts of IP addresses. URLs are an obvious candidate to consider because they're in use, seem to basically work to identify routing endpoints, and are far from a random, out of thin air, choice. Given the vast improvements in hardware since we last seriously thought about this (ca. 1990, IPv6) perhaps this worship of bit-twiddling and bit-packing may be a bit (haha) like those who once objected to anything but machine language programming because HLLs were so inefficient! P.S. It was from a talk I gave in Singapore to the local HackerSpace and intended to provoke thought and discussion but not just "no, we can't do that because that's not the way we do things." -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

On Sat, Oct 05, 2019 at 04:36:50PM -0400, bzs@theworld.com wrote:

On October 4, 2019 at 15:26 owen@delong.com (Owen DeLong) wrote:

...

OK… Let’s talk about how?

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?

A bit in the header or similar (version field) indicating extending addressing (what we call IPv6, or similar) is in use for this packet.

How does that allow the host that only understands 32-bit addresses to exchange traffic with a host which sets this header bit? - Matt

And in which part of the header is this to be added ? -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.

On Oct 6, 2019, at 15:58, bzs@theworld.com wrote:



...

On October 6, 2019 at 15:18 mpalmer@hezmatt.org (Matt Palmer) wrote:

...

On Sat, Oct 05, 2019 at 04:36:50PM -0400, bzs@theworld.com wrote:

On October 4, 2019 at 15:26 owen@delong.com (Owen DeLong) wrote:

...

OK… Let’s talk about how?

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?

A bit in the header or similar (version field) indicating extending addressing (what we call IPv6, or similar) is in use for this packet.

How does that allow the host that only understands 32-bit addresses to exchange traffic with a host which sets this header bit?

As I said, it doesn't, but it lets each host decide that rather than the router tho if the host just knows enough to copy out the entire src/dst address (imagine the bits beyond the first 32 were in something like an extended ICMP options field w/in the IP header) then the rest could operate identically to ipv4.

So all you'd need added to a host IPv4 stack would be if you see this extended addressing flag/bit/whatever then there's more that needs to be copied out to each outgoing IP packet.

It would be the routers' job to interpret those extra bits for routing.

-- -Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

On Sun, 06 Oct 2019 17:47:24 -0400, bzs@theworld.com said:

All a strictly IPv4 only host/router would need to understand in that case is the IHL, which it does already, and how to interpret whatever flag/option is used to indicate the presence of additional address bits mostly to ignore it or perhaps just enough to know to drop it if it's not implemented.

So... how would a strict IPv4 router handle the case where 8.8.4.5.13.9/40 should be routed to Cogent, but 8.8.4.5.17.168/40 should be routed via Hurricane Electric, and no you can't just route to wherever 8.8.4.5 goes because there's yet another peering war and nobody's baked a cake yet, so sending packets for either route to the wrong link will cause blackholing?

Forrest Christian (List Account) wrote:

I've been ignoring this discussion because I feel this ship sailed many years ago, and IPv6, like it or hate it, is the best way forward we have.

A problem is that there is a cliff edge in front of you.

But, assuming you're expanding the address space, the simplest solution is to add the additional bits addresses at the end.

Sure.

On the other hand, this sure seems similar to what we do today with CGNAT and similar today since there are already 64K endpoints in both TCP and UDP per ./32 of IP....

The following draft makes it more explicit: https://tools.ietf.org/html/draft-ymbk-aplusp-10 The A+P Approach to the IPv4 Address Shortage R. Bush, Ed. Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional end point identifiers, A+P is equivalent to NAT with end to end transparency. Masataka Ohta

On Mon, 07 Oct 2019 03:03:45 -0400, Rob McEwen said:

Likewise for spam filtering - spam filtering would be knocked back to the stone ages if IPv4 disappeared overnight. IPv6 is a spam sender's dream come true, since IPv6 DNSBLs are practically worthless.

Riddle me this: Why then have spammers not abandoned IPv4 and moved to IPv6 where we're totally powerless to stop their floods of spam? I'm tired of hearing the excuse "We can't move to IPv6 because then we couldn't stop the spam" - if that were true, then every organization that *has* moved to IPv6 would be drowning in spam.

On 10/7/2019 7:37 AM, Valdis Klētnieks wrote:

On Mon, 07 Oct 2019 03:03:45 -0400, Rob McEwen said:

...

Likewise for spam filtering - spam filtering would be knocked back to the stone ages if IPv4 disappeared overnight. IPv6 is a spam sender's dream come true, since IPv6 DNSBLs are practically worthless. Riddle me this: Why then have spammers not abandoned IPv4 and moved to IPv6 where we're totally powerless to stop their floods of spam?

I'm tired of hearing the excuse "We can't move to IPv6 because then we couldn't stop the spam" - if that were true, then every organization that *has* moved to IPv6 would be drowning in spam.

(1) as Stephen Satchell said... because a huge percentage of mailboxes (perhaps the vast majority?) are still behind servers that (wisely!) only listen on IPv4 for non-auth connections, so spammers would have to make extremely large deletions to their distribution list if they only sent to emails where the mail server only listened on IPv6. (2) For my own commercial anti-spam blacklist, I've had SEVERAL new subscribers this past year who specifically complained about spams that my anti-spam blacklists (AND all the other ones like Spamhaus, etc!) were NOT blocking. I requested more information about the ones that weren't getting blocked... and they were almost all IPv6-sent spams. I simply explained to them that they do NOT have to do this, and that most of that spam will go away the moment that their server only listens on IPv4 (at least, for non-SMTP-AUTH email - they can still listen for IPv6 authenticated email without these problems). I also explained to them that there hadn't been a situation in the history of the world where an email didn't make it to a server that only listened on IPv4 for non-authenticated email. (3) Many IPv6 mail servers have had to invest/expend significantly more resources per mailbox. (4) trying to get everyone to move too quickly to IPv6 POTENTIALLY actually damages email and harms OTHER's spam filtering. Why? Because it enables listwashing. A spammer can literally send to 10s of thousands of email addresses each from a separate /64 block, with a one-to-one relationship between the /64 block and the recipient email address. Then they can listwash spamtrap addresses based on which of those /64 blocks get blacklisted. It ALSO harms email because shady marketers get the idea that there are endless new IPs to burn through, and that only emboldens them. So when it comes to email, it turns out that IPv4 scarcity (for non-auth connections) is a feature not a bug! But, if desired, you can STILL have massive amounts of IPv6 clients sending via SMTP authentication - so this won't limit your ability for your refrigerator to send authenticated email to you! (so that greatly minimizes the "but we're running out" longer-term argument - besides the fact that this isn't really a HUGE problem anyways - since IPv6 clients already are already able to connect to IPv4 servers) -- Rob McEwen https://www.invaluement.com

I didn't quite say nothing would need to be changed, only that the changes would be by and large very minimal, some new cases in the existing IPv4 stacks, rather than an entirely new stack. Particularly for hosts, if this bit (flag, whatever) is set be sure to copy the entire IP packet into your dest headers. The extended addressing I describe could probably be mostly implemented in hosts as a new ICMP option for extended addressing. On October 6, 2019 at 17:58 valdis.kletnieks@vt.edu (Valdis Klētnieks) wrote:

On Sun, 06 Oct 2019 17:47:24 -0400, bzs@theworld.com said:

...

All a strictly IPv4 only host/router would need to understand in that case is the IHL, which it does already, and how to interpret whatever flag/option is used to indicate the presence of additional address bits mostly to ignore it or perhaps just enough to know to drop it if it's not implemented.

So... how would a strict IPv4 router handle the case where 8.8.4.5.13.9/40 should be routed to Cogent, but 8.8.4.5.17.168/40 should be routed via Hurricane Electric, and no you can't just route to wherever 8.8.4.5 goes because there's yet another peering war and nobody's baked a cake yet, so sending packets for either route to the wrong link will cause blackholing?

x[DELETED ATTACHMENT <no suggested filename>, application/pgp-signature]

-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

On Oct 5, 2019, at 13:36 , bzs@theworld.com wrote:

On October 4, 2019 at 15:26 owen@delong.com (Owen DeLong) wrote:

...

OK… Let’s talk about how?

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?

A bit in the header or similar (version field) indicating extending addressing (what we call IPv6, or similar) is in use for this packet.

This still requires you to basically rewrite the L3 stack to accommodate the new addresses.

They may not be able to talk but rather than a whole new stack it would have just been an extension of the commonly used IPv4 stack, more like a (e.g.) new ICMP option.

Uh, no, it would still have required reimplementing the entire L3 stuff at pretty much the same work level as the current IPv6 mechanism. You would still have needed to update: All L4->L3 binding code All Name Resolution code You’d still be faced with all the really hard problems that came with IPv4->IPv6 transition: Updating your applications to understand 128-bit addresses in logs, etc. Updating your provisioning systems to track 128-bit addresses. etc.

Or even an octet indicating how many octets in this address, default would be four (or even a nybble indicating how many 16-bit words.)

This doesn’t make transition any easier and it makes ASIC processing of packet forwarding a heck of a lot harder.

Something simple like that could have, at least in the early stages (which we're still in w/ IPv6 unfortunately), have been entirely handled in userspace in the software.

Nope… It really couldn’t and that would actually be worse… Right now, the biggest hurdles to IPv6 adoption aren’t the kernel level changes for a new stack, they’re the legacy application changes needed to support bigger addresses.

IPv4? Do the usual. Extended addressing? Hand to a userspace library. A minor poke to the drivers plus the userspace software. In many cases wouldn't even require a reboot to install, but at worst a quick reboot to install the low-level driver that knows to switch extended addressing packets to userspace.

I think you’re very confused about where the pain points with IPv6 are and what it would take to actually implement what you are suggesting here.

Particularly if the low 32 bits indicated the same IPv4 interface w/in a campus so primarily only the routers needed to interpret the rest of the address.

Uh, so a packet arrives at your 32-bit only application and you can’t tell whether you need to reply to the student’s laptop on the other side of the room or the linear accelerator 3,000 miles away because that’s all included in the 96 bits you didn’t even see that got spirited away to some user-space translator layer. What am I missing?

So it'd get to the right router who'd hand it off to the right (32-bit) host. Only a problem if your campus happened to have 4B+ hosts (or maybe 2B+), not likely.

Or if you need to communicate both within and outside of your campus (far more likely).

It's similar to IPv4v6 stacks but the host would return the full address in the (extended) IP packet.

How’s the host supposed to do that if the host hasn’t been updated to handle extended addressing? If the host has been updated, then there’s no difference from the current situation with IPv6… The need to update every host (and these days, more relevant, the need to update every application).

In current IPv4v6 stacks (NAT et al) the router has to keep track and interpolate by rewriting the packets or similar. In what I describe that's not necessary as each packet retains the full address as it passes through the host.

Yeah, except, you’re assuming every host gets updated with the necessary software to handle essentially IPv6 addressing without adding the IPv6 stack. This sounds like more pain for less gain to me.

Well, basically your question asks for a complete stack design right here right now, is that really where we want to go?

My point is that the changes to implement IPv6 on a given host (at the kernel level) are not significantly more than the changes you are proposing to do what you want. Difference is that they’ve mostly been done for the vast majority of hosts for IPv6 whereas yours would be a new implementation. It still doesn’t yield any greater compatibility because you’ve still got the difficulty of coping with the applications that simply can’t understand a larger internet (which is the biggest hurdle with IPv6 right now).

But the sort of thing I suggest was suggested.

And did not gain consensus for the same reasons I outline above, I suspect.

Some of the considerations as to why not do it this way were good, such as get some other bugs/limitations out of IPv4. And some not so good like bit-level performance and compatibilty considerations that have changed considerably since 1990.

Hindsight always yields what seems like errant judgment calls 30 years ago. At the time, they seemed like a good idea.

Were the 36-bit'ers still at the table in 1990? Probably.

36-bits would have been a terrible idea, frankly. Look how long it’s taken for IPv6 to get any real traction? Think about how painful it will be if we have to try and change the address format again? Far better to go for such an excessive number of addresses as to obviate the problem as permanently as possible. It’s not that I think IPv6 will last for ever, I’m just hoping that it’s something other than address shortage that leads to its obsolescence. In fact, if we don’t have an address shortage, the next protocol might be able to continue using IPv6 addresses and reduce the transition pain.

And CGNAT et al wasn't really conceived of yet or not very completely so it was assumed this would all be so urgent as to propel itself into the mainstream.

Frankly, I’m not convinced we wouldn’t all be better off if CGNAT hadn’t been conceived and implemented and this had been so urgent as to propel itself into the mainstream. It certainly would have been a higher level of pain in the short run, but it also would have led to a much shorter period of pain.

...

How would you have made a 128-bit address more human-readable? Does it really matter?

That really depends on your priorities. If the priority was, as with ipv4, location independence so all bits are equally meaningful (i.e., necessary to know what's desired), then it's difficult.

If it were actually treated as a potential problem then more defaults may have been engineered in.

But since this is a human interface problem I lean towards better software to view and manipulate addrs and let the engineers do what they need to do.

Seems reasonable, but I think what we’ve got is reasonably good. I have found that with a little experience and a good subnetting plan, IPv6 addresses can become quite human readable when it matters.

It's the tail wagging the dog or perhaps the dog returning to its, um, whatever.

We developed, w/ IPv4, this entire culture and software regime which thought it was reasonable to sometimes enter/read IPv4 addrs because they weren't too hard and then carried that over to IPv6 (not in theory, in practice.)

Yes, but I’d argue that the difficulty people have understanding CIDR in IPv4 and getting net masks and their implications right are a clear indication that decimal-coded-octets were NOT the right choice for address readability. Further, an IPv6 address using the same scheme would look something like: 38.32.0.0.144.48.0.0.0.0.0.0.32.0:0.2 If my math is correct, that’s the equivalent of: 38.32.0.0.144.48.0.0.0.0.0.0.32.0:0.2 2620: 0: 0930: 0: 0: 0: 200: 2 (keeping the : aligned with the corresponding decimal) 2620:0:930::200:2 (Human readable form) I don’t know about you, but that looks more like an SNMP OID than anything useful to me. I find the hex representation much easier. It doesn’t get better for addresses containing letters, either. Consider: 2620:0:930::dead:beef 2620: 0: 0930: 0: 0: 0: dead: beef 38.32.0.0.144.48.0.0.0.0.0.0.208.173.190.239 I’ll take the 2620:0:930::dead:beef version any day.

Meaning, for example, if DNS isn't working for you then you're often left to entering raw IP addresses manually, and "you" can often be non-technical users. IPv4, not a big deal, IPv6, challenging.

Well, entering a 128-bit number is going to be challenging no matter how you format it. Humans just don’t cope well with large numbers. If you’ve got an idea for a better format, I’m all ears. But grousing about the fact that 128 bit numbers are bigger than 32 bit numbers isn’t particularly helpful, since 32-bit numbers can’t represent the necessary number of hosts.

Mere cut+paste no doubt helps.

Certainly one solution. DNS failures aren’t all that common these days in my experience, either.

...

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?

IPv4 is not that much more difficult than a phone number. IPv6 is.

That depends… Are you including all variations of all international phone numbers in that calculation, or, just NANP numbers (e.g. +1.408.555.1212)? For NANP, sure, they’re relatively easy, but it’s an 11 digit number where the first digit is always 1. That supports a total of 10,000,000,000 devices, which is a bit more than IPv4 since it’s a true decimal number and doesn’t suffer from the octet-encoding overhead (0-255 instead of 000-999), so in 12 digits, you only get 4 billion instead of 10 in effectively 10 digits.

IPv4 benefits from chunking, like phone numbers.

IPv6 has chunking too. The separator is a : and not a - or ., but so what? I don’t think 2620.0.930..200.2 is significantly easier to read or better chunked than 2620:0:930::200:2.

If I have an idea of the "net", by which I mean the part which comes up repeatedly (such as w/in a campus) often the first two numbers, then all I really have to remember anew is the last two numbers, maybe only the last. For IPv6 it can be more difficult to commit a prefix to memory even if it's used somewhat regularly.

I don’t know… I don’t find 2620:0:930:: any harder to remember than 192.159.10, but perhaps that’s just me.

But I'd agree this is mostly a red herring, better human interface software should help and that might take time to evolve.

I think what we have now is reasonably good, actually. It takes some getting used to, but I bet you’ve had more years getting used to IPv4 than most of us have with IPv6.

...

All of this is mostly absurd as DNS names are human readable regardless of whether they point to A, AAAA, or both records.

As I said it often comes up precisely because, for some reason, DNS isn't available or not working correctly.

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 issue. Owen

Owen DeLong wrote : 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 issue.

About half of my devices, including all the VOIP phones, do not have DNS. I just cannot afford to lose the phones if there is a DNS failure. They have DHCP, but not DNS. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...

Owen DeLong wrote : I’m not sure how giving them DNS names makes them less resilient to DNS failures.

How do you resolve the IP address of the PBX ? I hard-code (in the master config). The PBX does not have a DNS name. I want my support staff to know its IP on the top of their head. DNS failures do not happen often, but they do happen. Fat fingers change or delete the entry, the zone gets corrupted or partially corrupted, that kind of stuff. There are things that redundant hardware and network will not solve. If the PBX address becomes unresolvable, the SIP registrations will timeout and I'm going to lose phones. Granted, it would not take that much time to troubleshoot, but just the possibility, not matter how remote, that it could happen makes it a non-option. If DHCP fails, I have a 169.254 secondary address. It may not be elegant, but it is resilient. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...

On October 8, 2019 at 03:00 michel.py@tsisemi.com (Michel Py) wrote:

...

Owen DeLong wrote : 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 issue.

About half of my devices, including all the VOIP phones, do not have DNS. I just cannot afford to lose the phones if there is a DNS failure. They have DHCP, but not DNS.

Considering the audience here configuration, maintenance, and repair might involve entering numeric IP addresses. Not the average user? I don't know, define average, how many tens of millions of sites out there have more than just edge routers? How many have adequate educational and reference materials in their native language? etc. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

Mark Andrews wrote:

There is also nothing stopping machines updating their addresses in the DNS dynamically securely. Except that glue A/AAAA can not be updated so easily and security configuration is even more painful than address configuration.

Masataka Ohta

Mark Andrews wrote:

Actually you can do exactly the same thing for glue. KEY records below bottom of zone cut exactly the same way as you have A and AAAA below bottom of zone cut. The only difference is the zone listed in the UPDATE message.

The tricky part is in converting a domain name of a primary nameserver to IP addresses, when the IP addresses of the primary nameserver changes. If the primary nameserver ask DNS its IP address to send an update request to itself, it will get old addresses. What if primary.childzone.parentzone.example.com is the primary for parentzone.example.com, and childzone.parentzone.example.com? Another problem is lack of redundancy that, when the primary server is down, dynamic update is impossible.

Now is that a “complicated” policy?

My point is that configuring lengthy random string of security key is more painful than configuring addresses. Masataka Ohta

Doug Barton wrote:

Not if you configure your services (like DNS) with static addresses, which as we've already discussed is not only possible, but easy.

That's your opinion. But, as Mark Andrews said:

Actually you can do exactly the same thing for glue.

I show it not so easy.

Please stop spreading FUD regarding this topic.

Automatic renumbering involving DNS was important design goal of IPv6 with reasons. Lack of it is still a problem. Masataka Ohta

John Levine wrote:

...

Automatic renumbering involving DNS was important design goal of IPv6 with reasons.

News flash: nobody used the A6 RRTYPE which was intended to support IPv6 renumbering. In 2002, RFC 3363 made A6 experimental. In 2012, RFC 6563 made A6 historic.

These days we all use AAAA, and we assign static addresses to our IPv6 servers.

FYI, A6 is totally useless for automatic renumbering. Masataka Ohta

Mark Andrews wrote:

Please explain how https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/ would not work.

Update messages are designed to be forwarded and that includes signed UPDATE messages be they TSIG or SIG(0). Named already forwards UPDATE messages if your tell it to.

Forward to which IP address of the primary? Unupdated one?

We already have UPDATE clients that lookup SRV records to send UPDATE

With SRV? You introduce yet another server, address of which may also be updated!? Congratulations, you have made barely solvable problem unsolvable. Masataka Ohta

Doug Barton wrote:

...

Automatic renumbering involving DNS was important design goal of IPv6 with reasons.

Lack of it is still a problem.

Meanwhile, the thing that most people miss about IPv6 is that except in edge cases, you never have to renumber. You get a massive address block that you can use as long as you pay your bill.

That is called "provider lock-in", which is the primary reason, when IPng WG was formed, why automatic renumbering is necessary for IPv6.

So, again, stop spreading FUD.

Look at the fact that IPv6 failed badly. Masataka Ohta

Doug Barton wrote:

And even if you do need to change providers, once you have your addressing plan in place all you have to change is the prefix.

Your attempt to hype people that renumbering were easy has zero probability of success here.

Except that it's not failing,

It failed from the beginning. Masataka Ohta

On 10/4/19 7:45 AM, Warren Kumari wrote:

On Fri, Oct 4, 2019 at 5:13 AM Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:

...

Doug Barton wrote:

...

And even if you do need to change providers, once you have your addressing plan in place all you have to change is the prefix.

This is the same as saying "If you need to change providers in IPv4, once you have your addressing plan in place all you have to do is change the prefix", or "To build the Eiffel Tower, all you have to do is bolt bits of metal together" -- it's technically correct*, but handwaves away the actual complexity and scale of work. Yes, you (clearly) can renumber v6 networks, and it's *probably* easier than renumbering v4, but "just change the prefix" oversells it.

I was assuming that this audience understands the relative complexity of changing the network parts of the address, and leaving the subnet and host parts in place. And by and large, it is not true that you can do this with IPv4. You might occasionally get lucky with it, but that would be the exception, not the rule. As for your Eiffel Tower example, the design and architecture are the pieces that would already be in place as part of your networking plan, so in a sense we're talking about RE-building the Eiffel Tower by taking off one bit of metal (the old network) and bolting another piece in its place. Not building it all over again from scratch. So you can credibly accuse me of underselling the renumbering effort, but don't engage in hyperbole to try to balance the scales. Renumbering has its pain points regardless of the protocol, but if you've designed your network correctly IPv6 renumbering is considerably easier than it is in IPv4. Doug

On Thu, Oct 3, 2019 at 10:42 PM Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote:

Doug Barton wrote:

...

...

Automatic renumbering involving DNS was important design goal of IPv6 with reasons.

Lack of it is still a problem.

...

Meanwhile, the thing that most people miss about IPv6 is that except in edge cases, you never have to renumber. You get a massive address block that you can use as long as you pay your bill.

That is called "provider lock-in", which is the primary reason, when IPng WG was formed, why automatic renumbering is necessary for IPv6.

If this is a concern, then get an allocation from your local RIR and announce it yourself. Then no provider lock-in based on address space of any sort. In general any sort of provider move is going to be disruptive if you don't have your own address space, so that should be taken into account when choosing to use address space that is somebody else's for production services that need to be reachable globally.

So, again, stop spreading FUD.

Look at the fact that IPv6 failed badly.

Huh? IPv6 has succeeded slowly, not failed badly. There are loads of us using it in production today just fine.

On 10/2/19 15:03, Naslund, Steve wrote:

In my experience, the biggest hurdle to installing a pure IPv6 has nothing to do with network gear or network engineers.  That stuff I expect to support v6.  This biggest hurdle is the dumb stuff like machinery interfaces, surveillance devices, the must have IP interface on such and such of an obsolete appliance, etc.  The dumb legacy app that supports the ancient obsolete pen plotter that we must keep forever, etc.

Using the plotter example, why is it obsolete and must be replaced if it still works? It's a waste of money to dump fully functional hardware because software. The argument to justify its replacement needs to be something along the lines of the new plotter will output faster and save X hours a day which is equal to Y hours of time over a year. Not that the new one supports IPv6 and yeah that's about it. Oh the new one also supports TLSv1.3 to make sure your plots can't be intercepted by your cube neighbor as you walk across the office.

On 10/3/19 13:13, Mark Andrews wrote:

...

On 4 Oct 2019, at 4:35 am, Seth Mattinen<sethm@rollernet.us> wrote:

On 10/2/19 15:03, Naslund, Steve wrote:

...

In my experience, the biggest hurdle to installing a pure IPv6 has nothing to do with network gear or network engineers. That stuff I expect to support v6. This biggest hurdle is the dumb stuff like machinery interfaces, surveillance devices, the must have IP interface on such and such of an obsolete appliance, etc. The dumb legacy app that supports the ancient obsolete pen plotter that we must keep forever, etc.

Using the plotter example, why is it obsolete and must be replaced if it still works? It's a waste of money to dump fully functional hardware because software. The argument to justify its replacement needs to be something along the lines of the new plotter will output faster and save X hours a day which is equal to Y hours of time over a year. Not that the new one supports IPv6 and yeah that's about it. Oh the new one also supports TLSv1.3 to make sure your plots can't be intercepted by your cube neighbor as you walk across the office. Firstly adding IPv6 doesn’t remove IPv4.

I know that. What I'm trying to say is that many companies aren't willing to throw away working equipment to gain a nebulous (to them) software feature like IPv6 that doesn't improve on its hardware functional state.

Let me clarify that I 100% agree with both Job and Dovid. It is indeed a terrible idea. And not everyone is even convinced IPv6 is the right next step. So it’s obviously wrong to push people towards where someone thinks, even if it’s the majority. I just had a hunch that even then we would still not see IPv6 adoption.. So there must be many more problems that we overlook. I just wanted to hear what other people think on the matter.

On 2 Oct 2019, at 19:43, Job Snijders <job@instituut.net> wrote:

It appears in your thought experiment, a stick is dressed up like a carrot.

I’m not a fan of deploying purely punitive strategies to promote adoption; technologies should stand on their own and be able to convince the potential users based on their merit, not based on penalties.

On Oct 2, 2019, at 4:04 PM, Nick Hilliard <nick@foobar.org> wrote:

Antonios Chariton wrote on 02/10/2019 17:33:

...

What if, globally, and starting at January 1st, 2020, someone (imagine a government or similar, but with global reach) imposed an IPv4 tax. For every IPv4 address on the Global Internet Routing Table, you had to pay a tax. Let’s assume that this can be imposed, must be paid, and cannot be avoided using some loophole. Let’s say that this tax would be $2, and it would double, every 3 or 6 months.

Interesting idea. Let's say it started off at $2 / month and doubled every 3 months. At the end of month 12, it would be $32/month. After 5 years, we'd be talking about just over $2 million per IP address per month, i.e. a little over half a billion dollars per /24.

What happens when v4 is gone? Surely you won’t let it end there - After all, If you have the ability and infrastructure to do this, why not tax IPv6 too? This would cut down on the number of “undesirables" on the internet by pricing it out of the reach of all but the largest megacorporations. Eventually we can reduce the internet to a few dozen authorized parties in each region and we’ll only need enough IP addresses for those. I can imagine a number of governments around the world would be very interested in this.