Mailing List Archive

> On 20210904, at 22:26, Grant Taylor via NANOG <nanog@nanog.org> wrote:
>
> Hi,
>
> Does anyone have any recommendation for a viable IPv6 tunnel broker / provider in the U.S.A. /other/ /than/ Hurricane Electric?

SixXS shut down 4 years ago, to get ISPs to move their butts... as long as there are tunnels, they do not have a business case.

See also https://www.sixxs.net/sunset/ and the "Call Your ISP for IPv6" thing in 2016: https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6 along with plans.

You people keep on giving money to ISPs that are not providing the service you want.

> I reluctantly just disabled IPv6 on my home network, provided by Hurricane Electric, because multiple services my wife uses are objecting to H.E.'s IPv6 address space as so called VPN or proxy provider. Netflix, HBO Max, Pandora, and other services that I can't remember at the moment have all objected to H.E

Tunnels are VPNs

So, that makes sense that services that need to 'protect their IP' (silly property) because they did not figure out people might live anywhere in the world might want to pay for things and receive service... [sic]


IPv6 tunnels where meant as a transition mechanism, as a way for engineers to test IPv6 before it was wide spread.

Deploying IPv6 is easy, and due to IPv4-squeeze (unless you have slave monopoly money and can just buy 2% of the address space), you could have spent the last 25 years getting ready for this day. And especially in the last 5 - 10 years, deploying IPv6 has been easy, due to all the work by many many many people around the world in testing and actively deploying IPv6. Of course there are still platforms that don't support DHCPv6 for instance, but things are easy, stable and often properly battle tested.

>
> Disabling IPv6 feels *SO* *WRONG*! But fighting things; hacking DNS, null routing prefixes, firewalling, etc., seems even more wrong.
>
> Is there a contemporary option for home users like myself who's ISP doesn't offer native IPv6?

As this is NANOG.... and people on the list are ISPs and it is 2021, thus IPv6 being 25+ years old, the best that is left to do is:

https://www.youtube.com/watch?v=ASXJgvy3mEg

Go Jared!

Greets,
Jeroen

Jeroen,

> You people keep on giving money to ISPs that are not providing the
service you want.

Not everyone has the luxury of picking their ISP, and the common consumer
doesn't know or care about IPv6. They want Netflix to work and that's it.

Ryan


On Sat, Sep 4, 2021, 1:47 PM Jeroen Massar via NANOG <nanog@nanog.org>
wrote:

>
> > On 20210904, at 22:26, Grant Taylor via NANOG <nanog@nanog.org> wrote:
> >
> > Hi,
> >
> > Does anyone have any recommendation for a viable IPv6 tunnel broker /
> provider in the U.S.A. /other/ /than/ Hurricane Electric?
>
> SixXS shut down 4 years ago, to get ISPs to move their butts... as long as
> there are tunnels, they do not have a business case.
>
> See also https://www.sixxs.net/sunset/ and the "Call Your ISP for IPv6"
> thing in 2016: https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6 along
> with plans.
>
> You people keep on giving money to ISPs that are not providing the service
> you want.
>
> > I reluctantly just disabled IPv6 on my home network, provided by
> Hurricane Electric, because multiple services my wife uses are objecting to
> H.E.'s IPv6 address space as so called VPN or proxy provider. Netflix, HBO
> Max, Pandora, and other services that I can't remember at the moment have
> all objected to H.E
>
> Tunnels are VPNs
>
> So, that makes sense that services that need to 'protect their IP' (silly
> property) because they did not figure out people might live anywhere in the
> world might want to pay for things and receive service... [sic]
>
>
> IPv6 tunnels where meant as a transition mechanism, as a way for engineers
> to test IPv6 before it was wide spread.
>
> Deploying IPv6 is easy, and due to IPv4-squeeze (unless you have slave
> monopoly money and can just buy 2% of the address space), you could have
> spent the last 25 years getting ready for this day. And especially in the
> last 5 - 10 years, deploying IPv6 has been easy, due to all the work by
> many many many people around the world in testing and actively deploying
> IPv6. Of course there are still platforms that don't support DHCPv6 for
> instance, but things are easy, stable and often properly battle tested.
>
> >
> > Disabling IPv6 feels *SO* *WRONG*! But fighting things; hacking DNS,
> null routing prefixes, firewalling, etc., seems even more wrong.
> >
> > Is there a contemporary option for home users like myself who's ISP
> doesn't offer native IPv6?
>
> As this is NANOG.... and people on the list are ISPs and it is 2021, thus
> IPv6 being 25+ years old, the best that is left to do is:
>
> https://www.youtube.com/watch?v=ASXJgvy3mEg
>
> Go Jared!
>
> Greets,
> Jeroen
>
>

On 2021-09-04 23:02, Ryan Hamel wrote:
> Jeroen,
>
> > You people keep on giving money to ISPs that are not providing the
> service you want.
>
> Not everyone has the luxury of picking their ISP,

But this list is NANOG.... Network Operators. We are the ISPs....

> and the common consumer doesn't know or care about IPv6.

And they indeed should not have to care. Good that this is not a
consumer list, or a ISP complaint line (though, I guess complaining
about peering or broken connectivity is in the charter)

> They want Netflix to work and that's it.

They thus have no need for IPv6, which was the question...

Netflix works mostly fine over IPv4 (or heck CGN as that is what one is
likely headed to if your ISP did not get chunks of free IPv4 address
space), it is actually still IPv6 where they sometimes have a few PMTU
blackholes... ;) [though, have not noticed one in a while now]

Greets,
Jeroen

* ryan@rkhtech.org (Ryan Hamel) [Sat 04 Sep 2021, 23:04 CEST]:
>Not everyone has the luxury of picking their ISP, and the common consumer
>doesn't know or care about IPv6. They want Netflix to work and that's it.

We just had a 100+ post thread about Netflix not working because CGNs
were misclassified as VPN endpoints.


-- Niels.

According to Jeroen Massar via NANOG <jeroen@massar.ch>:
>On 2021-09-04 23:02, Ryan Hamel wrote:
>> Jeroen,
>>
>> > You people keep on giving money to ISPs that are not providing the
>> service you want.
>>
>> Not everyone has the luxury of picking their ISP,
>
>But this list is NANOG.... Network Operators. We are the ISPs....

Well, some of us are. I have a choice of an excellent local fiber ISP that
does not offer IPv6 or Spectrum cable which is generally awful but does have v6.
So I use a tunnel.

I have asked my ISP about IPv6 and their answer is that that they're not opposed to
it but since I am the only person who has asked for it, it's quite low on the list
of things to do.

R's,
John
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Sat, Sep 4, 2021, 22:49 John Levine <johnl@iecc.com> wrote:

> I have asked my ISP about IPv6 and their answer is that that they're not
> opposed to
> it but since I am the only person who has asked for it, it's quite low on
> the list
> of things to do.
>

Sounds like a consulting opportunity :)

Thank you
jms

>

On 9/5/21 04:49, John Levine wrote:

> Well, some of us are. I have a choice of an excellent local fiber ISP that
> does not offer IPv6 or Spectrum cable which is generally awful but does have v6.
> So I use a tunnel.
>
> I have asked my ISP about IPv6 and their answer is that that they're not opposed to
> it but since I am the only person who has asked for it, it's quite low on the list
> of things to do.

Supporting the routing and forwarding of IP addresses is just about the
most basic thing any ISP should do.

If that is low on their to-do list, what else could they possibly be doing?

Mark.

On Sat, Sep 4, 2021 at 9:36 PM Mark Tinka <mark@tinka.africa> wrote:

> Supporting the routing and forwarding of IP addresses is just about the
> most basic thing any ISP should do.
>
> If that is low on their to-do list, what else could they possibly be doing?
>

Counting all the profit they make from a captive audience with no
competition? ;)

-A

On 9/4/21 2:44 PM, Jeroen Massar via NANOG wrote:
> SixXS shut down 4 years ago, to get ISPs to move their butts... as
> long as there are tunnels, they do not have a business case.

I saw that.

> See also https://www.sixxs.net/sunset/ and the "Call Your ISP for
> IPv6" thing in 2016: https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6
> along with plans.

I have contacted my ISP and inquired about IPv6 one or more times every
year that I've been using them.

> You people keep on giving money to ISPs that are not providing the
> service you want.

Are you talking generally or are you using me as an example (read:
scapegoat)? -- It's okay if you are. I'd like to delve further into
this idea.

I have three ISPs in my town of just shy of 100k people within an hour
drive of the largest city in the state of more than 700k people.

- Municipal fiber - 1 Gbps - IPv4 only - $50 / month
- Local cable co. - ~100 Mbps - IPv4 and IPv6 - for $100 / month
- ILEC xDSL - ~50 Mbps - why would I look - for $100 month

There may be cellular Internet options, but those aren't ... economical,
especially for streaming.

Of those three which would you choose?

So ... I think I'm in quite the same position as John L. is.

> Tunnels are VPNs

I concede the technical point and move on.

> So, that makes sense that services that need to 'protect their IP'
> (silly property) because they did not figure out people might live
> anywhere in the world might want to pay for things and receive
> service... [sic]

I agree there is some questionable ... /thought/ going on somewhere. --
I'm reluctant to call it /logic/.

I agree that some people are trying to circumvent geographical restrictions.

However, my wife and I are not. We want to access content that's for
the address we have on file with the companies, that we have service at,
and that we receive the paper bills at. -- As I've stated before in
other threads, I believe that companies are capable of adding 1 + 1 + 1
to get 3. If they /wanted/ to. As such, I can only surmise that they
do not /want/ to correlate the multiple addresses and allow us to view
content for the same market.

> IPv6 tunnels where meant as a transition mechanism, as a way for
> engineers to test IPv6 before it was wide spread.

And seeing as how I can't get IPv6 natively from multiple providers that
I've worked with in the last 20 years, I can only surmise that we as an
industry are still transitioning from single stack to dual stack.

> Deploying IPv6 is easy, and due to IPv4-squeeze (unless you have
> slave monopoly money and can just buy 2% of the address space), you
> could have spent the last 25 years getting ready for this day. And
> especially in the last 5 - 10 years, deploying IPv6 has been easy, due
> to all the work by many many many people around the world in testing
> and actively deploying IPv6. Of course there are still platforms that
> don't support DHCPv6 for instance, but things are easy, stable and
> often properly battle tested.

And yet here we are.

As a consumer I have no effective influence.

> As this is NANOG.... and people on the list are ISPs and it is 2021,
> thus IPv6 being 25+ years old, the best that is left to do is:
>
> https://www.youtube.com/watch?v=ASXJgvy3mEg

And that's arguably what my city did. They got together and installed
municipal fiber. Save for the lack of IPv6, it wins on all counts;
faster, cheaper, better customer service, and other non-technical perks.
Just no IPv6. Hence why I have historically augmented my municipal
GPON with an H.E. IPv6 tunnel. -- In fact, I am going to continue with
said H.E. IPv6 tunnel, just without advertising it to the network (RA /
DHCPv6). I will have to statically configure IPv6 on things that I want
to use it on. The rest of the home network will be IPv4 only.

I feel like 1995 called and want's their single stack Internet back.
<ASCII tear>

So, Jeroen, what would you recommend that people like John L. and myself do?



--
Grant. . . .
unix || die

On Sun, 5 Sept 2021 at 08:25, Grant Taylor via NANOG <nanog@nanog.org> wrote:

> - Municipal fiber - 1 Gbps - IPv4 only - $50 / month
> - Local cable co. - ~100 Mbps - IPv4 and IPv6 - for $100 / month
> - ILEC xDSL - ~50 Mbps - why would I look - for $100 month
>
> There may be cellular Internet options, but those aren't ... economical,
> especially for streaming.
>
> Of those three which would you choose?

Municipal fiber. Which is the point, you cannot capitalise offering
IPv6, so offering it is bad for business. People who have adopted IPv6
have eaten into their margins for no utility.
I view IPv6 as the biggest mistake of my career and feel responsible
for this horrible outcome and I do apologise to Internet users for
it. This dual-stack is the worst possible outcome, and we've been here
over two decades, increasing cost and reducing service quality. We
should have performed better, we should have been IPv6 only years ago.

I wish 20 years ago big SPs would have signed a contract to drop IPv4
at the edge 20 years from now, so that we'd given everyone a 20 year
deadline to migrate away.
20 years ago was the best time to do it, the 2nd best time is today.
If we don't do it, 20 years from now, we are in the same position,
inflating costs and reducing quality and transferring those costs to
our end users who have to suffer from our incompetence.

--
++ytti

On 9/4/21 11:43 PM, Saku Ytti wrote:
> Municipal fiber.

;-)

> Which is the point, you cannot capitalise offering IPv6, so offering
> it is bad for business. People who have adopted IPv6 have eaten into
> their margins for no utility.

I don't understand. :-/

> I view IPv6 as the biggest mistake of my career and feel responsible
> for this horrible outcome and I do apologise to Internet users for
> it.

*blink* ... *blink*

First, thank you. I say that sincerely from and end user point of view
feeling like I'm between a rock and a hard place, one of which is
closing in.

Second, I can't say that similar thoughts haven't crossed my mind.

> This dual-stack is the worst possible outcome, and we've been here
> over two decades, increasing cost and reducing service quality. We
> should have performed better, we should have been IPv6 only years ago.

I remember LAN networking back in the '90s where multiple / mixed
protocols was a Bad Thing™. I view IPv4 and IPv6 as tantamount to the
same (or at least very similar) thing. What's worse is that IPv4 and
IPv6 have extremely similar sounding names. Though I think in some ways
that IPv4 and IPv6 are effectively as technically different from each
other as IP(v4) and IPX. Though at least they had the decency to have
more different names.

> I wish 20 years ago big SPs would have signed a contract to drop IPv4
> at the edge 20 years from now, so that we'd given everyone a 20 year
> deadline to migrate away.

Hindsight is 20/20 for a while. Then ... bit rot.

> 20 years ago was the best time to do it, the 2nd best time is today.
> If we don't do it, 20 years from now, we are in the same position,
> inflating costs and reducing quality and transferring those costs to
> our end users who have to suffer from our incompetence.

Sadly, I think that we are back to the multi-protocol days of old. And
I believe that we are going to be stuck here for much of my career. :-(



--
Grant. . . .
unix || die

> In fact, I am going to continue with said H.E. IPv6 tunnel, just without advertising it to the network (RA / DHCPv6). I will have to statically configure IPv6 on things that I want to use it on.

There we get to the heart of things.

The problem is not with IPv6 or your ISP (*), but with the Netflix software.
Doing happy eyeballs and selecting an IP address out of the ones available that they *then* reject because they don’t like it: beyond broken, just plain stupid.
Netflix should be using only those IP addresses that it likes (**).

Grüße, Carsten

(*) Well, an ISP that does not offer 128-bit IP *is* a problem, but not the one that led to this thread.

(**) if it needs to deal in address liking at all, which is also fundamentally broken, but seems to be an addiction of their specific industry.

On 9/5/21 06:44, Aaron C. de Bruyn wrote:

>
> Counting all the profit they make from a captive audience with no
> competition? ;)

Well, with no more IPv4 to route and no IPv6 to deliver, those profits
won't be lasting many more years.

Mark.

On 2021-09-04 23:33, Mark Tinka wrote:
> On 9/5/21 04:49, John Levine wrote:
>
>> I have asked my ISP about IPv6 and their answer is that that they're
>> not opposed to
>> it but since I am the only person who has asked for it, it's quite low
>> on the list
>> of things to do.
>
> Supporting the routing and forwarding of IP addresses is just about
> the most basic thing any ISP should do.
>
> If that is low on their to-do list, what else could they possibly be
> doing?


$DAYJOB (at a business SP) is much busier installing more VPNs in the
form of SDWAN than anything IPv6 related. There is a hell of a lot more
customer demand for tools that route packets with finer control than
just dest-based routing, not to mention the security add-ons.

The fact that folks can achieve multi-homed Internet connectivity
without the financial burden of a /24 helps SDWAN's case. Turns out Mom
and Pop, and even John Q. down the street, wants fast failover in case
of circuit trouble just like the big boys.

That said, I do hear prospects and customers asking for IPv6 more often
now than a year ago. But it's nowhere near the popularity of SDWAN:
It's gone from maybe 2-4 requests per year in 2019 to 2-4 requests per
quarter today.

Sorry, the market *still* doesn't care much about IPv6. Believe me, I
hope people will continue getting interested, but I'm done holding my
breath.

Maybe we should collectively focus instead on raising the default MTU
for the Internet to 2000 bytes to accommodate all these tunnels. ;)


> Mark.


-Brian

On 9/5/21 12:48 AM, Carsten Bormann wrote:
> There we get to the heart of things.
>
> The problem is not with IPv6 or your ISP (*), but with the Netflix software.

Hum....

> Doing happy eyeballs and selecting an IP address out of the ones
> available that they *then* reject because they don’t like it:
> beyond broken, just plain stupid.

I feel like that might be conflating a couple of things; the selection
of $SERVICE's destination IP address, and the $CLIENT's inherent source
is coming from.

The $SERVICE can choose any number of destination IP addresses. The
$CLIENT only has minimal control over which protocol is used; IPv4 or IPv6.

I do feel like the $SERVICE could rely on something a bit more
intelligent than DNS such that they make a more informed decision based
on the $CLIENT's inherent source address(es).

> Netflix should be using only those IP addresses that it likes (**).

I don't know if it's the case or not, but I believe that simple DNS
based name resolution tends to be largely ignorant of knowledge of the
$CLIENT's IP address. -- Yes, there are some options, but those tend
to take us way off into the weeds.

> (*) Well, an ISP that does not offer 128-bit IP *is* a problem,
> but not the one that led to this thread.

Agreed.

> (**) if it needs to deal in address liking at all, which is also
> fundamentally broken, but seems to be an addiction of their specific
> industry.

First: I like the "seems to be an addition of their specific industry".

Second: I think that there are technological solutions that would
present a better end user experience. E.g. serve a page / redirect that
sends the client to an IPv4 only destination. Or at the very least
provide a more graceful UX that briefly describes the problem instead of
the service falling over leaving the end user -> consumer -> paying
customer holding the ball and wondering what's wrong. In many cases,
the end user -> consumer -> paying customer is quite likely the party
least equipped / ill-equipped to deal with the ""problem. Especially
when the so called problem is really something that the $SERVICE
provider dislikes and is not a real technological problem preventing
communications.



--
Grant. . . .
unix || die

Saku Ytti <saku@ytti.fi> writes:

> I view IPv6 as the biggest mistake of my career and feel responsible
> for this horrible outcome and I do apologise to Internet users for
> it. This dual-stack is the worst possible outcome, and we've been here
> over two decades, increasing cost and reducing service quality. We
> should have performed better, we should have been IPv6 only years ago.

I believe this is slowly sinking in among the technology evangelists and
geeks who managed to drive the half-assed dual-stack transition a decade
or two ago. No one will argue for dual-stack anymore.

So where does that put us in a decade or two? Which protocol is
optional?



Bjørn

* bjorn@mork.no (Bjørn Mork) [Sun 05 Sep 2021, 18:24 CEST]:
>So where does that put us in a decade or two? Which protocol is
>optional?

The one that costs money. You can already see this in mobile networks.


-- Niels.

On 9/5/21 17:43, Brian Knight wrote:

>
> $DAYJOB (at a business SP) is much busier installing more VPNs in the
> form of SDWAN than anything IPv6 related.  There is a hell of a lot
> more customer demand for tools that route packets with finer control
> than just dest-based routing, not to mention the security add-ons.

My question wasn't serious, if you've been around long enough :-).


> Sorry, the market *still* doesn't care much about IPv6.

I doubt it's me (or those who have deployed IPv6) that will be sorry, in
the long run.

Mark.

On 9/5/21 18:22, Bjørn Mork wrote:

> I believe this is slowly sinking in among the technology evangelists and
> geeks who managed to drive the half-assed dual-stack transition a decade
> or two ago. No one will argue for dual-stack anymore.
>
> So where does that put us in a decade or two? Which protocol is
> optional?

You will join the IPv6 train whenever you do.

I don't waste anymore time asking people to deploy it. I'm better off
spending my time drinking wine.

Mark.

Grant Taylor via NANOG <nanog@nanog.org> writes:

> Hi,
>
> Does anyone have any recommendation for a viable IPv6 tunnel broker /
> provider in the U.S.A. /other/ /than/ Hurricane Electric?
>
> I reluctantly just disabled IPv6 on my home network, provided by
> Hurricane Electric, because multiple services my wife uses are objecting
> to H.E.'s IPv6 address space as so called VPN or proxy provider.
> Netflix, HBO Max, Pandora, and other services that I can't remember at
> the moment have all objected to H.E.
>
> Disabling IPv6 feels *SO* *WRONG*! But fighting things; hacking DNS,
> null routing prefixes, firewalling, etc., seems even more wrong.

Well, that's what I used to do back when I didn't have native v6 and ran
into this issue: block v6 at the DNS level. I.e., simply filter out all
AAAA records for offending service providers. Pretty simple to setup on
your home router (it's usually one or a few TLDs per service provider).
It does fail if your clients do DNSSEC validation, but if you do that at
the router (or not at all) it should just work :)

And yeah, it's an ugly hack that really shouldn't be necessary, but I
found it worked quite well back when I used it (a handful of years ago
or so), and it keeps IPv6 active and working for everything else...

Another solution that I've used on occasion is to do your own
tunnelling: find a hosting provider that can provide you a VPS with a v6
prefix and do your own tunnelling to that. This works by virtue of being
"under the radar" of the service providers that do this kind of broken
filtering, providing you can find a VPS provider whose prefixes are not
blacklisted for some other reason (like being non-residential or
something). Works equally well by tunnelling to a friend (or other
trusted third party) who does have native v6 and a prefix that's large
enough to sub-delegate some IP space to you.

-Toke

Hi Toke,

On 9/5/21 3:07 PM, Toke Høiland-Jørgensen via NANOG wrote:
> Well, that's what I used to do back when I didn't have native v6 and
> ran into this issue: block v6 at the DNS level. I.e., simply filter
> out all AAAA records for offending service providers. Pretty simple
> to setup on your home router (it's usually one or a few TLDs per
> service provider).

I agree that it's not hard to disable AAAA resolution for ... obstinate
domains. However, as you say, doing so means breaking DNSSEC more and
more often. Of course it's possible to do that, but it's now a second
thing that's being done per obstinate domain. :-(

I've considered null routing / rejecting IPv6 traffic to prefixes
associated with the obstinate domains, but that's not really a set it
and forget it thing. Especially if ~> when the obstinate domains use
shared hosting thus bring collateral damage into the mix. And yet
another (3rd) hack ~> workaround. :-(

> It does fail if your clients do DNSSEC validation, but if you do that
> at the router (or not at all) it should just work :)

Ya. I've been doing the DNSSEC validation on the LAN local recursive
DNS server for this reason.

> And yeah, it's an ugly hack that really shouldn't be necessary,

Yep. How many ugly hacks does it take before one starts questioning if
said ugly hack(s) is (are) the proper thing to do?

> but I found it worked quite well back when I used it (a handful of
> years ago or so), and it keeps IPv6 active and working for everything
> else...

If you're willing to (break) deal with DNSSEC, yes it does work.

> Another solution that I've used on occasion is to do your own
> tunnelling: find a hosting provider that can provide you a VPS
> with a v6 prefix and do your own tunnelling to that. This works by
> virtue of being "under the radar" of the service providers that do
> this kind of broken filtering, providing you can find a VPS provider
> whose prefixes are not blacklisted for some other reason (like being
> non-residential or something).

The operative phrase being "find a VPS provider whose prefixes are not
blacklisted". :-/

The workaround ~> hack is becoming more and more problematic year after
year.

> Works equally well by tunnelling to a friend (or other trusted third
> party) who does have native v6 and a prefix that's large enough to
> sub-delegate some IP space to you.

I conceptually agree. However, finding a friend with comparable
bandwidth (~1 Gbps) /with/ native IPv6 is ... problematic. It sort of
means that you're into the VPS territory. And now you're back to the
whack-a-mole game of /which/ VPS provider. :-/



--
Grant. . . .
unix || die

On Sun, Sep 05, 2021 at 11:07:22PM +0200, Toke H?iland-J?rgensen via NANOG wrote:
> Another solution that I've used on occasion is to do your own
> tunnelling: find a hosting provider that can provide you a VPS with a v6
> prefix and do your own tunnelling to that. This works by virtue of being
> "under the radar" of the service providers...

The content providers are also _currently_ classifying IPv4 and IPv6 blocks as
cloud hosting, business access, residential access, etc.

You'll have to find a VPS cloud provider that is too low under the
content provider's radar to have been already classified as well.

On Sun, 5 Sept 2021 at 19:22, Bjørn Mork <bjorn@mork.no> wrote:

> So where does that put us in a decade or two? Which protocol is
> optional?

If we don't get regulatory enforcement or voluntary commitments to
sunset IPv4, we are doomed for dual-stack for the foreseeable future
(decades).
I absolutely HATE testing, developing and supporting IPv4+IPv6, more
than doubling my time, adding 3rd stack would actually not increase
cost that much, it's the 1=>2 which is fantastically expensive. And
costs are transferred to customers.
Those who have not done _anything_ with IPv6, have done the right
thing from business POV, they've had lowest cost, least issues and
have had other people pay for the improvements of the stack. And even
today, I see no business sense deploying IPv6.

Now if we'd know, all of our CDN, cloudyshops and tier1 will start
dropping IPV4 at edge in 2040, this would create good business reason
to start developing to IPv6, you'd know you need to have it, and you'd
know you have finite window when you need to support both.
And this is something we should commit to do, and everyone would
benefit from the comment.

--
++ytti

Hello,


> I absolutely HATE testing, developing and supporting IPv4+IPv6, more
> than doubling my time, adding 3rd stack would actually not increase
> cost that much, it's the 1=>2 which is fantastically expensive. And
> costs are transferred to customers.

Dual stack is doubling dev time ? Ok... this is quite strange...
Maybe on testing... but using some standards protocols....?

(...)

> Now if we'd know, all of our CDN, cloudyshops and tier1 will start
> dropping IPV4 at edge in 2040, this would create good business reason
> to start developing to IPv6, you'd know you need to have it, and you'd
> know you have finite window when you need to support both.
> And this is something we should commit to do, and everyone would
> benefit from the comment.

Really, the ONLY thing that make IPv6 hell is the bloody war between
Cogent and HE. Imagine this kind of war with IPv4...
Really guys stop this stupid stuff and make IPv6 Great Again...

Regards,
Xavier

Saku Ytti <saku@ytti.fi> writes:

> I absolutely HATE testing, developing and supporting IPv4+IPv6, more
> than doubling my time, adding 3rd stack would actually not increase
> cost that much, it's the 1=>2 which is fantastically expensive. And
> costs are transferred to customers.

+1

> Those who have not done _anything_ with IPv6, have done the right
> thing from business POV, they've had lowest cost, least issues and
> have had other people pay for the improvements of the stack. And even
> today, I see no business sense deploying IPv6.

The state is not static. The difference is there for any (partially)
new deployment.

Adding new access infrastructure of any sort (Fixed Wireless is the
hype...)? Why would you want to continue being stupid even if you
implemented dual-stack for all your fibre, hfc and dsl customers? You
can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
even if we assume most of the fibre/hfc/dsl value chain is reused.



Bjørn

On Mon, 6 Sept 2021 at 10:20, Bjørn Mork <bjorn@mork.no> wrote:

> Adding new access infrastructure of any sort (Fixed Wireless is the
> hype...)? Why would you want to continue being stupid even if you
> implemented dual-stack for all your fibre, hfc and dsl customers? You
> can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
> even if we assume most of the fibre/hfc/dsl value chain is reused.

Can you? You need to offer IPv4 anyhow and all the complexities
related to that, i.e. some stateful box. Why would I offer in addition
to that IPv6, which is not being requested by anyone. And by anyone I
mean anyone I want as customer, as those who request it, are probably
going to be expensive to support and I need to subsidise those with my
regular customers, so I'd rather not cater to those.



--
++ytti

Saku Ytti <saku@ytti.fi> writes:
> On Mon, 6 Sept 2021 at 10:20, Bjørn Mork <bjorn@mork.no> wrote:
>
>> Adding new access infrastructure of any sort (Fixed Wireless is the
>> hype...)? Why would you want to continue being stupid even if you
>> implemented dual-stack for all your fibre, hfc and dsl customers? You
>> can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
>> even if we assume most of the fibre/hfc/dsl value chain is reused.
>
> Can you? You need to offer IPv4 anyhow and all the complexities
> related to that, i.e. some stateful box. Why would I offer in addition
> to that IPv6, which is not being requested by anyone. And by anyone I
> mean anyone I want as customer, as those who request it, are probably
> going to be expensive to support and I need to subsidise those with my
> regular customers, so I'd rather not cater to those.


Exactly. The existing dual-stack deployments will die out as access
infra-structure is replaced.



Bjørn

All this is resolved using IPv6-only and IPv4aaS, the same way as cellular providers are doing with 464XLAT.

This means you don't need to invest in more IPv4 addressses (at some point you can even transfer some of them to the laggers), you still provide IPv4 service to the edge, but the access is IPv4-ignorant.

Reduced Capex and Opex in general.


?El 6/9/21 9:29, "NANOG en nombre de Saku Ytti" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de saku@ytti.fi> escribió:

On Mon, 6 Sept 2021 at 10:20, Bjørn Mork <bjorn@mork.no> wrote:

> Adding new access infrastructure of any sort (Fixed Wireless is the
> hype...)? Why would you want to continue being stupid even if you
> implemented dual-stack for all your fibre, hfc and dsl customers? You
> can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
> even if we assume most of the fibre/hfc/dsl value chain is reused.

Can you? You need to offer IPv4 anyhow and all the complexities
related to that, i.e. some stateful box. Why would I offer in addition
to that IPv6, which is not being requested by anyone. And by anyone I
mean anyone I want as customer, as those who request it, are probably
going to be expensive to support and I need to subsidise those with my
regular customers, so I'd rather not cater to those.



--
++ytti



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

On Mon, 6 Sept 2021 at 10:48, JORDI PALET MARTINEZ via NANOG
<nanog@nanog.org> wrote:

> Reduced Capex and Opex in general.

Can you show the work?

--
++ytti

It is simple, most of your traffic will use IPv6. Depending on your network/customer base 65-85%.

You need less and less IPv4 addresses in the NAT64, less NAT64 boxes.

Less resources to operate IPv6-only vs dual-stack.

And because the IPv6 traffic is going up more and more with the time, you can keep reducing IPv4 addresses and NAT64 boxes. If you are using boxes that can be used for other functionalities, you even "recover" part of you initial investment.



?El 6/9/21 10:06, "Saku Ytti" <saku@ytti.fi> escribió:

On Mon, 6 Sept 2021 at 10:48, JORDI PALET MARTINEZ via NANOG
<nanog@nanog.org> wrote:

> Reduced Capex and Opex in general.

Can you show the work?

--
++ytti



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Grant Taylor via NANOG <nanog@nanog.org> writes:

> Hi Toke,
>
> On 9/5/21 3:07 PM, Toke Høiland-Jørgensen via NANOG wrote:
>> Well, that's what I used to do back when I didn't have native v6 and
>> ran into this issue: block v6 at the DNS level. I.e., simply filter
>> out all AAAA records for offending service providers. Pretty simple
>> to setup on your home router (it's usually one or a few TLDs per
>> service provider).
>
> I agree that it's not hard to disable AAAA resolution for ... obstinate
> domains. However, as you say, doing so means breaking DNSSEC more and
> more often. Of course it's possible to do that, but it's now a second
> thing that's being done per obstinate domain. :-(
>
> I've considered null routing / rejecting IPv6 traffic to prefixes
> associated with the obstinate domains, but that's not really a set it
> and forget it thing. Especially if ~> when the obstinate domains use
> shared hosting thus bring collateral damage into the mix. And yet
> another (3rd) hack ~> workaround. :-(
>
>> It does fail if your clients do DNSSEC validation, but if you do that
>> at the router (or not at all) it should just work :)
>
> Ya. I've been doing the DNSSEC validation on the LAN local recursive
> DNS server for this reason.

Yup, me too :)

>> And yeah, it's an ugly hack that really shouldn't be necessary,
>
> Yep. How many ugly hacks does it take before one starts questioning if
> said ugly hack(s) is (are) the proper thing to do?

Well, I come from a software background, so in my world the whole thing
is held together by duct tape and string anyway ;)

And while I can agree in principle, the nice thing about hacks is that
you can actually get those to *work*, whereas tilting at windmills to
get providers to do the right thing is much harder. So ideally you could
do both: deploy the hack(s) while waiting to get the proper fix deployed
a decade or two from now...

>> but I found it worked quite well back when I used it (a handful of
>> years ago or so), and it keeps IPv6 active and working for everything
>> else...
>
> If you're willing to (break) deal with DNSSEC, yes it does work.
>
>> Another solution that I've used on occasion is to do your own
>> tunnelling: find a hosting provider that can provide you a VPS
>> with a v6 prefix and do your own tunnelling to that. This works by
>> virtue of being "under the radar" of the service providers that do
>> this kind of broken filtering, providing you can find a VPS provider
>> whose prefixes are not blacklisted for some other reason (like being
>> non-residential or something).
>
> The operative phrase being "find a VPS provider whose prefixes are not
> blacklisted". :-/
>
> The workaround ~> hack is becoming more and more problematic year after
> year.

Yeah, I do realise that that particular workaround probably has (had?)
an expiry date :(

-Toke

JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes:

> All this is resolved using IPv6-only and IPv4aaS, the same way as
> cellular providers are doing with 464XLAT.

Sure, there are a gazillion ways to provde edge access to both IPv4 and
IPv6. You can pick anyone you like. But the extra layers still do not
come for free.

And cellular providers give you a single /64. Not even useful as IPv6
access for anything larger than a single handset. Extending that /64 to
something you can use is non-trivial. How many providers have actually
done that?

And how many end users cared?




Bjørn

JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes:

> It is simple, most of your traffic will use IPv6. Depending on your
> network/customer base 65-85%.
>
> You need less and less IPv4 addresses in the NAT64, less NAT64 boxes.
>
> Less resources to operate IPv6-only vs dual-stack.
>
> And because the IPv6 traffic is going up more and more with the time,
> you can keep reducing IPv4 addresses and NAT64 boxes. If you are using
> boxes that can be used for other functionalities, you even "recover"
> part of you initial investment.

You're assuming that IPv6 is required. There is no reason do do that in
the current Internet. IPv6 is still optional. The number of users who
care about IPv6 access is very close to 0 and dropping.

And as demonstrated in this thread: Even the few who still do care are
not willing to pay extra, or sacrifice anything, for IPv6. They will
run off to your competitor as soon as they discover the price is lower
there. Which it will be since they saved a lot by building and running
an IPv4 only access network.



Bjørn

* bjorn@mork.no (Bjørn Mork) [Mon 06 Sep 2021, 15:08 CEST]:
>And as demonstrated in this thread: Even the few who still do care
>are not willing to pay extra, or sacrifice anything, for IPv6. They
>will run off to your competitor as soon as they discover the price
>is lower there. Which it will be since they saved a lot by building
>and running an IPv4 only access network.

Is that why cable operators are shifting to native IPv6 + CGNAT for
IPv4 instead of following your advice to build only native IPv4?


-- Niels.

Given that, with NAT, IPv4 address space will last forever and
that people still insisting on IPv6 requires NAT, there is no
point to deploy IPv6.

Even for architectural purity, NAT44 can, but NAT46 and NAT64
can't, be improved to have the end to end transparency.

Masataka Ohta

On 9/6/21 5:04 AM, Toke Høiland-Jørgensen via NANOG wrote:
> Well, I come from a software background, so in my world the whole
> thing is held together by duct tape and string anyway ;)

Don't forget bailing wire.

> And while I can agree in principle, the nice thing about hacks is that
> you can actually get those to *work*, whereas tilting at windmills to
> get providers to do the right thing is much harder. So ideally you
> could do both: deploy the hack(s) while waiting to get the proper
> fix deployed a decade or two from now...

Yes, it's usually possible to get one or more hacks to work well enough
to achieve the desired immediate goal -- $NextStreamingService to work
on $SignificantOthersDevice.

But, how much time and effort ins required for each
$NextStreamingService that comes down the pipe and the associated
ill-will of $SignificantOther?

> Yeah, I do realise that that particular workaround probably has (had?)
> an expiry date :(

When is the proper time to give up on hacks and take one, relatively
simple, step backwards to avoid all subsequent time / effort / ill-will?



--
Grant. . . .
unix || die

Users don't care about IP at all.

They just want to make sure that their apps keep working.

If you switch them to IPv6, and they have faster access for IPv6 enables sites and apps (40% faster time to complete HTTP get), and they don't notice that the WAN is IPv6-only, because inside the LANs they still have dual-stack, problem solved.


?El 6/9/21 15:08, "NANOG en nombre de Bjørn Mork" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de bjorn@mork.no> escribió:

JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes:

> It is simple, most of your traffic will use IPv6. Depending on your
> network/customer base 65-85%.
>
> You need less and less IPv4 addresses in the NAT64, less NAT64 boxes.
>
> Less resources to operate IPv6-only vs dual-stack.
>
> And because the IPv6 traffic is going up more and more with the time,
> you can keep reducing IPv4 addresses and NAT64 boxes. If you are using
> boxes that can be used for other functionalities, you even "recover"
> part of you initial investment.

You're assuming that IPv6 is required. There is no reason do do that in
the current Internet. IPv6 is still optional. The number of users who
care about IPv6 access is very close to 0 and dropping.

And as demonstrated in this thread: Even the few who still do care are
not willing to pay extra, or sacrifice anything, for IPv6. They will
run off to your competitor as soon as they discover the price is lower
there. Which it will be since they saved a lot by building and running
an IPv4 only access network.



Bjørn



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

You're confusing things.

The fact that cellular providers, actually cellular equipment vendors, do not implement DHCPv6-PD, doesn't mean that you can't use DHCPv6-PD for assigning IPv6 prefixes using 464XLAT in broadband.

See RFC8585 and RFC8683.


?El 6/9/21 14:56, "NANOG en nombre de Bjørn Mork" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de bjorn@mork.no> escribió:

JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes:

> All this is resolved using IPv6-only and IPv4aaS, the same way as
> cellular providers are doing with 464XLAT.

Sure, there are a gazillion ways to provde edge access to both IPv4 and
IPv6. You can pick anyone you like. But the extra layers still do not
come for free.

And cellular providers give you a single /64. Not even useful as IPv6
access for anything larger than a single handset. Extending that /64 to
something you can use is non-trivial. How many providers have actually
done that?

And how many end users cared?




Bjørn



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

On Mon, Sep 6, 2021 at 2:55 PM Bjørn Mork <bjorn@mork.no> wrote:

> And cellular providers give you a single /64. Not even useful as IPv6
> access for anything larger than a single handset. Extending that /64 to
> something you can use is non-trivial. How many providers have actually
> done that?
>

I am sitting here on a 4G broadband connection provided by the
cellular provider "3". I am using the Huawei B535-232 CPE provided to me by
"3" as part of the contract. My IPv6 configuration, which I
received completely automatic without having to do anything or even know
about it:

Router IPv6: 2a02:aa7:4620:e76b:5a02:3ff:fe04:506
My computer connected through a LAN cable to the
router: 2a02:aa7:4620:e76b:1870:3bef:4272:5
My android cell phone connected via wifi:
2a02:aa7:4620:e76b:d199:f9b2:7103:3a05

As should be obvious the /64 provided extends to something larger than a
single handset here in a completely trivial way. The CPE is simply bridging
the /64 provided.

Yes I would be more happy with a prefix delegation of some size but this
works too. It is still better than the IPv4 which has to go through NAT.

Regards,

Baldur

Grant Taylor via NANOG <nanog@nanog.org> writes:

> On 9/6/21 5:04 AM, Toke Høiland-Jørgensen via NANOG wrote:
>> Well, I come from a software background, so in my world the whole
>> thing is held together by duct tape and string anyway ;)
>
> Don't forget bailing wire.

Heh, true, although I think the baling wire-to-string ratio tends to be
a bit higher in the US than over here in Europe :)

>> And while I can agree in principle, the nice thing about hacks is that
>> you can actually get those to *work*, whereas tilting at windmills to
>> get providers to do the right thing is much harder. So ideally you
>> could do both: deploy the hack(s) while waiting to get the proper
>> fix deployed a decade or two from now...
>
> Yes, it's usually possible to get one or more hacks to work well enough
> to achieve the desired immediate goal -- $NextStreamingService to work
> on $SignificantOthersDevice.
>
> But, how much time and effort ins required for each
> $NextStreamingService that comes down the pipe and the associated
> ill-will of $SignificantOther?
>
>> Yeah, I do realise that that particular workaround probably has (had?)
>> an expiry date :(
>
> When is the proper time to give up on hacks and take one, relatively
> simple, step backwards to avoid all subsequent time / effort /
> ill-will?

Well, this is more a question for the philosophy department I'd say... :)

-Toke

On Mon, Sep 06, 2021 at 08:38:44AM +0200, Xavier Beaudouin via NANOG wrote:
> Hello,
>
>
> > I absolutely HATE testing, developing and supporting IPv4+IPv6, more
> > than doubling my time, adding 3rd stack would actually not increase
> > cost that much, it's the 1=>2 which is fantastically expensive. And
> > costs are transferred to customers.
>
> Dual stack is doubling dev time ? Ok... this is quite strange...

Nope, entirely normal and expected. Coding for one case is very
straightforward:

Do thing
Do other thing
Do this as well

Coding for two cases involves identifying each step which needs to be done
differently for the two cases and coding up the things to be done
differently:

if case1:
Do thing this way
elif case2:
Do same thing this other way
Do other thing the same way regardless
if case1:
Do this as well
elif case2:
Don't do anything

Adding a third case is *usually* not as hard, as you've identified at least
most of the places that need to be done differently for different cases, and
if you're lucky then some of the doings can be the same both ways:

if case1:
Do thing this way
elif case2:
Do same thing this other way
elif case3:
Do same thing in *yet another* way
Do other thing the same way for everyone
if case1 or case3:
Do this as well
elif case2:
Don't do anything

It's not just program control flow either; there's also data structures and
data storage to think of. That can end up being even *more* complicated
than the control flow, especially if you're interoperating with other
systems that need to consume the same data.

For example, in the IPAM software world, imagine you named a field
"ip_address", that contains an IPv4 address, and now you want to add IPv6.
But that database is also used by some other software (that you might not
even control), so you can't just rename it to "ipv4_address" and change all
the references in your code. Do you add "ipv6_address" and hope that
everyone figures out that "ip_address" *means* "ipv4_address"? What about
in the future, when you have the first device that is IPv6-only... what
goes into that "ip_address" field?

- Matt

this amazing thread is so new, fresh, and enlightening. why has no one
brought these facts and ideas up before? just wow!

randy

Regulatory enforcement by whom? Last I knew there wasn’t a world wide Internet regulatory body.



> On Sep 6, 2021, at 2:33 AM, Saku Ytti <saku@ytti.fi> wrote:
>
> ?On Sun, 5 Sept 2021 at 19:22, Bjørn Mork <bjorn@mork.no> wrote:
>
>> So where does that put us in a decade or two? Which protocol is
>> optional?
>
> If we don't get regulatory enforcement or voluntary commitments to
> sunset IPv4, we are doomed for dual-stack for the foreseeable future
> (decades).
> I absolutely HATE testing, developing and supporting IPv4+IPv6, more
> than doubling my time, adding 3rd stack would actually not increase
> cost that much, it's the 1=>2 which is fantastically expensive. And
> costs are transferred to customers.
> Those who have not done _anything_ with IPv6, have done the right
> thing from business POV, they've had lowest cost, least issues and
> have had other people pay for the improvements of the stack. And even
> today, I see no business sense deploying IPv6.
>
> Now if we'd know, all of our CDN, cloudyshops and tier1 will start
> dropping IPV4 at edge in 2040, this would create good business reason
> to start developing to IPv6, you'd know you need to have it, and you'd
> know you have finite window when you need to support both.
> And this is something we should commit to do, and everyone would
> benefit from the comment.
>
> --
> ++ytti

On 9/7/21 02:56, Randy Bush wrote:

> this amazing thread is so new, fresh, and enlightening. why has no one
> brought these facts and ideas up before? just wow!

Have no fear, it will refresh automatically in 2 years, again.

Mark.

> On Sep 6, 2021, at 12:27 AM, Saku Ytti <saku@ytti.fi> wrote:
>
> On Mon, 6 Sept 2021 at 10:20, Bjørn Mork <bjorn@mork.no> wrote:
>
>> Adding new access infrastructure of any sort (Fixed Wireless is the
>> hype...)? Why would you want to continue being stupid even if you
>> implemented dual-stack for all your fibre, hfc and dsl customers? You
>> can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
>> even if we assume most of the fibre/hfc/dsl value chain is reused.
>
> Can you? You need to offer IPv4 anyhow and all the complexities
> related to that, i.e. some stateful box. Why would I offer in addition
> to that IPv6, which is not being requested by anyone. And by anyone I
> mean anyone I want as customer, as those who request it, are probably
> going to be expensive to support and I need to subsidise those with my
> regular customers, so I'd rather not cater to those.

You don’t necessarily have to carry IPv4 across your network with all the
complexities involved in that. You can do IPv4 at the edges with all IPv6
in the middle through a variety of techniques which are relatively trivial
to implement these days.

Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon.

Unfortunately, nobody wants to lead because it comes with certain negative
commercial implications. Perverse incentives remain a problem.

The race is on:

Will we get IPv6 deployed before our similar failures with regard
to climate change (for amusingly similar perverse incentive reasons)
render the planet uninhabitable?

Owen

> On Sep 6, 2021, at 3:55 PM, Matt Palmer <mpalmer@hezmatt.org> wrote:
>
> On Mon, Sep 06, 2021 at 08:38:44AM +0200, Xavier Beaudouin via NANOG wrote:
>> Hello,
>>
>>
>>> I absolutely HATE testing, developing and supporting IPv4+IPv6, more
>>> than doubling my time, adding 3rd stack would actually not increase
>>> cost that much, it's the 1=>2 which is fantastically expensive. And
>>> costs are transferred to customers.
>>
>> Dual stack is doubling dev time ? Ok... this is quite strange...
>
> Nope, entirely normal and expected. Coding for one case is very
> straightforward:
>
> Do thing
> Do other thing
> Do this as well
>
> Coding for two cases involves identifying each step which needs to be done
> differently for the two cases and coding up the things to be done
> differently:
>
> if case1:
> Do thing this way
> elif case2:
> Do same thing this other way
> Do other thing the same way regardless
> if case1:
> Do this as well
> elif case2:
> Don't do anything

Sure, but most of this can be obviated with IPV6_V6ONLY=false.

From that point on, your software doesn’t need to know or care whether the connection is IPv4 or IPv6, everything looks like IPv6.

Owen

On Tue, 7 Sept 2021 at 19:51, Owen DeLong <owen@delong.com> wrote:

> Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon.

Fully agreed, I just don't see the driver. But I can imagine a
different timeline where in 2000 several tier1 signed mutual binding
contracts to drop IPv4 at the edge in 2020. And no one opposed,
because 20 years before was 1980, and 20 years in the future IPv4
wont' anymore be a thing, it's clear due to exponential growth.

And we'd all be enjoying a much simplified stack and lower costs all
around (vendor, us, customers).

Why is this not possible now? Why would we not sign this mutual
agreement for 2040? Otherwise we'll be having this same discussion in
2040.

--
++ytti

On 9/8/21 08:50, Saku Ytti wrote:

> Fully agreed, I just don't see the driver. But I can imagine a
> different timeline where in 2000 several tier1 signed mutual binding
> contracts to drop IPv4 at the edge in 2020. And no one opposed,
> because 20 years before was 1980, and 20 years in the future IPv4
> wont' anymore be a thing, it's clear due to exponential growth.
>
> And we'd all be enjoying a much simplified stack and lower costs all
> around (vendor, us, customers).
>
> Why is this not possible now? Why would we not sign this mutual
> agreement for 2040? Otherwise we'll be having this same discussion in
> 2040.

I do not see why this is not possible now.

In fact, I'd go as far as saying that the proposal should be shortened
from 20 years to 10 years from today. 10 years is not unreasonable.

I'm not sure if there needs to be a separate "cabal" amongst the major
network operators that cover every corner of the world to agree to this,
as I expect more talking here on NANOG than action around this issue.
But I'd be happy to join and support such a cabal, with the backing of
my own management toward making this commitment, at least from an
African standpoint.

I know at least 3 or 4 other operators in Africa that would be willing
to commit to the same, either directly or by proxy with us.

Do we drive this through the IETF, or just have private, multi-lateral
agreements, as major operators?

I'm now just thinking of how we get this idea off the ground, and stop
talking too much.

Mark.

On Wed, 8 Sept 2021 at 10:25, Mark Tinka <mark@tinka.africa> wrote:

> Do we drive this through the IETF, or just have private, multi-lateral
> agreements, as major operators?

I have no idea, I'll ask our VP if we'd entertain such a contract and
if so what type of terms.

I imagine some website documenting who has undersigned. I also
anticipate we'd need an escape clause, like a company could go 'our
commitment will expire if these of our competitors do not commit'.
So we'd have a list of companies customers can pressure to commit in
order to put the contracts in-force.

This may be a naive suggestion, this is not an area I have experience
in. But I'll ask nonetheless.

--
++ytti

>
> I'm not sure if there needs to be a separate "cabal" amongst the major
> network operators that cover every corner of the world to agree to this,
> as I expect more talking here on NANOG than action around this issue.
> But I'd be happy to join and support such a cabal, with the backing of
> my own management toward making this commitment, at least from an
> African standpoint.
>

If the Telecom Infra Project <https://telecominfraproject.com/participants/>
is a good indicator
of what operators can achieve by uniting,
then you're on a good trajectory.

Cheers,

Etienne

On Wed, Sep 8, 2021 at 9:25 AM Mark Tinka <mark@tinka.africa> wrote:

>
>
> On 9/8/21 08:50, Saku Ytti wrote:
>
> > Fully agreed, I just don't see the driver. But I can imagine a
> > different timeline where in 2000 several tier1 signed mutual binding
> > contracts to drop IPv4 at the edge in 2020. And no one opposed,
> > because 20 years before was 1980, and 20 years in the future IPv4
> > wont' anymore be a thing, it's clear due to exponential growth.
> >
> > And we'd all be enjoying a much simplified stack and lower costs all
> > around (vendor, us, customers).
> >
> > Why is this not possible now? Why would we not sign this mutual
> > agreement for 2040? Otherwise we'll be having this same discussion in
> > 2040.
>
> I do not see why this is not possible now.
>
> In fact, I'd go as far as saying that the proposal should be shortened
> from 20 years to 10 years from today. 10 years is not unreasonable.
>
> I'm not sure if there needs to be a separate "cabal" amongst the major
> network operators that cover every corner of the world to agree to this,
> as I expect more talking here on NANOG than action around this issue.
> But I'd be happy to join and support such a cabal, with the backing of
> my own management toward making this commitment, at least from an
> African standpoint.
>
> I know at least 3 or 4 other operators in Africa that would be willing
> to commit to the same, either directly or by proxy with us.
>
> Do we drive this through the IETF, or just have private, multi-lateral
> agreements, as major operators?
>
> I'm now just thinking of how we get this idea off the ground, and stop
> talking too much.
>
> Mark.
>


--
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

On 9/8/21 09:30, Saku Ytti wrote:

> I have no idea, I'll ask our VP if we'd entertain such a contract and
> if so what type of terms.

That would be great!

Consider our side in full support, already, as I usually have positive
outcomes with my management on these sorts of things. SEACOM would be
happy to sign and promote such an accord.


> I imagine some website documenting who has undersigned. I also
> anticipate we'd need an escape clause, like a company could go 'our
> commitment will expire if these of our competitors do not commit'.
> So we'd have a list of companies customers can pressure to commit in
> order to put the contracts in-force.

Yes, agreed. Makes it easier if the world knows where to go to
understand how much support the idea has, and if their provider (or
provider's provider) is part of it or not.


> This may be a naive suggestion, this is not an area I have experience
> in. But I'll ask nonetheless.

So both Workonline and SEACOM made a similar agreement to enable ROV and
drop Invalids on 1st April, 2019, and we made this commitment to the
public via multiple fora.

There was a 3rd major African operator that was originally part of the
accord, but they pulled out at the last minute. That did not prevent us
from going ahead.

So while not as critical as the basic IP protocol that governs our
Internet, not to mention the small sample size, myself and Ben
(Workonline) have a little experience in this area :-). And I can bet
almost all the wine in my house that Ben would support an accord to drop
egde-IPv4 by 2031.

Mark.

On 9/8/21 09:35, Etienne-Victor Depasquale wrote:

>
> If the Telecom Infra Project
> <https://telecominfraproject.com/participants/> is a good indicator
> of what operators can achieve by uniting,
> then you're on a good trajectory.

Without the membership fees, of course :-).

Mark.

>
> Without the membership fees, of course :-).


Membership fees can be painful, that's for sure.
They do have positive aspects, though :)

Cheers,

Etienne

On Wed, Sep 8, 2021 at 9:38 AM Mark Tinka <mark@tinka.africa> wrote:

>
>
> On 9/8/21 09:35, Etienne-Victor Depasquale wrote:
>
>
> If the Telecom Infra Project
> <https://telecominfraproject.com/participants/> is a good indicator
> of what operators can achieve by uniting,
> then you're on a good trajectory.
>
>
> Without the membership fees, of course :-).
>
> Mark.
>


--
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

On 9/8/21 09:40, Etienne-Victor Depasquale wrote:

> Membership fees can be painful, that's for sure.
> They do have positive aspects, though :)

I encourage other operators (especially the "major" ones - but really,
everyone) to seriously consider supporting this idea, and begin to
circulate, within your organizations, whether you can receive purchase
for this initiative internally, so we put this discussion about IPv6 to
bed, in the next 10 years.

Just a simple piece of feedback about basic support back to this list
would help kick things off, I feel.

Mark.

Saku Ytti <saku@ytti.fi> writes:

> On Tue, 7 Sept 2021 at 19:51, Owen DeLong <owen@delong.com> wrote:
>
>> Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon.
>
> Fully agreed, I just don't see the driver. But I can imagine a
> different timeline where in 2000 several tier1 signed mutual binding
> contracts to drop IPv4 at the edge in 2020. And no one opposed,
> because 20 years before was 1980, and 20 years in the future IPv4
> wont' anymore be a thing, it's clear due to exponential growth.
>
> And we'd all be enjoying a much simplified stack and lower costs all
> around (vendor, us, customers).

I started wondering if there are areas where we can disable IPv4 today.

Ideas like Tore documented in RFC 7755 are certainly possible without
any negative effects, and hopefully with reduced costs compared to a
full dual-stack environment. But it is still based on the assumption
that any interface facing the Internet must be dual-stack.

The next thought was SMTP and authoritative DNS servers. Running IPv6
only in a real production environment should be possible as long as you
keep IPv4 on at least one of the servers.

But you don't have to look far before you hit snags like this:
https://www.norid.no/en/om-domenenavn/regelverk-for-no/vedlegg-f/

So although I techincally could run IPv6 only on all but one of the DNS
servers, this would violate current policy. Oddly enough, running IPv4
only on all servers is allowed. Go figure.

> Why is this not possible now? Why would we not sign this mutual
> agreement for 2040? Otherwise we'll be having this same discussion in
> 2040.

Signing such a contract would be pretty stupid from a commercial pov.
The growth isn't exponential anymore. It's linear at best. You can
probably run just fine with an IPv4 only network after 2040. Not so
sure about the IPv6 only network.


Bjørn

On Wed, 8 Sept 2021 at 11:24, Bjørn Mork <bjorn@mork.no> wrote:

> Signing such a contract would be pretty stupid from a commercial pov.
> The growth isn't exponential anymore. It's linear at best. You can
> probably run just fine with an IPv4 only network after 2040. Not so
> sure about the IPv6 only network.

This is probably true for large segment of eyeballs. But stakeholders
like tier1, cdn and cloudyshops have customer demand for ipv4+ipv6. So
they'd all be able to capitalise on ipv4 going away. And if the small,
mid size eyeballs knew ipv4 is going away in 10, 15, 20 years
whichever it is, then they'd of course have to start moving too,
because no upstream.


--
++ytti

On Wed Sep 08, 2021 at 09:49:15AM +0200, Mark Tinka wrote:
> On 9/8/21 09:40, Etienne-Victor Depasquale wrote:
> > I encourage other operators (especially the "major" ones - but really,
> > everyone) to seriously consider supporting this idea, and begin to
> > circulate, within your organizations, whether you can receive purchase
> > for this initiative internally, so we put this discussion about IPv6 to
> > bed, in the next 10 years.
>
> Just a simple piece of feedback about basic support back to this list
> would help kick things off, I feel.

This was discussed as a follow up to World IPv6 day. We'd be 10 years
closer by now if we had done it then.

The sooner we start the sooner we can finish, I was in favour of it then
and remain so.

brandon

> On Sep 8, 2021, at 10:24 AM, Bjørn Mork <bjorn@mork.no> wrote:
> The next thought was SMTP

I assume someone’s tried using MX record precedence to do this? AAAA record references with lower values than A record references, and see what happens? Anyone have any results to share there?

> and authoritative DNS servers.

If all currently-listed NS are dual-stack, I don’t know how much more would be gained by pruning them back to IPv6 only, from an actual-change-in-the-world perspective. Obviously it’s got to happen in the long run, will happen in the long run, and is the right thing to do, but I’m not sure that’s where our short-term tactical effort is going to have the most effect.

If there are currently IPv4-only nameservers, deprecating those, dual-stacking them, or replacing them with IPv6-only is a good move.

> Running IPv6 only in a real production environment should be possible as long as you keep IPv4 on at least one of the servers.

Agreed, and in your internal environment you can go IPv6 only with NAT/gateway at the edge to reach legacy stuff on the outside. That helps get your people used to IPv6-only, and demonstrates the benefits of less configuration, less worrying about IP address availability, etc. If people don’t have a taste of how much easier it is, they don’t have a strong incentive to keep moving forward.

> But you don't have to look far before you hit snags like this:
> https://www.norid.no/en/om-domenenavn/regelverk-for-no/vedlegg-f/

Ugh. Policy from 2018. Has anyone reached out to them to get this fixed? .NO is one of the few ccTLDs we don’t have a relationship with. Looks like they’re using NetNod and Neustar.

-Bill

On 9/8/21 10:49, Brandon Butterworth wrote:

> This was discussed as a follow up to World IPv6 day. We'd be 10 years
> closer by now if we had done it then.
>
> The sooner we start the sooner we can finish, I was in favour of it then
> and remain so.

End of.

Mark.

> On Sep 7, 2021, at 23:50 , Saku Ytti <saku@ytti.fi> wrote:
>
> On Tue, 7 Sept 2021 at 19:51, Owen DeLong <owen@delong.com> wrote:
>
>> Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon.
>
> Fully agreed, I just don't see the driver. But I can imagine a

$$$$$$

IPv4 continues to increase in cost. Surely, there is a point where organizations
start to cry uncle.

Surely there is a point where we move from but you have to do IPv4 anyhow
to but you have to do IPv6 to support most new things because newcomers
don’t want to pay $150/address to get on the legacy network.

(Yeah, I know it’s only $50 today, but it was $10 a few years ago and $30
last year).

> different timeline where in 2000 several tier1 signed mutual binding
> contracts to drop IPv4 at the edge in 2020. And no one opposed,

That would have been nice, but that opportunity was missed. I’m thinking that
the most hope for this to happen realistically is for eyeball providers to start
charging extra to provide IPv4AAS to their customers that need it. I think
an announcement from one or two of the major ones would serve as an
extreme motivation for the lagging content providers (Are you listening here
Amazon? Skype? Google Cloud? AWS? (global load balancing)) to get their
shit together. Once they do, there’s really not much “you have to support
IPv4 anyway” left, then the eyeballs can shut it off for customers that don’t
pay extra and voila… Little incentive remains to continue maintaining
IPv4 infrastructure.

> because 20 years before was 1980, and 20 years in the future IPv4
> wont' anymore be a thing, it's clear due to exponential growth.
>
> And we'd all be enjoying a much simplified stack and lower costs all
> around (vendor, us, customers).

Yep.

> Why is this not possible now? Why would we not sign this mutual
> agreement for 2040? Otherwise we'll be having this same discussion in
> 2040.

Because markets (and people) are bad at transition and we live in a world of markets
and perverse incentives. It’s part of the reason climate change is so hard to address
also.

Owen

> On Sep 8, 2021, at 00:49 , Mark Tinka <mark@tinka.africa> wrote:
>
>
>
> On 9/8/21 09:40, Etienne-Victor Depasquale wrote:
>
>> Membership fees can be painful, that's for sure.
>> They do have positive aspects, though :)
>
> I encourage other operators (especially the "major" ones - but really, everyone) to seriously consider supporting this idea, and begin to circulate, within your organizations, whether you can receive purchase for this initiative internally, so we put this discussion about IPv6 to bed, in the next 10 years.
>
> Just a simple piece of feedback about basic support back to this list would help kick things off, I feel.
>
> Mark.

I think the tipping point would be to get the major eyeball providers on board. If you can get them to agree (even if they just agree to surcharge IPv4 support by that time or even in 5 years), that will serve as a really strong forcing function for the content providers.

Comcast is well positioned to be able to do this, many of their customers have no viable alternative anyway, so not like they lose business almost no matter what they do. (They’ve proven this repeatedly). They’ve also already got full or nearly full IPv6 enablement for all of their customers (albeit it with ridiculously small prefixes for most of them).

The reality is that if we get content dual-stacked and stop requiring IPv4 for new eyeball installations, that’s the biggest initial win.

Owen

> But you don't have to look far before you hit snags like this:
> https://www.norid.no/en/om-domenenavn/regelverk-for-no/vedlegg-f/

I just sent the following to them:

I’m writing about your name server requirements page:

https://www.norid.no/en/om-domenenavn/regelverk-for-no/vedlegg-f/

I think that requirement 4:

Accessible name servers
Name servers must be permanently connected to the Internet, and must have a permanently assigned (fixed) IPv4 address. The name servers may also have an IPv6 address, and this too must be permanently assigned as required for the IPv4 address. The name servers must be connected to a stable and reliable infrastructure.

is somewhat out of date relevant to current best internet practices…

At the very least, IPv6 should no longer be options.

Ideally, IPv4 should be optional.

Suggest you send something similar.

Owen

* Owen DeLong via NANOG [Wed 08 Sep 2021, 20:35 CEST]:
>IPv4 continues to increase in cost. Surely, there is a point where
>organizations start to cry uncle.

In most western countries there isn't much growth in the total number
of connections. It's mostly churn between providers. IPv4 addresses
aren't wasted once a customer leaves (unlike for mobile numbers there
is no mandated number portability for IP addresses), they can be
reused for the next customer, they don't deteriorate when kept in
stock, and they can likely be sold for more, later, eventually.

(As long as you buy, not rent, that is, and LIR fees don't
significantly increase.)


-- Niels.

> On Sep 8, 2021, at 11:57 , Niels Bakker <niels=nanog@bakker.net> wrote:
>
> * Owen DeLong via NANOG [Wed 08 Sep 2021, 20:35 CEST]:
>> IPv4 continues to increase in cost. Surely, there is a point where organizations start to cry uncle.
>
> In most western countries there isn't much growth in the total number of connections. It's mostly churn between providers. IPv4 addresses aren't wasted once a customer leaves (unlike for mobile numbers there is no mandated number portability for IP addresses), they can be reused for the next customer, they don't deteriorate when kept in stock, and they can likely be sold for more, later, eventually.
>
> (As long as you buy, not rent, that is, and LIR fees don't significantly increase.)
>
>
> -- Niels.

The addresses aren’t the major cost of providing IPv4 services.

CGN boxes, support calls, increasing size of routing table = buying new routers, etc.

Increased cost of developers having to work around NAT and NAT becoming ever more complex with multiple layers, etc.

All of these are the things driving the ever increasing cost of IPv4 services, not just the cost of the addresses.

Owen

It appears that Bill Woodcock <woody@pch.net> said:
>> The next thought was SMTP
>
>I assume someone’s tried using MX record precedence to do this? AAAA record references with lower values than A record references,
>and see what happens? Anyone have any results to share there?

I used to publish two MX records at the same precedence, one with an A record
and one with an AAAA record. It didn't work very well because some v4 only
systems decided that an MX without an A record meant my mail system was
broken. Now I have one MX with both which works OK.

Postfix has some parameters to say whether to prefer v4 or v6 at the same
priority. Wietse says don't prefer v6, you'll lose mail.

R's,
John

On Wed, 08 Sep 2021 11:39:50 -0700, Owen DeLong via NANOG said:

> The reality is that if we get content dual-stacked and stop requiring IPv4
> for new eyeball installations, that’s the biggest initial win.

The problem is "get content dual-stacked".

Somebody made this handy page of the IPv6 status for the Alexa Top 500.

http://www.delong.com/ipv6_alexa500.html

Awful lot of red spots even in the top 100. Hell, even amazon.com
isn't IPv6 yet. And the long tail is going to be the death of a thousand
cuts for the call center unless you have a way to deal with those sites.

And the devil is in the details. cnn.com itself has a quad-A. But looking
at Chrome loading it with the IPvFoo extension, I see that of the 145
addresses it hits, only 38 are IPv6, the rest are IPv4.

On the other hand, looking at *who* are the IPv4, they seem to be
overwhelmingly ad servers and analytics sites - so maybe hitting cnn.com as
IPv6-only is a win for the consumer. I rather suspect that the CFO of CNN
would see it differently though....

(Eerily reminiscent of the factoid that 60% of the cost of a long distance
phone call before the AT&T breakup was keeping the accounting records
so they could bill the customer)

> On Sep 8, 2021, at 18:55 , Valdis Kl?tnieks <valdis.kletnieks@vt.edu> wrote:
>
> On Wed, 08 Sep 2021 11:39:50 -0700, Owen DeLong via NANOG said:
>
>> The reality is that if we get content dual-stacked and stop requiring IPv4
>> for new eyeball installations, that’s the biggest initial win.
>
> The problem is "get content dual-stacked".
>
> Somebody made this handy page of the IPv6 status for the Alexa Top 500.
>
> http://www.delong.com/ipv6_alexa500.html
>
> Awful lot of red spots even in the top 100. Hell, even amazon.com
> isn't IPv6 yet. And the long tail is going to be the death of a thousand
> cuts for the call center unless you have a way to deal with those sites.

This is my point… That is why I think an announcement of “On X date,
we will begin charging extra for IPv4 services and define Internet Access
to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
big fire under those laggards.

Think about it… Amazon doesn’t want to lose access to Comcast, T-Mobile,
Verizon Wireless, and/or AT&T eyeballs any more than those ISPs want
to deal with the call center consequences if they turn off IPv4 before those
content providers are ready.

If they put that date, say, 5 years out, perhaps January 15, 2027 for
example, so that it doesn’t happen during the retail cash cow season,
I suspect it would drive that long tail to shorten. Right now, it’s costing
Amazon (amazon.com, not AWS) nothing to ignore IPv6 and continue
lagging, they’re able to externalize all of those costs onto the eyeball ISPs.

> And the devil is in the details. cnn.com itself has a quad-A. But looking
> at Chrome loading it with the IPvFoo extension, I see that of the 145
> addresses it hits, only 38 are IPv6, the rest are IPv4.

You don’t think they’d be motivated by a drop-dead date agreed upon
by the eyeball ISPs? I think they would.

> On the other hand, looking at *who* are the IPv4, they seem to be
> overwhelmingly ad servers and analytics sites - so maybe hitting cnn.com as
> IPv6-only is a win for the consumer. I rather suspect that the CFO of CNN
> would see it differently though....

I rather suspect that an announcement of a drop-dead date 5 years out by
a select group of major eyeball providers would get the situation corrected
likely well short of 5 years.

> (Eerily reminiscent of the factoid that 60% of the cost of a long distance
> phone call before the AT&T breakup was keeping the accounting records
> so they could bill the customer)

Yes… IIRC, After the breakup, that jumped to more like 80% until things finally
got to the point that everyone recognized that eliminating the billing records
for such things saved tons of money.

Owen

Owen DeLong via NANOG wrote:

>>> The reality is that if we get content dual-stacked and stop requiring IPv4
>>> for new eyeball installations, that$B!G(Bs the biggest initial win.

> This is my point$B!D(B That is why I think an announcement of $B!H(BOn X date,
> we will begin charging extra for IPv4 services and define Internet Access
> to be IPv6$B!I(B by a couple of the larger eyeball ISPs would light a pretty
> big fire under those laggards.

Aren't you calling your desire "the reality"?

Masataka Ohta

Owen DeLong via NANOG <nanog@nanog.org> writes:

> This is my point… That is why I think an announcement of “On X date,
> we will begin charging extra for IPv4 services and define Internet Access
> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
> big fire under those laggards.
>
> Think about it… Amazon doesn’t want to lose access to Comcast, T-Mobile,
> Verizon Wireless, and/or AT&T eyeballs any more than those ISPs want
> to deal with the call center consequences if they turn off IPv4 before those
> content providers are ready.

By all means, let's just escalate the peering wars between eyeball
networks and content providers. That will solve all our problems.



Bjørn

Owen DeLong via NANOG <nanog@nanog.org> writes:

> The addresses aren’t the major cost of providing IPv4 services.
>
> CGN boxes, support calls, increasing size of routing table = buying new routers, etc.

You're counting dual-stack costs as if IPv4 was the optional protocol.
That's a fantasy world. Time to get out of la-la land now.

Your edge routers can do CGN for all connected users just fine. Yes,
there is still a cost both in resources and management, but you'll have
to weigh that against the cost of doing dual-stack on the same box. I'm
not convinced dual-stack wins.

Don't know what you're thinking of wrt support calls, but dual-stack has
some failure modes which are difficult to understand for both end users
and support. NAT is pretty well understood in comparison.

Your routing tables won't grow with IPv4 or CGN. They grow when you add
IPv6.

> Increased cost of developers having to work around NAT and NAT
> becoming ever more complex with multiple layers, etc.

And this can be avoided by reconfiguring the local network somehow? Or
are we talking about an Internet without IPv4? This is even more
fantastic than the idea that IPv4 is optional in the local network.

> All of these are the things driving the ever increasing cost of IPv4
> services, not just the cost of the addresses.

Yes, the cost of addresses is not prohibitive, and there is no
indication it will be.

The consolidation of hosting services have reduced the need for globally
routable addresses. You don't host your own mail server and web server
anymore, even if you're a large organisation. Most ISPs haven't yet
taken advantage of this. They are still giving globally routable IPv4
addresses to customers which have no need for that. These addresses can
be re-allocated for CGN if there is a need. This is obviously still not
free, but it does limit the price of fresh IPv4 addresses.

The other costs you list will not affect an IPv4 only shop at all.


Bjørn

> On 10 Sep 2021, at 17:21, Bjørn Mork <bjorn@mork.no> wrote:
>
> Owen DeLong via NANOG <nanog@nanog.org> writes:
>
>> The addresses aren’t the major cost of providing IPv4 services.
>>
>> CGN boxes, support calls, increasing size of routing table = buying new routers, etc.
>
> You're counting dual-stack costs as if IPv4 was the optional protocol.
> That's a fantasy world. Time to get out of la-la land now.
>
> Your edge routers can do CGN for all connected users just fine. Yes,
> there is still a cost both in resources and management, but you'll have
> to weigh that against the cost of doing dual-stack on the same box. I'm
> not convinced dual-stack wins.
>
> Don't know what you're thinking of wrt support calls, but dual-stack has
> some failure modes which are difficult to understand for both end users
> and support. NAT is pretty well understood in comparison.
>
> Your routing tables won't grow with IPv4 or CGN. They grow when you add
> IPv6.
>
>> Increased cost of developers having to work around NAT and NAT
>> becoming ever more complex with multiple layers, etc.
>
> And this can be avoided by reconfiguring the local network somehow? Or
> are we talking about an Internet without IPv4? This is even more
> fantastic than the idea that IPv4 is optional in the local network.
>
>> All of these are the things driving the ever increasing cost of IPv4
>> services, not just the cost of the addresses.
>
> Yes, the cost of addresses is not prohibitive, and there is no
> indication it will be.
>
> The consolidation of hosting services have reduced the need for globally
> routable addresses. You don't host your own mail server and web server
> anymore, even if you're a large organisation. Most ISPs haven't yet
> taken advantage of this. They are still giving globally routable IPv4
> addresses to customers which have no need for that. These addresses can
> be re-allocated for CGN if there is a need. This is obviously still not
> free, but it does limit the price of fresh IPv4 addresses.
>
> The other costs you list will not affect an IPv4 only shop at all.
>
>
> Bjørn

Or you could deliver IPv6-only to your customers and used to CGN boxes
to deliver IPv4AAS using less than 1/2 the IPv4 address space you need
for a NAT444 solution as +60% of your traffic doesn’t need CGN processing.

464XLAT example

{ Internet IPv4(40% of traffic) + IPv6(60% of traffic) } - [Router w/ NAT64] - { IPv6-only (IPv4 traffic has been translated to IPv6) } - [CPE w/ CLAT] { home network IPv4 + IPv6 }

DS-Lite

{ Internet IPv4(40% of traffic) + IPv6(60% of traffic) } - [Router w/ AFTR] - { IPv6-only (IPv4 traffic has been encapsulated in IPv6) } - [CPE w/ B4] { home network IPv4 + IPv6 }

MAP-T and MAP-E are similar to 464XLAT and DS-Lite respectively.

Yes, you have to learn something new but it costs less that a “pure" IPv4
service.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

> On 20210909, at 21:55, Owen DeLong via NANOG <nanog@nanog.org> wrote:
>> [..]
>> Awful lot of red spots even in the top 100. Hell, even amazon.com
>> isn't IPv6 yet. And the long tail is going to be the death of a thousand
>> cuts for the call center unless you have a way to deal with those sites.
>
> This is my point… That is why I think an announcement of “On X date,
> we will begin charging extra for IPv4 services and define Internet Access
> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
> big fire under those laggards.

You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ?

yes, a /24 was 0 setup, now now close to 5000 of currency.... and the monthly fee also doubled.
Noting that 20 for an IPv4 IP is effectively quite cheap with current prices going towards 50+...

There are thus already a few places that are doing the squish....

Greets,
Jeroen

> On Sep 10, 2021, at 01:39 , Jeroen Massar <jeroen@massar.ch> wrote:
>
>
>
>> On 20210909, at 21:55, Owen DeLong via NANOG <nanog@nanog.org> wrote:
>>> [..]
>>> Awful lot of red spots even in the top 100. Hell, even amazon.com
>>> isn't IPv6 yet. And the long tail is going to be the death of a thousand
>>> cuts for the call center unless you have a way to deal with those sites.
>>
>> This is my point… That is why I think an announcement of “On X date,
>> we will begin charging extra for IPv4 services and define Internet Access
>> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
>> big fire under those laggards.
>
> You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ?
>
> yes, a /24 was 0 setup, now now close to 5000 of currency.... and the monthly fee also doubled.
> Noting that 20 for an IPv4 IP is effectively quite cheap with current prices going towards 50+...
>
> There are thus already a few places that are doing the squish....
>
> Greets,
> Jeroen
>

Yes, but it needs to come from a major eyeball ISP to be the motivating
factor that we need here. A minor virtual server host isn’t going to do it.

Owen

It appears that Owen DeLong via NANOG <owen@delong.com> said:
>This is my point… That is why I think an announcement of “On X date,
>we will begin charging extra for IPv4 services and define Internet Access
>to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
>big fire under those laggards.

Indeed. They would send postcards to all their customers saying
"Comcast has said they will cut off your access to Netflix on April 1,
Call their president's office at 1-800-xxx-xxxx and tell them what you think."

Great move.

R's,
John

On 2021-09-10 18:27, Owen DeLong wrote:
>
>
>> On Sep 10, 2021, at 01:39 , Jeroen Massar <jeroen@massar.ch> wrote:
>>
>>
>>
>>> On 20210909, at 21:55, Owen DeLong via NANOG <nanog@nanog.org> wrote:
>>>> [..]
>>>> Awful lot of red spots even in the top 100. Hell, even amazon.com
>>>> isn't IPv6 yet. And the long tail is going to be the death of a thousand
>>>> cuts for the call center unless you have a way to deal with those sites.
>>>
>>> This is my point… That is why I think an announcement of “On X date,
>>> we will begin charging extra for IPv4 services and define Internet Access
>>> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
>>> big fire under those laggards.
>>
>> You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ?
>>
>> yes, a /24 was 0 setup, now now close to 5000 of currency.... and the monthly fee also doubled.
>> Noting that 20 for an IPv4 IP is effectively quite cheap with current prices going towards 50+...
>>
>> There are thus already a few places that are doing the squish....
>>
>> Greets,
>> Jeroen
>>
>
> Yes, but it needs to come from a major eyeball ISP to be the motivating
> factor that we need here. A minor virtual server host isn’t going to do it.

"minor virtual server host". I think you are underestimating things...

https://bgp.he.net/AS24940 + AS213230

That is not a toy network... but hey, I guess 'everything is bigger' on
the other side of the big old lake eh.

I am sure, considering the news and rumors, that that pricing change
made, that it made an impact at a lot of companies, that things are
changing, and that is a win for IPv6...

But hey, YMMV.

Greets,
Jeroen

> On Sep 10, 2021, at 13:22 , John Levine <johnl@iecc.com> wrote:
>
> It appears that Owen DeLong via NANOG <owen@delong.com> said:
>> This is my point… That is why I think an announcement of “On X date,
>> we will begin charging extra for IPv4 services and define Internet Access
>> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
>> big fire under those laggards.
>
> Indeed. They would send postcards to all their customers saying
> "Comcast has said they will cut off your access to Netflix on April 1,
> Call their president's office at 1-800-xxx-xxxx and tell them what you think."

Nope… Netflix is fully available on IPv6 and actually looks forward to ISPs
doing this.

Now Amazon might send post cards saying “Comcast has said that they
will cut off your access to our store…”, but I suspect that the cost of such
a campaign and the collateral damage would be well in excess of the
cost of just adding IPv6 to their service.

Owen

> On Sep 10, 2021, at 14:17 , Jeroen Massar <jeroen@massar.ch> wrote:
>
> On 2021-09-10 18:27, Owen DeLong wrote:
>>> On Sep 10, 2021, at 01:39 , Jeroen Massar <jeroen@massar.ch> wrote:
>>>
>>>
>>>
>>>> On 20210909, at 21:55, Owen DeLong via NANOG <nanog@nanog.org> wrote:
>>>>> [..]
>>>>> Awful lot of red spots even in the top 100. Hell, even amazon.com
>>>>> isn't IPv6 yet. And the long tail is going to be the death of a thousand
>>>>> cuts for the call center unless you have a way to deal with those sites.
>>>>
>>>> This is my point… That is why I think an announcement of “On X date,
>>>> we will begin charging extra for IPv4 services and define Internet Access
>>>> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
>>>> big fire under those laggards.
>>>
>>> You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ?
>>>
>>> yes, a /24 was 0 setup, now now close to 5000 of currency.... and the monthly fee also doubled.
>>> Noting that 20 for an IPv4 IP is effectively quite cheap with current prices going towards 50+...
>>>
>>> There are thus already a few places that are doing the squish....
>>>
>>> Greets,
>>> Jeroen
>>>
>> Yes, but it needs to come from a major eyeball ISP to be the motivating
>> factor that we need here. A minor virtual server host isn’t going to do it.
>
> "minor virtual server host". I think you are underestimating things...
>
> https://bgp.he.net/AS24940 + AS213230
>
> That is not a toy network... but hey, I guess 'everything is bigger' on the other side of the big old lake eh.

Not everything, but compare to (e.g. 15169, 16509).

Also, the key here is more that we need large eyeballs, such as 7922, 21928, 6167, 6298, etc.).

I wasn’t meaning to disparage Hetzner in any way, but they’re a cloud host, not an eyeball provider. While they’re not a toy network, I also wouldn’t call them a major cloud provider in the same league with (e.g. AWS, Azure, Google Cloud).

> I am sure, considering the news and rumors, that that pricing change made, that it made an impact at a lot of companies, that things are changing, and that is a win for IPv6...

Agreed… I’m glad to see what they’ve done, but I’m advocating for someone like Comcast to follow suit in hopes that it will drive other large content providers to make the move.

Owen

>> Indeed. They would send postcards to all their customers saying
>> "Comcast has said they will cut off your access to Netflix on April 1,
>> Call their president's office at 1-800-xxx-xxxx and tell them what you think."
>
> Nope… Netflix is fully available on IPv6 and actually looks forward to ISPs
> doing this.

OK, then Disney+ or Hulu or whoever. Peering wars never end well. Don't
even need postcards, just stick the flyer in with the bill.

> Now Amazon might send post cards saying “Comcast has said that they
> will cut off your access to our store…”, but I suspect that the cost of such
> a campaign and the collateral damage would be well in excess of the
> cost of just adding IPv6 to their service.

AWS has perfectly good support for IPv6 so they must have business reasons
to stick with v4. But I expect the cost of putting up banners on the
homepage saying to call your ISP, for people coming through the relevant
ISP, would be pretty cheap, and Amazon's customers appear to like their
accounts and their Prime quite a lot. Again, peering wars never end well.

This ignores the question of what the advantage to the ISP would be other
than bloody-mindedness. The world is not going to abandon IPv4 any time
soon and the last time I looked, the cost of routing packets is the same
regardless of which header they have.

Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

> On Sep 8, 2021, at 1:26 AM, Bjørn Mork <bjorn@mork.no> wrote:
>
>
> I started wondering if there are areas where we can disable IPv4 today.

There are places in which it is disabled today, for at least some services.

Sent using a machine that autocorrects in interesting ways...

> On Sep 8, 2021, at 1:31 AM, Saku Ytti <saku@ytti.fi> wrote:
>
> If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years
> whichever it is, then they'd of course have to start moving too,
> because no upstream.

And they would fight it tooth and nail, just like they do now, and if they found an address they could NAT to, they would argue that that one address gave them the ability to avoid the transition -just like they do now.

> On Sep 11, 2021, at 9:04 PM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
>
>
> Sent using a machine that autocorrects in interesting ways...
>
>> On Sep 8, 2021, at 1:31 AM, Saku Ytti <saku@ytti.fi> wrote:
>>
>> If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years
>> whichever it is, then they'd of course have to start moving too,
>> because no upstream.
>
> And they would fight it tooth and nail, just like they do now, and if they found an address they could NAT to, they would argue that that one address gave them the ability to avoid the transition -just like they do now.

Speaking for the smaller providers, there is enough of the Internet that is only accessible via IPv4 out there that CGN solutions are a reasonable way to manage the situation. There is also enough legacy equipment out there that doesn’t accommodate IPv6 that this process will still take several decades.

Edicts never work. More carrot, less stick.

>> If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years
>> whichever it is, then they'd of course have to start moving too,
>> because no upstream.
>
> And they would fight it tooth and nail, just like they do now

you speak as if it was religion or they are bad people. neither is the
case. it is what they see as their best business interest.

being from the pacific northwest, i have learned not to try to push
water uphill. so, until we can tilt the hill, it's probably bast for
one's health if one gets over it.

randy

> Edicts never work. More carrot, less stick.

but the ipv6 stick has worked so well over the last 25 years

> On Sep 12, 2021, at 11:35 , Brian Johnson <brian.johnson@netgeek.us> wrote:
>
>
>
>> On Sep 11, 2021, at 9:04 PM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
>>
>>
>> Sent using a machine that autocorrects in interesting ways...
>>
>>> On Sep 8, 2021, at 1:31 AM, Saku Ytti <saku@ytti.fi> wrote:
>>>
>>> If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years
>>> whichever it is, then they'd of course have to start moving too,
>>> because no upstream.
>>
>> And they would fight it tooth and nail, just like they do now, and if they found an address they could NAT to, they would argue that that one address gave them the ability to avoid the transition -just like they do now.
>
> Speaking for the smaller providers, there is enough of the Internet that is only accessible via IPv4 out there that CGN solutions are a reasonable way to manage the situation. There is also enough legacy equipment out there that doesn’t accommodate IPv6 that this process will still take several decades.
>
> Edicts never work. More carrot, less stick.

They did with ATSC.

Owen

On 9/12/21 1:08 PM, Randy Bush wrote:
>>> If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years
>>> whichever it is, then they'd of course have to start moving too,
>>> because no upstream.
>> And they would fight it tooth and nail, just like they do now
> you speak as if it was religion or they are bad people. neither is the
> case. it is what they see as their best business interest.
>
> being from the pacific northwest, i have learned not to try to push
> water uphill. so, until we can tilt the hill, it's probably bast for
> one's health if one gets over it.
>
If vendors actually cared they could make the CGNAT's and other hacks
ridiculously buggy and really expensive to deploy and maintain. I doubt
many vendors were chomping at the bit to support CGNAT and are probably
wondering what fresh hell is next to keep ipv4 limping along.

Mike

> I doubt many vendors were chomping at the bit to support CGNAT

definitely. they hate to sell big expensive boxes.

randy

On 9/12/21 4:59 PM, Randy Bush wrote:
>> I doubt many vendors were chomping at the bit to support CGNAT
> definitely. they hate to sell big expensive boxes.

Back in the early 2000's the first rumblings of what would eventually
turn into CGN started popping up at Cablelabs. I went to the EVP of
Service Provider and basically told him that he had a choice between
that mess or developing ipv6. I doubt he was interested in doing
anything at all, but he chose ipv6, at least in the abstract. Steve
Deering and I then went around to all of the BU's trying to figure out
what it would take for them to implement ipv6 in the routing plane.
Cablelabs was also pretty ipv6-focused too making a similar calculation.

So no, they weren't interested in it either. They were completely driven
by what the providers wanted and what a large group of providers have
since made pretty clear is that horrible hacks are fine by them if it
gets them out of a short term bind. But it's hardly uniform across the
industry. This is a classic reverse-tragedy of the commons.

Mike

On 9/13/21 01:00, Michael Thomas wrote:

>
> If vendors actually cared they could make the CGNAT's and other hacks
> ridiculously buggy and really expensive to deploy and maintain. I
> doubt many vendors were chomping at the bit to support CGNAT and are
> probably wondering what fresh hell is next to keep ipv4 limping along.
>

10's of millions of dollars being spent by African mobile operators,
every year, in CG-NAT hardware and licenses, with the vendors.

They will make sure that code is bug-free :-).

Mark.

On 9/13/21 02:16, Michael Thomas wrote:

>
> But it's hardly uniform across the industry. This is a classic
> reverse-tragedy of the commons.

The problem is it's uniform in the corners that contain scale and the
money to make a difference at vendor-land.

7 million mom & pop ISP's vs. 10 large mobile operators... yeah, $vendor
will struggle to make that decision :-).

Mark.

> On Sep 13, 2021, at 05:17 , Mark Tinka <mark@tinka.africa> wrote:
>
>
>
> On 9/13/21 01:00, Michael Thomas wrote:
>
>>
>> If vendors actually cared they could make the CGNAT's and other hacks ridiculously buggy and really expensive to deploy and maintain. I doubt many vendors were chomping at the bit to support CGNAT and are probably wondering what fresh hell is next to keep ipv4 limping along.
>>
>
> 10's of millions of dollars being spent by African mobile operators, every year, in CG-NAT hardware and licenses, with the vendors.
>
> They will make sure that code is bug-free :-).

ROFLMAO

100s of millions of dollars are spent every year on major backbone router kit. That code has never been bug free.

Your assertion is provably false.

Owen

< rant >

ipv6 was designed at a time where the internet futurists/idealists had
disdain for operators and vendors, and thought we were evil money
grabbers who had to be brought under control.

the specs as originally RFCed by the ietf is very telling. for your
amusement, take a look at rfc 2450. it took five years of war to get
rid of the tla/sla crap. and look at the /64 religion today[0].

real compatibility with ipv4 was disdained. the transition plan was
dual stack and v4 would go away in a handful of years. the 93
transition mechanisms were desperate add-ons when v4 did not go away.
and dual stack does not scale, as it requires v4 space proportional to
deployed v6 space.

we are left to make the mess work for the users, while being excoriated
for not doing it quickly or well enough, and for trying to make ends
meet financially.

randy, trying to deal with the mess since the early '90s

---

[0] https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-05

Randy Bush wrote on 13/09/2021 19:22:
> the specs as originally RFCed by the ietf is very telling. for your
> amusement, take a look at rfc 2450. it took five years of war to get
> rid of the tla/sla crap. and look at the /64 religion today[0].

architectural decisions were made because of a mixture of actual and
perceived problems at the time, but several of the outcomes make little
sense now or in some cases, actively cause problems. E.g. using mcast
for address resolution because large flat l2 networks were the order of
the day, that "privacy addresses" would give privacy, that client
self-selected addresses should be the only game in town for
auto-addressing (it took years to get any form of dhcp through), that
extension headers were a great idea, that "transition mechanisms" would
be viable for fundamentally incompatible protocols, etc. That said,
it's easy to be critical of design decisions with 25y of hindsight, and
even easier to understate how difficult it is to dislodge ipv4 which
took 40 years of evolution to cement itself into its current position.

Nick

> it's easy to be critical of design decisions with 25y of hindsight

there was a good number of senior implementors and ops who screamed
loudly at the time. to no avail.

randy

On Mon, Sep 13, 2021 at 8:22 PM Randy Bush <randy@psg.com> wrote:

> real compatibility with ipv4 was disdained. the transition plan was
> dual stack and v4 would go away in a handful of years. the 93
> transition mechanisms were desperate add-ons when v4 did not go away.
> and dual stack does not scale, as it requires v4 space proportional to
> deployed v6 space.
>

What I find most peculiar about this whole rant (not just yours but the
whole thread) is that I may be the only one who found implementing IPv6
with dual stack completely trivial and a non issue? There is no scale issue
nor any of the other rubbish.

Some say what we have is not a true dual stack setup because we run MPLS
and the IPv6 mostly lives inside L2VPN or L3VPN tunnels. Most of our
network gear has no idea what an IPv6 address is. But neither does that
equipment touch the public IPv4 internet. Nevertheless we configure our
IPv4 and IPv6 both only on our few edge Juniper MX devices and that is it.
I do not believe IPv6 has 100 config lines in my network total.

For all I care we already have a perfect working system with IPv4+CGN+IPv6.
The CGN part was the most troublesome, not the IPv6.

Regards,

Baldur

On 9/13/21 11:22 AM, Randy Bush wrote:
> < rant >
>
> ipv6 was designed at a time where the internet futurists/idealists had
> disdain for operators and vendors, and thought we were evil money
> grabbers who had to be brought under control.
>
> the specs as originally RFCed by the ietf is very telling. for your
> amusement, take a look at rfc 2450. it took five years of war to get
> rid of the tla/sla crap. and look at the /64 religion today[0].
>
> real compatibility with ipv4 was disdained. the transition plan was
> dual stack and v4 would go away in a handful of years. the 93
> transition mechanisms were desperate add-ons when v4 did not go away.
> and dual stack does not scale, as it requires v4 space proportional to
> deployed v6 space.
>
> we are left to make the mess work for the users, while being excoriated
> for not doing it quickly or well enough, and for trying to make ends
> meet financially.
>
This is really easy to say in hindsight. 30 years ago it wasn't even
vaguely a given that the Internet would even win and the size of the IP
universe was still tiny. The main problem is that the internet was a
classic success disaster where you're going as fast as possible and
falling farther and farther behind. All of the gripes about particulars
strike me as utterly irrelevant in the global scheme of things. As I
mentioned, if they did nothing more than bolted on two more address
bytes it still would have been just as impossible to get vendors and
providers to care because everybody was heads down trying to deal with
the success disaster. It's really easy to say that ipv6 suffers from
second system syndrome -- which it does -- but that doesn't provide any
concrete strategy for what would have been "better" in both getting
vendors and providers to care. None of them wanted to do anything other
than crank out kit that could be sold in the here and now that providers
were willing to buy. That was certainly my experience at Cisco. As I
said, the exec I talked to didn't actually want to do anything at all
but was willing to let a couple of engineers navel gaze if it gave him
something to talk about were the subject to actually come up with
customers and a bludgeon against 3COM (iirc) at the time.

None of this is technical. It was which short term hack is going to keep
the gravy train flowing? I was a developer at the time keeping an eye on
the drafts as they were coming out. They didn't strike me was overly
difficult to implement nor did they strike me as particularly
overwrought. From a host standpoint, i didn't think it would take too
much effort to get something up and running but I waited until somebody
started asking for it. That never came. Nothing ever came. Then NAT's
came and kicked the can down the roads some more. Now we have mega-yacht
NAT's to kick it down the road even farther. Tell us what else would
have prevented that?

Mike

In resource challenged regions we have been using IPv4+CGN+IPv6 dual stack for the last ten or so years. For 20K subs you can use one /24 of ipv4 and a /40 or so of ipv6. There have been available RGW’s and sufficient vendor support throughout this time. The only issues I have ever really seen have been with Sony PSN doing random ipv4 /32 blocks. Apart from that it has been working just fine. Over 50% of traffic now flows on the V6 side and in general end customers have no clue, it just works.



>For all I care we already have a perfect working system with IPv4+CGN+IPv6. The CGN part was the most troublesome, not the IPv6.

Baldur Norddahl wrote:
>
>
> On Mon, Sep 13, 2021 at 8:22 PM Randy Bush <randy@psg.com
> <mailto:randy@psg.com>> wrote:
>
> real compatibility with ipv4 was disdained. the transition plan was
> dual stack and v4 would go away in a handful of years. the 93
> transition mechanisms were desperate add-ons when v4 did not go away.
> and dual stack does not scale, as it requires v4 space proportional to
> deployed v6 space.
>
>
> What I find most peculiar about this whole rant (not just yours but
> the whole thread) is that I may be the only one who found implementing
> IPv6 with dual stack completely trivial and a non issue? There is no
> scale issue nor any of the other rubbish.
>
> Baldur
>
The essential point is that your dual stack is barely relevant until
every stack is dual. Which is impossible without CGNAT.

It also turns out that is barely relevant how easy it may have been for you.

Joe

On 9/13/21 2:52 PM, Baldur Norddahl wrote:
>
>
> On Mon, Sep 13, 2021 at 8:22 PM Randy Bush <randy@psg.com
> <mailto:randy@psg.com>> wrote:
>
> real compatibility with ipv4 was disdained.  the transition plan was
> dual stack and v4 would go away in a handful of years.  the 93
> transition mechanisms were desperate add-ons when v4 did not go away.
> and dual stack does not scale, as it requires v4 space proportional to
> deployed v6 space.
>
>
> What I find most peculiar about this whole rant (not just yours but
> the whole thread) is that I may be the only one who found implementing
> IPv6 with dual stack completely trivial and a non issue? There is no
> scale issue nor any of the other rubbish.

I agree on the host side. It didn't even occur to me at the time I was
looking at it that it would be any sort of issue -- we had all kinds of
other protocols on our boxes like SMB, Netware, DEC LAT, etc. We would
have done it if customers told us they wanted it, just like we
implemented ACL's not realizing why they were especially important. Back
in the early days all routing was done in software so it wouldn't have
been hard to squeeze v6 in. All of that changed when the forwarding
plane got cast in silicon though which made it far, far more difficult
to get anybody to stick their necks out vs a skunk works software
project. But before that it would have been completely doable if
somebody was willing to throw money at it.

Mike

On 13.09.21 20:22, Randy Bush wrote:
> < rant >

> ipv6 was designed at a time where the internet futurists/idealists had
> disdain for operators and vendors, and thought we were evil money
> grabbers who had to be brought under control.

and...

> <snip>

> real compatibility with ipv4 was disdained.


I'm not claiming IPv6 is any sort of perfect, but let's not revise history.

To quote Lee Hayes' adaptation of Will Rogers:

“Things aren't what they used to be, what's more they never were.”

There were four proposals for the IPng:

* NIMROD, PIP, SIP, and TUBA

SIP was the one that was chosen, supported by endpoint manufacturers
such as Sun and SGI, and it was the MOST compatible.  Operators and
router manufacturers at the time pushed TUBA, which was considerably
less compatible with the concepts used in v4 because of variable length
addressing.   If we endpoints had some notion that v6 would take as long
as it has to diffuse, perhaps we all might have thought differently. I
don't know.

There is no evidence that any other design choices on the table at the
time would have gotten us transitioned any faster, and a lot of evidence
and analysis that the exact opposite is more likely.  There are many
reasons v6 has taken this long to deploy, but one prediction model
(Elmore/Camp) dating back to 2008 have said it would take to the end of
the century to get to 80%, barring a paradigm shift.  We may have that
paradigm shift with IoT, but the jury is still out.

Eliot

Randy Bush wrote:

> it took five years of war to get
> rid of the tla/sla crap.

As backbone operators do not want to have large
routing tables, TLA is a good idea. As you can
see, TLA of IPv4 is /24, though there is no NLA.

> and look at the /64 religion today[0].

It was /80, until I pointed out that IEEE1394 MAC
address is 64bit long.

Masataka Ohta

and 8+8, variable length, ... just didn't happen, eh?

the nice thing about revisionist history is that anybody can play.

randy

8+8 came *MUCH* later than that, and really wasn't ready for prime
time.  The reason we know that is that work was the basis of LISP and
ILNP.  Yes, standing on the shoulders of giants.  And there certainly
were poor design decisions in IPv6, bundling IPsec being one.  But the
idea that operators were ignored?  Feh.

On 14.09.21 14:10, Randy Bush wrote:
> and 8+8, variable length, ... just didn't happen, eh?
>
> the nice thing about revisionist history is that anybody can play.
>
> randy
>

Nick Hilliard wrote:

> E.g. using mcast for address resolution because large flat
> l2 networks were the order of the day,

It was and still is trivially obvious that automatic
address resolution over large flat l2 does not scale.

Configuring virtual all-host-mcast in large flat l2
for automatic address resolution needs static address
resolution information, which is not automatic.

> that client
> self-selected addresses should be the only game in town for
> auto-addressing

Using lengthy MAC addresses for that purpose was tried
in XNS. But as it was so annoying, it was totally abandoned
at the time IPv4 was widely developed.

Though AppleTalk was still using a single byte for that
purpose in SOHO, DHCP was already performing better
everywhere including SOHO.

> that extension headers were a great idea,

IPv4 optional header was totally operationally denied a lot
before that.

Masataka Ohta

Eliot Lear wrote:

> Operators and
> router manufacturers at the time pushed TUBA, which was considerably
> less compatible with the concepts used in v4 because of variable length
> addressing.

That address length is variable is not a problem at all. Byte-wise
barrel shifters by hardware for CLNP are trivially easy and light
weight to implement.

The real problem is on the number of prefix bits which must be
looked up by backbone routers, which means IPv6 abandoning TLA
is hopeless.

NSAP addresses, which essentially are telephone numbers, assume
geographically aggregated addresses at country level (so called,
country code), which is why they don't need large global routing
tables.

8+8 has nothing to do with the problem and LISP came a lot later
as a broken solution for the problem.

Masataka Ohta

On 9/14/21 5:37 AM, Eliot Lear wrote:
>
> 8+8 came *MUCH* later than that, and really wasn't ready for prime
> time.  The reason we know that is that work was the basis of LISP and
> ILNP.  Yes, standing on the shoulders of giants.  And there certainly
> were poor design decisions in IPv6, bundling IPsec being one.  But the
> idea that operators were ignored?  Feh.
>
I wasn't there at actual meetings at the time but I find the notion that
operators were ignored pretty preposterous too. There was a significant
amount of bleed over between the two as I recall from going to
Interop's. What incentive do vendors have to ignore their customers?
Vendors have incentive to listen to customer requirements and abstract
them to take into account things can't see on the outside, but to
actually give the finger to them? And given how small the internet
community was back while this was happening, I find it even more unlikely.

But Randy still hasn't told us what would have worked and why it would
have succeeded.

Mike


> On 14.09.21 14:10, Randy Bush wrote:
>> and 8+8, variable length, ... just didn't happen, eh?
>>
>> the nice thing about revisionist history is that anybody can play.
>>
>> randy
>>

> On Sep 14, 2021, at 12:58 , Michael Thomas <mike@mtcc.com> wrote:
>
>
>
> On 9/14/21 5:37 AM, Eliot Lear wrote:
>> 8+8 came MUCH later than that, and really wasn't ready for prime time. The reason we know that is that work was the basis of LISP and ILNP. Yes, standing on the shoulders of giants. And there certainly were poor design decisions in IPv6, bundling IPsec being one. But the idea that operators were ignored? Feh.
>>
> I wasn't there at actual meetings at the time but I find the notion that operators were ignored pretty preposterous too. There was a significant amount of bleed over between the two as I recall from going to Interop's. What incentive do vendors have to ignore their customers? Vendors have incentive to listen to customer requirements and abstract them to take into account things can't see on the outside, but to actually give the finger to them? And given how small the internet community was back while this was happening, I find it even more unlikely.
>

You’d be surprised… Vendors often get well down a path before exposing enough information to the community to get the negative feedback their solution so richly deserves. At that point, they have rather strong incentives to push for the IETF adopting their solution over customer objections because of entrenched code-base and a desire not to go back and explain to management that the idea they’ve been working on for the last 6 months is stillborn.

Owen

On Tue, Sep 14, 2021 at 10:03 AM Masataka Ohta <
mohta@necom830.hpcl.titech.ac.jp> wrote:

>
> NSAP addresses, which essentially are telephone numbers, assume
> geographically aggregated addresses at country level (so called,
> country code), which is why they don't need large global routing
> tables.
>

The phone network doesn't really operate or 'route' in the same way as the
Internet does.
I don't think using it in a comparison here works, at all... I really wish
folk would stop trying
to make this equivalency.

(I think LNP actually means the phone carriers are creating a 'must know
about 6+b address/path mappings
in a possible future... or even just in the US ~350m endpoints/mappings,
but anyways...)

But in fact with local number portability, you cannot rely on the county
code to tell you where to route a telephone call anymore. Which is many
calls result in a data dip to provide you the routing information from a
central repository.

Shane

On Tue, Sep 14, 2021 at 10:07 AM Masataka Ohta <
mohta@necom830.hpcl.titech.ac.jp> wrote:

> Eliot Lear wrote:
>
> > Operators and
> > router manufacturers at the time pushed TUBA, which was considerably
> > less compatible with the concepts used in v4 because of variable length
> > addressing.
>
> That address length is variable is not a problem at all. Byte-wise
> barrel shifters by hardware for CLNP are trivially easy and light
> weight to implement.
>
> The real problem is on the number of prefix bits which must be
> looked up by backbone routers, which means IPv6 abandoning TLA
> is hopeless.
>
> NSAP addresses, which essentially are telephone numbers, assume
> geographically aggregated addresses at country level (so called,
> country code), which is why they don't need large global routing
> tables.
>
> 8+8 has nothing to do with the problem and LISP came a lot later
> as a broken solution for the problem.
>
> Masataka Ohta
>

On 9/14/21 1:06 PM, Owen DeLong wrote:
>
>
>> On Sep 14, 2021, at 12:58 , Michael Thomas <mike@mtcc.com
>> <mailto:mike@mtcc.com>> wrote:
>>
>>
>> On 9/14/21 5:37 AM, Eliot Lear wrote:
>>>
>>> 8+8 came *MUCH* later than that, and really wasn't ready for prime
>>> time.  The reason we know that is that work was the basis of LISP
>>> and ILNP.  Yes, standing on the shoulders of giants. And there
>>> certainly were poor design decisions in IPv6, bundling IPsec being
>>> one.  But the idea that operators were ignored?  Feh.
>>>
>> I wasn't there at actual meetings at the time but I find the notion
>> that operators were ignored pretty preposterous too. There was a
>> significant amount of bleed over between the two as I recall from
>> going to Interop's. What incentive do vendors have to ignore their
>> customers? Vendors have incentive to listen to customer requirements
>> and abstract them to take into account things can't see on the
>> outside, but to actually give the finger to them? And given how small
>> the internet community was back while this was happening, I find it
>> even more unlikely.
>>
>
> You’d be surprised… Vendors often get well down a path before exposing
> enough information to the community to get the negative feedback their
> solution so richly deserves. At that point, they have rather strong
> incentives to push for the IETF adopting their solution over customer
> objections because of entrenched code-base and a desire not to go back
> and explain to management that the idea they’ve been working on for
> the last 6 months is stillborn.
>
But we're talking almost 30 years ago when the internet was tiny. And
it's not like operators were some fount of experience and wisdom back
then: everybody was making it up along the way including operators which
barely even existed back then. I mean, we're talking about the netcom
days here. That's why this stinks of revisionist history to me.

Mike

> On Sep 14, 2021, at 13:51 , Michael Thomas <mike@mtcc.com> wrote:
>
>
>
> On 9/14/21 1:06 PM, Owen DeLong wrote:
>>
>>
>>> On Sep 14, 2021, at 12:58 , Michael Thomas <mike@mtcc.com <mailto:mike@mtcc.com>> wrote:
>>>
>>>
>>>
>>> On 9/14/21 5:37 AM, Eliot Lear wrote:
>>>> 8+8 came MUCH later than that, and really wasn't ready for prime time. The reason we know that is that work was the basis of LISP and ILNP. Yes, standing on the shoulders of giants. And there certainly were poor design decisions in IPv6, bundling IPsec being one. But the idea that operators were ignored? Feh.
>>>>
>>> I wasn't there at actual meetings at the time but I find the notion that operators were ignored pretty preposterous too. There was a significant amount of bleed over between the two as I recall from going to Interop's. What incentive do vendors have to ignore their customers? Vendors have incentive to listen to customer requirements and abstract them to take into account things can't see on the outside, but to actually give the finger to them? And given how small the internet community was back while this was happening, I find it even more unlikely.
>>>
>>
>> You’d be surprised… Vendors often get well down a path before exposing enough information to the community to get the negative feedback their solution so richly deserves. At that point, they have rather strong incentives to push for the IETF adopting their solution over customer objections because of entrenched code-base and a desire not to go back and explain to management that the idea they’ve been working on for the last 6 months is stillborn.
>>
> But we're talking almost 30 years ago when the internet was tiny. And it's not like operators were some fount of experience and wisdom back then: everybody was making it up along the way including operators which barely even existed back then. I mean, we're talking about the netcom days here. That's why this stinks of revisionist history to me.
>

I was there for parts of it. Even then, the vendors were entrenched in their views and dominated many of the conversations.

Owen

> I wasn't there at actual meetings at the time

but your opinion was?

> but I find the notion that operators were ignored pretty preposterous
> too

so did we, the ops who were there at the time

randy

On 9/14/21 2:08 PM, Randy Bush wrote:
>> I wasn't there at actual meetings at the time
> but your opinion was?

Just because I didn't attend IETF meetings doesn't mean that I didn't
read drafts, etc. Lurkers are a thing and lurkers are allowed opinions too.

Mike

> Just because I didn't attend IETF meetings doesn't mean that I didn't
> read drafts, etc. Lurkers are a thing and lurkers are allowed opinions
> too.

i missed the rfc where the chair of the v6 wg said the ops did not
understand the h ratio because we did not understand logarithms.

<plonk>

randy

On 9/14/21 2:07 PM, Owen DeLong wrote:
> You’d be surprised… Vendors often get well down a path before exposing
> enough information to the community to get the negative feedback their
> solution so richly deserves. At that point, they have rather strong
> incentives to push for the IETF adopting their solution over customer
> objections because of entrenched code-base and a desire not to go back
> and explain to management that the idea they’ve been working on for
> the last 6 months is stillborn.
>>>
>> But we're talking almost 30 years ago when the internet was tiny. And
>> it's not like operators were some fount of experience and wisdom back
>> then: everybody was making it up along the way including operators
>> which barely even existed back then. I mean, we're talking about the
>> netcom days here. That's why this stinks of revisionist history to me.
>>
>
> I was there for parts of it. Even then, the vendors were entrenched in
> their views and dominated many of the conversations.
>
Vendors have to be able to implement things so of course there is going
to be push back when it's not technically feasible or far more
expensive. Nobody expects customers putting out the actual $$$ to be up
to speed on the intricacies of TCAM's and other such considerations so
there is always going to be back and forth.

And none of this alters that nobody has given a scenario where their
$SOLUTION would have fared any better than ipv6.

Mike

On 9/14/21 2:17 PM, Randy Bush wrote:
>> Just because I didn't attend IETF meetings doesn't mean that I didn't
>> read drafts, etc. Lurkers are a thing and lurkers are allowed opinions
>> too.
> i missed the rfc where the chair of the v6 wg said the ops did not
> understand the h ratio because we did not understand logarithms.

So in order to have an opinion, I have to know all of the politics along
with the documents produced. Got it. Thank goodness we didn't know that
when we were implementing IPv4 in the mid 80's.

Frankly I had always regretted not going to an IETF meeting at ISI
around 88 or so, but given the silliness of IETF politics maybe that was
a blessing.

Mike

> On Sep 14, 2021, at 14:20 , Michael Thomas <mike@mtcc.com> wrote:
>
>
> On 9/14/21 2:07 PM, Owen DeLong wrote:
>> You’d be surprised… Vendors often get well down a path before exposing enough information to the community to get the negative feedback their solution so richly deserves. At that point, they have rather strong incentives to push for the IETF adopting their solution over customer objections because of entrenched code-base and a desire not to go back and explain to management that the idea they’ve been working on for the last 6 months is stillborn.
>>>>
>>> But we're talking almost 30 years ago when the internet was tiny. And it's not like operators were some fount of experience and wisdom back then: everybody was making it up along the way including operators which barely even existed back then. I mean, we're talking about the netcom days here. That's why this stinks of revisionist history to me.
>>>
>>
>> I was there for parts of it. Even then, the vendors were entrenched in their views and dominated many of the conversations.
>>
> Vendors have to be able to implement things so of course there is going to be push back when it's not technically feasible or far more expensive. Nobody expects customers putting out the actual $$$ to be up to speed on the intricacies of TCAM's and other such considerations so there is always going to be back and forth.

Back and forth is one thing, but the reality is that they put a lot of development effort into things in a vacuum and then expected us to take what they built and standardize it. They often seemed utterly surprised when the practical realities of deploying it in an operational network didn’t agree with their idea of an “elegant” solution.

> And none of this alters that nobody has given a scenario where their $SOLUTION would have fared any better than ipv6.

That’s probably fair criticism to some extent.

Owen

Shane Ronan wrote:

> But in fact with local number portability, you cannot rely on the county
> code to tell you where to route a telephone call anymore.

Not. With geographical aggregation, you may route a call
*anywhere* in the destination country.

Geographical aggregation means carriers in a country is
required to have rich and robust connectivity between
them within the country as if the country is served by
a single carrier, which actually was the case with
ATT/PTT/NTT monopoly.

Then, whichever international carrier is chosen by the caller,
the international carrier looks up country-wise routing
table to reach the country. When the call reaches some
point in the destination country, the callee can be reached
relying on rich connectivity in the country.

Number portability database is looked up after the call
reaches the destination country, which will be used for
further intra-national routing, which do not affect
country-wise aggregation of international routing table.

But, as ISPs do not want to be regulated to have such rich
intra-national connectivity in all the countries,
geographically aggregated addressing is considered not
acceptable by operator community of the Internet.

Masataka Ohta

Christopher Morrow wrote:

>> NSAP addresses, which essentially are telephone numbers, assume
>> geographically aggregated addresses at country level (so called,
>> country code), which is why they don't need large global routing
>> tables.

> The phone network doesn't really operate or 'route' in the same way as the
> Internet does.

The context here is TUBA where NSAP addresses are used for best
effort CLNP, which is not circuit switched and resource reserving
phone network.

> I don't think using it in a comparison here works, at all... I really wish
> folk would stop trying
> to make this equivalency.

That you don't properly understand the similarities and the
differences between telephone network and the Internet is
not a problem for rest of us.

Masataka Ohta

On Wed, 15 Sep 2021 13:38:21 +0900, Masataka Ohta said:

> Not. With geographical aggregation, you may route a call
> *anywhere* in the destination country.

The *real* fun starts when my provider is able to connect calls
to my +1 540 etcetc phone number to my phone even if I'm in +371
or +81 or similar....

Valdis Kl?tnieks wrote:

>> Not. With geographical aggregation, you may route a call
>> *anywhere* in the destination country.
>
> The *real* fun starts when my provider is able to connect calls
> to my +1 540 etcetc phone number to my phone even if I'm in +371
> or +81 or similar....

No problem. The caller will be charged for call to +1 and you
will be charged for international transfer from +1 to +371 or
+81.

Masataka Ohta

On Wed, 15 Sept 2021 at 06:38, Masataka Ohta <
mohta@necom830.hpcl.titech.ac.jp> wrote:

> Shane Ronan wrote:
>
> > But in fact with local number portability, you cannot rely on the county
> > code to tell you where to route a telephone call anymore.
>
> Not. With geographical aggregation, you may route a call
> *anywhere* in the destination country.
>

You mean anywhere in the world. Calls to my number reach my cell phone no
matter where I go.


>
> Number portability database is looked up after the call
> reaches the destination country, which will be used for
> further intra-national routing, which do not affect
> country-wise aggregation of international routing table.
>
>
Actually the GSM system will query the HLR to find out where to really
route the call. Much like LISP actually.

Regards,

Baldur

On 15.09.21 06:38, Masataka Ohta wrote:
>
> Geographical aggregation means carriers in a country is
> required to have rich and robust connectivity between
> them within the country...

or region.

And this is indeed why such an addressing concept was dropped from
IPv6.  It just didn't fly economically.

Eliot

Baldur Norddahl wrote:

>>> But in fact with local number portability, you cannot rely on the county
^^^^^^^^^^^^^^^^^^^^^^^^
>>> code to tell you where to route a telephone call anymore.
>>
>> Not. With geographical aggregation, you may route a call
>> *anywhere* in the destination country.

> You mean anywhere in the world. Calls to my number reach my cell phone no
> matter where I go.

You are confusing number portability and call forwarding.

Masataka Ohta

On 9/15/21 09:31, Masataka Ohta wrote:
> Baldur Norddahl wrote:
>
>>>> But in fact with local number portability, you cannot rely on the
>>>> county
>                      ^^^^^^^^^^^^^^^^^^^^^^^^
>>>> code to tell you where to route a telephone call anymore.
>>>
>>> Not. With geographical aggregation, you may route a call
>>> *anywhere* in the destination country.
>
>> You mean anywhere in the world. Calls to my number reach my cell phone no
>> matter where I go.
>
> You are confusing number portability and call forwarding.

You're confusing call forwarding with international roaming.

Obligatory back story. In the early days of international roaming I had
cellular service in the US with AT&T. I traveled to Bulgaria for a week
and took my phone with me. International rates were on the order of
$3.95 per minute.

I deliberately left my phone turned off so as to avoid expensive
incoming calls. On arrival I turned my phone on and made two calls to
let people at home know I'd arrived. During the trip I would turn it on
and make a call occasionally, total under ten calls, all outbound.

When I got home I would up with a bill totaling several hundred dollars.
Every time someone called my number the call got routed to Bulgaria. The
call then went back to the USA and hit my voicemail, so I got charged
$3.95 twice for each of these calls.

I eventually got the bill resolved, but it took a very long time and
multiple escalations. Suffice it to say that AT&T customer service reps
are located nowhere near the "A" in "AT&T".

A year later I made another international trip. Ahead of time I called
AT&T to ask them to disable voicemail so I wouldn't have to deal with
that again. I finally was able to do so but that, too, took multiple
calls to people very obviously not in "A".

--
Jay Hennigan - jay@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

> On Sep 15, 2021, at 09:31 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> Baldur Norddahl wrote:
>
>>>> But in fact with local number portability, you cannot rely on the county
> ^^^^^^^^^^^^^^^^^^^^^^^^
>>>> code to tell you where to route a telephone call anymore.
>>>
>>> Not. With geographical aggregation, you may route a call
>>> *anywhere* in the destination country.
>
>> You mean anywhere in the world. Calls to my number reach my cell phone no
>> matter where I go.
>
> You are confusing number portability and call forwarding.
>
> Masataka Ohta

Not exactly… He is confusing number portability and roaming.

Owen

ons. 15. sep. 2021 19.37 skrev Owen DeLong via NANOG <nanog@nanog.org>:

>
>
> > On Sep 15, 2021, at 09:31 , Masataka Ohta <
> mohta@necom830.hpcl.titech.ac.jp> wrote:
> >
> > Baldur Norddahl wrote:
> >
> >>>> But in fact with local number portability, you cannot rely on the
> county
> > ^^^^^^^^^^^^^^^^^^^^^^^^
> >>>> code to tell you where to route a telephone call anymore.
> >>>
> >>> Not. With geographical aggregation, you may route a call
> >>> *anywhere* in the destination country.
> >
> >> You mean anywhere in the world. Calls to my number reach my cell phone
> no
> >> matter where I go.
> >
> > You are confusing number portability and call forwarding.
> >
> > Masataka Ohta
>
> Not exactly… He is confusing number portability and roaming.
>

I am not confusing anything. Nobody said anything about number portability
in the above quote.

Just pointing out that some assumptions about how voice call works is not
true. Nor would it be smart to send traffic to another part of the world
unnecessarily. Local calls stay local even when roaming. Please remember
that signaling and voice is separate in the telco world which is why it
compares poorly with IP. Except for the LISP protocol which does something
similar.

Regards

Baldur

The 600 ton elephant in the room is anyone could right now sit down
and design and deploy some alternative to IPv4/IPv6 and from there
begin writing down how they did it as a series of standards documents
and encourage others to give it a try hoping for some snowball effect.

You just float it on top of the current probably IP layer tho there
are other possibilities, not too many (pick a layer.)

What much of the muttering is about is people (who never do things
like this) tend to be risk-averse and want someone or something on
high to bless and nurture their efforts.

That's what much of this discussion about some alternative to IPv6
comes down to, risk aversion, how do you know if you sat down and
began working out an alternative you'd be rewarded for your efforts.

You Don't!

Imagine if Linus Torvalds sat waiting for the POSIX committees et al
to take up his ideas for an alternative to Unix (TM). He'd still be
waiting.

Probably one of the worst problems with IPv6 is precisely the fact
that groups of people managed to ride directly on the then rapid
growth of IPv4 and turn out whatever a dozen or so strangers in
windowless hotel rooms and some email lists could agree on, including
all sorts of vested interests (e.g., router vendors and the big tech
of the day.) Clearly it wasn't completely insidious, it all kind of
works, it's just that there's been a lot of resistance to adoption
hence a sense that something's wrong.

The world is your oyster (TheWorld is mine :-)).

P.S. One might want to keep in mind a quote often attributed to Bill
Joy (one of the founders of Sun Microsystems, and a lot of other
stuff), roughly:

In order for a new technology to succeed it has to be ten times
better than what it seeks to replace (i.e., to overcome incumbency
and inertia.)

--
-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*

It appears that Baldur Norddahl <baldur.norddahl@gmail.com> said:
According to Baldur Norddahl <baldur.norddahl@gmail.com>:
>> Number portability database is looked up after the call
>> reaches the destination country, which will be used for
>> further intra-national routing, which do not affect
>> country-wise aggregation of international routing table.
>
>Actually the GSM system will query the HLR to find out where to really
>route the call. Much like LISP actually.

With a century and a half of history, the phone system has a lot of different
numbering hacks.

In the US, the country is divided into several hundred regions within which
you can port phone numbers. They do this with an overlay database; on each
call the number is looked up to get a routing number which is used to route
the call. If the number hasn't been ported the routing number is the
number itself, otherwise it's a number assigned to the switch that handles
the call. The routing numbers are assigned in the familar hierarchical
way and the first seven digits of the number (three digit area code,
three digit prefix, one digit subprefix) to route the call. Mobile carriers
have their own system underneath that so if you, say, get an AT&T number in
New York, port it to Verizon, and then move to California, calls to your
number get routed to New York, looked up in the porting database, delivered
to a Verizon switch in NY, then routed within the Verizon network to your
phone in California. Dunno whether Verizon uses the same HLR to do international
roaming or separate for domestic and international.

There is a proposal to provide national number portability in the US which
would in effect merge all of the regions together and get rid of all long
distance charges within the US that has a reasonably good chance of happening.

This has nothing to do with IPv6, of course, other than that modern phones use
VoLTE so within a mobile carrier's network your voice call is probably handled
using IPv6 transport.

----- On Sep 15, 2021, at 2:20 PM, bzs@theworld.com wrote:

Hi,

> The 600 ton elephant in the room is anyone could right now sit down
> and design and deploy some alternative to IPv4/IPv6 and from there
> begin writing down how they did it as a series of standards documents
> and encourage others to give it a try hoping for some snowball effect.

Isn't that how 6RD (RFC5969) was created?

Thanks,

Sabri

On 9/14/21 12:44 AM, Eliot Lear wrote:
>
> There were four proposals for the IPng:
>
> * NIMROD, PIP, SIP, and TUBA
>
> SIP was the one that was chosen, supported by endpoint manufacturers
> such as Sun and SGI, and it was the MOST compatible.  Operators and
> router manufacturers at the time pushed TUBA, which was considerably
> less compatible with the concepts used in v4 because of variable
> length addressing.   If we endpoints had some notion that v6 would
> take as long as it has to diffuse, perhaps we all might have thought
> differently. I don't know.
>
>
So I'm beginning to think that the reason ipv6 didn't take off is one
simple thing: time. All of the infighting took years and by then that
ship had long sailed. The basic mechanisms for v6 for hosts were not
complicated and all of the second system syndrome fluff could be mostly
be ignored or implemented when it actually made sense. If this had been
settled within a year instead of five, there may have been a chance
especially since specialized hardware was either nonexistent or just
coming on the scene. I mean, Kalpana was still pretty new when a lot of
this was being first discussed from what I can tell. Maybe somebody else
knows when hardware routing came on the scene but there was still lots
of software forwarding planes when I started at Cisco in 1998 just as
broadband was starting to flow.

The IETF was a victim of its own dysfunction, film at 11 and now we're
having a 30 year reunion.

Mike

> On Sep 15, 2021, at 16:20 , Michael Thomas <mike@mtcc.com> wrote:
>
>
>
> On 9/14/21 12:44 AM, Eliot Lear wrote:
>>
>> There were four proposals for the IPng:
>>
>> NIMROD, PIP, SIP, and TUBA
>> SIP was the one that was chosen, supported by endpoint manufacturers such as Sun and SGI, and it was the MOST compatible. Operators and router manufacturers at the time pushed TUBA, which was considerably less compatible with the concepts used in v4 because of variable length addressing. If we endpoints had some notion that v6 would take as long as it has to diffuse, perhaps we all might have thought differently. I don't know.
>>
>>
> So I'm beginning to think that the reason ipv6 didn't take off is one simple thing: time. All of the infighting took years and by then that ship had long sailed. The basic mechanisms for v6 for hosts were not complicated and all of the second system syndrome fluff could be mostly be ignored or implemented when it actually made sense. If this had been settled within a year instead of five, there may have been a chance especially since specialized hardware was either nonexistent or just coming on the scene. I mean, Kalpana was still pretty new when a lot of this was being first discussed from what I can tell. Maybe somebody else knows when hardware routing came on the scene but there was still lots of software forwarding planes when I started at Cisco in 1998 just as broadband was starting to flow.
>
Most of it was settled fairly quickly, actually. The bigger delays were software vendors, network infrastructure product vendors (DSLAMs and the like), etc. who even after it was well settled simply didn’t feel a need to incorporate it into their products until about a year after IANA runout.
> The IETF was a victim of its own dysfunction, film at 11 and now we're having a 30 year reunion.
>
I’m not sure we can put all (or even most) of the blame on IETF dysfunction here. Don’t get me wrong, IMHO there’s plenty of IETF dysfunction and it is partially responsible. However, I suspect that if IETF had rolled out the model of perfection and an ideal protocol 1 month after the IPNG working group started, we’d still be pretty much where we are today because of the procrastination model of addressing major transitions that is baked into human nature.

Owen

On 9/15/21 4:26 PM, Owen DeLong wrote:
>
>
>> On Sep 15, 2021, at 16:20 , Michael Thomas <mike@mtcc.com
>> <mailto:mike@mtcc.com>> wrote:
>>
>>
>> On 9/14/21 12:44 AM, Eliot Lear wrote:
>>>
>>> There were four proposals for the IPng:
>>>
>>> * NIMROD, PIP, SIP, and TUBA
>>>
>>> SIP was the one that was chosen, supported by endpoint manufacturers
>>> such as Sun and SGI, and it was the MOST compatible.  Operators and
>>> router manufacturers at the time pushed TUBA, which was considerably
>>> less compatible with the concepts used in v4 because of variable
>>> length addressing.   If we endpoints had some notion that v6 would
>>> take as long as it has to diffuse, perhaps we all might have thought
>>> differently.  I don't know.
>>>
>>>
>> So I'm beginning to think that the reason ipv6 didn't take off is one
>> simple thing: time. All of the infighting took years and by then that
>> ship had long sailed. The basic mechanisms for v6 for hosts were not
>> complicated and all of the second system syndrome fluff could be
>> mostly be ignored or implemented when it actually made sense. If this
>> had been settled within a year instead of five, there may have been a
>> chance especially since specialized hardware was either nonexistent
>> or just coming on the scene. I mean, Kalpana was still pretty new
>> when a lot of this was being first discussed from what I can tell.
>> Maybe somebody else knows when hardware routing came on the scene but
>> there was still lots of software forwarding planes when I started at
>> Cisco in 1998 just as broadband was starting to flow.
>>
> Most of it was settled fairly quickly, actually. The bigger delays
> were software vendors, network infrastructure product vendors (DSLAMs
> and the like), etc. who even after it was well settled simply didn’t
> feel a need to incorporate it into their products until about a year
> after IANA runout.

I was aware of ipv6 -- or at least what would become ipv6 -- in either
1992 and absolutely no later than 1993. The internet was still tiny then
and I don't even think that CIDR was even a thing yet, and broadband was
still 5 years away. Had something simple like ipv6 headers, AAAA, and
the silliness of SLAC vs. DHCP wars had been resolved quickly there was
a very good chance that vendors would have adopted it if customers
wanted it or could be cajoled into wanting it. At that time IP was still
"the path to OSI" iirc so none of this was in cement from a vendor
standpoint (and sorry, there are lots more vendors than just router
vendors). But the entire thing dragged on and on and on and by then it
was far too late. Then the invention of NAT sealed that fate.


>> The IETF was a victim of its own dysfunction, film at 11 and now
>> we're having a 30 year reunion.
>>
> I’m not sure we can put all (or even most) of the blame on IETF
> dysfunction here. Don’t get me wrong, IMHO there’s plenty of IETF
> dysfunction and it is partially responsible. However, I suspect that
> if IETF had rolled out the model of perfection and an ideal protocol 1
> month after the IPNG working group started, we’d still be pretty much
> where we are today because of the procrastination model of addressing
> major transitions that is baked into human nature.
>
No I think the best was the enemy of the good. As it ever were. Nobody
seems to have appreciated what the real problem was -- time. Hindsight
is 20/20 but it wasn't hard to see that the internet was exploding and
wasn't in fact the "path to OSI" and by ignoring time there wasn't going
to be a path to anything.

Mike

On September 15, 2021 at 15:40 sabri@cluecentral.net (Sabri Berisha) wrote:
> ----- On Sep 15, 2021, at 2:20 PM, bzs@theworld.com wrote:
>
> Hi,
>
> > The 600 ton elephant in the room is anyone could right now sit down
> > and design and deploy some alternative to IPv4/IPv6 and from there
> > begin writing down how they did it as a series of standards documents
> > and encourage others to give it a try hoping for some snowball effect.
>
> Isn't that how 6RD (RFC5969) was created?
>
> Thanks,
>
> Sabri

One could use a similar approach tho probably an entire routing
infrastructure would also need to be simulated. It wouldn't just be
sneaking a packet from here to there, it would be the emulation of an
entire network most likely. Hard to say w/o a design spec :-)

But at the end of the day it's just bits.

--
-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 14 Sep 2021, at 3:46 AM, Eliot Lear <lear@ofcourseimright.com> wrote:
> ….
> There is no evidence that any other design choices on the table at the time would have gotten us transitioned any faster, and a lot of evidence and analysis that the exact opposite is more likely.

Elliot -

If by “design choices” you mean the criteria that we set forth for the new protocol (IPng), then that’s potentially true - it’s fairly challenging to hypothecate what impact different technical criteria would have had on the outcome.

If by “design choices” you mean the tradeoffs accepted in selecting a particular candidate protocol and declaring victory, then I’d strongly disagree. I believe that we had the appropriate technical criteria for IPng (very nicely compiled and edited by Craig Patridge and Frank Kastenholz in RFC1726) and then made conscious decisions to disregard those very criteria in order to “make a decision” & “move forward.”

All of the IPng proposals where completely deficient with respect to transition capabilities. In the rush to make a IPng decision, the actual IPng Transition Criteria [1] that mandated a straightforward transition plan from IPv4 was simply acknowledged and then declared as “resolved" because we would also simultaneously form some working groups to study all of the transition requirements and made good on the transition criteria via future deliverables...(deliverables that were subsequently not delivered on)

The right answer would have been to formally and critically evaluate each of the candidate protocols against the requirements and not make any selection until candidate presented itself that actually met the required technical criteria. Instead, IPv6 transition was left as an afterthought for the operator community to solve, and thus the battles with the IETF on NAT-based transition for nearly two decades to get this basic technical requirement met.

FYI,
/John

Disclaimer: my views alone - made from 100% recycled electrons.

=== [1] The actual IPng Transition criteria (per RFC 1726) are as follows -

"
5.5 Transition

CRITERION
The protocol must have a straightforward transition plan from the
current IPv4.

DISCUSSION
A smooth, orderly, transition from IPv4 to IPng is needed. If we
can't transition to the new protocol, then no matter how wonderful
it is, we'll never get to it.

We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.

Rather, IPng will need to co-exist with IPv4 for some period of
time. There are a number of ways to achieve this co-existence
such as requiring hosts to support two stacks, converting between
protocols, or using backward compatible extensions to IPv4. Each
scheme has its strengths and weaknesses, which have to be weighed.

Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.

The absence of a rational and well-defined transition plan is not
acceptable. Indeed, the difficulty of running a network that is
transitioning from IPv4 to IPng must be minimized. (A good target
is that running a mixed IPv4-IPng network should be no more and
preferably less difficult than running IPv4 in parallel with
existing non-IP protocols).
"

In short:

1) The protocol must have a straightforward transition plan
2) A number of ways to achieve this which are to be explored
3) IPng must provide backward-compatibility to IPv4-only hosts
4) The absence of a well-defined transition plan is not acceptable

===

> On 20210916, at 11:15, John Curran <jcurran@istaff.org> wrote:
>
> On 14 Sep 2021, at 3:46 AM, Eliot Lear <lear@ofcourseimright.com> wrote:
>> ….
>> There is no evidence that any other design choices on the table at the time would have gotten us transitioned any faster, and a lot of evidence and analysis that the exact opposite is more likely.
>
> Elliot -
>
> If by “design choices” you mean the criteria that we set forth for the new protocol (IPng), then that’s potentially true - it’s fairly challenging to hypothecate what impact different technical criteria would have had on the outcome.
>
> If by “design choices” you mean the tradeoffs accepted in selecting a particular candidate protocol and declaring victory, then I’d strongly disagree. I believe that we had the appropriate technical criteria for IPng (very nicely compiled and edited by Craig Patridge and Frank Kastenholz in RFC1726) and then made conscious decisions to disregard those very criteria in order to “make a decision” & “move forward.”
>
> All of the IPng proposals where completely deficient with respect to transition capabilities.

Would not have mattered: one has to upgrade a large portion of the code/hardware present in the network anyway.

And ~1995 was a completely different time from 1998, or 2001 let alone 2021 in number of devices and deployment; thus anything one would have guessed would have been off.

The only thing that might have worked is a flag day, but unless some large org sets that in the near future, we'll just have the very very slow death thing that is happening and I bet that IPv4 will nicely outlive us all on this list and the ones that where there when IPng started.

Greets,
Jeroen

On 2021-09-16, at 01:20, Michael Thomas <mike@mtcc.com> wrote:
>
> So I'm beginning to think that the reason ipv6 didn't take off is one simple thing: time.

Well, actually, the reason was: Microsoft :-)
(And time.)

We entered into the current trajectory when we missed the window to get IPv6 into Windows 95. The rest is history…

Grüße, Carsten

It's hard to argue that there was no transition plan.  There were in
fact at least three transition plans for the selected approach (dual
stack, 6to4, and tunneling) some of which have been discarded along the
way; while others came to be based on operational experience.  Moreover,
the only way to really know that a transition mechanism is really going
to work is to let it out of the lab.  And ALL of the proposals would
have suffered the very same transition pains, because just as Jeroen has
pointed out, the pain stretched all the way to the application.

I don't think it's reasonable to argue that we should have waited for
some other mythical better proposal to come along.  I don't recall
anyone arguing for that at the time, and there's no reason to believe
that such a mythical proposal would have ever come to be in any
foreseeable time frame.  In fact Erik Fair, Dave Crocker, Tom Kessler
and I argued the very opposite, that we were digging ourselves a hole
with NAT.  Your argument at the time (Interop '95, Vegas) was that the
IETF didn't have the right to dictate address usage to deployments. 
True enough, but then people shouldn't hang their woes on the IETF.

As I mentioned earlier, the fundamental issue was that there were no ng
proposals that were in fact substitutable resources for v4, and NAT
was.  From there, economics has ruled, arguments be damned.

Eliot

* I *did* in fact posit an approach in 1992 that would have allowed for
orderly transition such that IPv4 could continue, and that was to define
class E addresses as extension blocks that were in fact name space
prefixes for another IPv4 header.  It wasn't taken seriously, and
perhaps rightly so.  This actually borrowed a page from the PSTN - most
people communicate locally and so you would rarely use those extended
name spaces.  This was before Paul (Tsuchiya) Francis offered PIP, which
had a notion of Landmark Routing that also went nowhere.


On 16.09.21 11:15, John Curran wrote:
> On 14 Sep 2021, at 3:46 AM, Eliot Lear <lear@ofcourseimright.com
> <mailto:lear@ofcourseimright.com>> wrote:
>> ….
>> There is no evidence that any other design choices on the table at
>> the time would have gotten us transitioned any faster, and a lot of
>> evidence and analysis that the exact opposite is more likely.
>
> Elliot -
>
> If by “design choices” you mean the criteria that we set forth for
> the new protocol (IPng), then that’s potentially true - it’s
> fairly challenging to hypothecate what impact different technical
> criteria would have had on the outcome.
>
> If by “design choices” you mean the tradeoffs accepted in
> selecting a particular candidate protocol and declaring victory,
> then I’d strongly disagree.  I believe that we had the appropriate
> technical criteria for IPng (very nicely compiled and edited by
> Craig Patridge and Frank Kastenholz in RFC1726) and then made
> conscious decisions to disregard those very criteria in order to
> “make a decision” & “move forward.”
>
> All of the IPng proposals where completely deficient with respect
> to transition capabilities.  In the rush to make a IPng
> decision,the actual IPng Transition Criteria [1]  that mandated a
> straightforward transition plan fromIPv4 was simply acknowledged
> and then declared as “resolved" becausewe would
> also simultaneously form some working groups to study all of
> the transition requirements and made good on the transition
> criteria via future deliverables...(deliverables that were
> subsequently not delivered on)
>
> The right answer would have been to formally and critically
> evaluate each of the candidate protocols against the requirements
> and not make any selection until candidate presented itself
> that actually met the required technical criteria. Instead, IPv6
> transition was left as an afterthought for the operator community
> to solve, and thus the battles with the IETF on NAT-based
> transition for nearly two decades to get this basic technical
> requirement met.
>
>
> FYI,
> /John
>
> Disclaimer: my views alone - made from 100% recycled electrons.
>
> ===  [1] The actual IPng Transition criteria (per RFC 1726) are as
> follows -
>
> "
> 5.5 Transition
>
>   CRITERION
>      The protocol must have a straightforward transition plan from the
>      current IPv4.
>
>   DISCUSSION
>      A smooth, orderly, transition from IPv4 to IPng is needed.  If we
>      can't transition to the new protocol, then no matter how wonderful
>      it is, we'll never get to it.
>
>      We believe that it is not possible to have a "flag-day" form of
>      transition in which all hosts and routers must change over at
>      once. The size, complexity, and distributed administration of the
>      Internet make such a cutover impossible.
>
>      Rather, IPng will need to co-exist with IPv4 for some period of
>      time.  There are a number of ways to achieve this co-existence
>      such as requiring hosts to support two stacks, converting between
>      protocols, or using backward compatible extensions to IPv4.  Each
>      scheme has its strengths and weaknesses, which have to be weighed.
>
>      Furthermore, we note that, in all probability, there will be IPv4
>      hosts on the Internet effectively forever.  IPng must provide
>      mechanisms to allow these hosts to communicate, even after IPng
>      has become the dominant network layer protocol in the Internet.
>
>      The absence of a rational and well-defined transition plan is not
>      acceptable.  Indeed, the difficulty of running a network that is
>      transitioning from IPv4 to IPng must be minimized.  (A good target
>      is that running a mixed IPv4-IPng network should be no more and
>      preferably less difficult than running IPv4 in parallel with
>      existing non-IP protocols).
> "
>
> In short:
>
>   1) The protocol must have a straightforward transition plan
>   2) A number of ways to achieve this which are to be explored
>   3) IPng must provide backward-compatibility to IPv4-only hosts
>   4) The absence of a well-defined transition plan is not acceptable
>
> ===

On 16 Sep 2021, at 5:46 AM, Eliot Lear <lear@ofcourseimright.com> wrote:
> It's hard to argue that there was no transition plan. There were in fact at least three transition plans for the selected approach (dual stack, 6to4, and tunneling) some of which have been discarded along the way; while others came to be based on operational experience. Moreover, the only way to really know that a transition mechanism is really going to work is to let it out of the lab. And ALL of the proposals would have suffered the very same transition pains, because just as Jeroen has pointed out, the pain stretched all the way to the application.

Eliot -

The requirement was not for the assertion of multiple “transition plans”, but rather "The protocol must have a straightforward transition plan from the current IPv4.”

"A straightforward plan” – singular. If you have a link to that plan, please provide it, but until such time I’ll stay with my understanding of events (that being that we completely dropped the ball with regard to providing the operator community with a meaningful transition plan.)
> I don't think it's reasonable to argue that we should have waited for some other mythical better proposal to come along. I don't recall anyone arguing for that at the time, and there's no reason to believe that such a mythical proposal would have ever come to be in any foreseeable time frame. In fact Erik Fair, Dave Crocker, Tom Kessler and I argued the very opposite, that we were digging ourselves a hole with NAT. Your argument at the time (Interop '95, Vegas) was that the IETF didn't have the right to dictate address usage to deployments. True enough, but then people shouldn't hang their woes on the IETF.
>
Sorry, I was on the IPng Directorate, and there were indeed arguments that we lacked meaningful transition strategy, and that the fig leaf of shipping the responsibility off to “to-be-defined” working groups was irresponsible.
> As I mentioned earlier, the fundamental issue was that there were no ng proposals that were in fact substitutable resources for v4, and NAT was. From there, economics has ruled, arguments be damned.
>
As predicted - "As currently envisioned, IPng may not be ambitious enough in the delivery of new capabilities to compete against IPv4 and the inevitable arrival of network address translation devices. In order to meet the requirement for “viability in the marketplace', IPng needs to deliver clearly improved functionality over IPv4 while offering some form transparent access between the IPv4 and IPng communities once IPv4 address depletion has occurred.”

Sorry, but as the sole “network operator” on the IPng Directorate who lived through thru convenient papering over of the transition requirement firsthand, I’ll have to concur with Randy Bush’s take on this one -

>> "real compatibility with ipv4 was disdained. the transition plan was dual stack and v4 would go away in a handful of years. the 93 transition mechanisms were desperate add-ons when v4 did not go away. and dual stack does not scale, as it requires v4 space proportional to deployed v6 space."
>>
>> we are left to make the mess work for the users, while being excoriated for not doing it quickly or well enough, and for trying to make ends meet financially.”

Anyone who wants to argue that IPng had a viable transition plan best put a hard link to the documented plan in their reply - trying to argue the point without actually citing the alleged “straightforward plan" is just embarrassing.

Thanks,
/John

p.s. Disclaimer: my views alone (although likely shared by many operators upon hearing silence in response to the question: “Okay, how is this transition really supposed to work?”)

John you were not the "sole network operator" on the directorate.[1] 
And I'm not saying that there weren't arguments, but I am saying that
nobody said, “wait for something better.” Rather, everyone was arguing
for their preferred approach out of the ones I mentioned.

Eliot

[1] https://www.sobco.com/ipng/directorate.minutes/bigten.5.19.94


On 16.09.21 14:10, John Curran wrote:
> On 16 Sep 2021, at 5:46 AM, Eliot Lear <lear@ofcourseimright.com
> <mailto:lear@ofcourseimright.com>> wrote:
>> It's hard to argue that there was no transition plan.  There were in
>> fact at least three transition plans for the selected approach (dual
>> stack, 6to4, and tunneling) some of which have been discarded along
>> the way; while others came to be based on operational experience.
>> Moreover, the only way to really know that a transition mechanism is
>> really going to work is to let it out of the lab.  And ALL of the
>> proposals would have suffered the very same transition pains, because
>> just as Jeroen has pointed out, the pain stretched all the way to the
>> application.
>
> Eliot -
>
> The requirement was not for the assertion of multiple “transition
> plans”, but rather "The protocol must have a straightforward
> transition plan from the current IPv4.”
>
> "A straightforward plan” – singular.  If you have a link to that plan,
> please provide it, but until such time I’ll stay with my understanding
> of events (that being that we completely dropped the ball with regard
> to providing the operator community with a meaningful transition plan.)
>>
>> I don't think it's reasonable to argue that we should have waited for
>> some other mythical better proposal to come along.  I don't recall
>> anyone arguing for that at the time, and there's no reason to believe
>> that such a mythical proposal would have ever come to be in any
>> foreseeable time frame.  In fact Erik Fair, Dave Crocker, Tom Kessler
>> and I argued the very opposite, that we were digging ourselves a hole
>> with NAT.  Your argument at the time (Interop '95, Vegas) was that
>> the IETF didn't have the right to dictate address usage to
>> deployments.  True enough, but then people shouldn't hang their woes
>> on the IETF.
>>
> Sorry, I was on the IPng Directorate, and there were indeed arguments
> that we lacked meaningful transition strategy, and that the fig leaf
> of shipping the responsibility off to “to-be-defined” working groups
> was irresponsible.
>>
>> As I mentioned earlier, the fundamental issue was that there were no
>> ng proposals that were in fact substitutable resources for v4, and
>> NAT was. From there, economics has ruled, arguments be damned.
>>
> As predicted - "As currently envisioned, IPng may not be ambitious
> enough in the delivery of new capabilities to compete against IPv4 and
> the inevitable arrival of network address translation devices.  In
> order to meet the requirement for “viability in the marketplace', IPng
> needs to deliver clearly improved functionality over IPv4 while
> offering some form transparent access between the IPv4 and IPng
> communities once IPv4 address depletion has occurred.”
>
> Sorry, but as the sole “network operator” on the IPng Directorate who
> lived through thru convenient papering over of the transition
> requirement firsthand, I’ll have to concur with Randy Bush’s take on
> this one -
>
>>> "real compatibility with ipv4 was disdained.  the transition plan
>>> was dual stack and v4 would go away in a handful of years.  the 93
>>> transition mechanisms were desperate add-ons when v4 did not go
>>> away. and dual stack does not scale, as it requires v4 space
>>> proportional to deployed v6 space."
>>>
>>> we are left to make the mess work for the users, while being
>>> excoriated for not doing it quickly or well enough, and for trying
>>> to make ends meet financially.”
>
> Anyone who wants to argue that IPng had a viable transition plan best
> put a hard link to the documented plan in their reply - trying to
> argue the point without actually citing the alleged  “straightforward
> plan" is just embarrassing.
>
> Thanks,
> /John
>
> p.s.  Disclaimer: my views alone (although likely shared by many
> operators upon hearing silence in response to the question:  “Okay,
> how is this transition really supposed to work?”)
>
>

>
>
>
>
> This has nothing to do with IPv6, of course, other than that modern phones
> use
> VoLTE so within a mobile carrier's network your voice call is probably
> handled
> using IPv6 transport.
>
> Good point John.

A lot of folks missed that ipv6 absorbed the scale growth in mobile, and
mobile is what most eyeballs and be big content consider the internet to
be. And, yes, mobile voice is called VoLTE and is most commonly deployed in
the usa with ipv6.

And most internet is called youtube / fb, and that is ipv6 too.

This is where i live and work , 87% of mobiles on v6, voice and data

https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/CombinedUSMobileCarriers.png

This is where nanog seems to be (old man yells at cloud meme)

https://static.wikia.nocookie.net/memepediadankmemes/images/0/01/297.jpg/revision/latest?cb=20180908193511

I don’t see the failure of ipv6 in 2021. It is globally deployed, providing
global address, to billions of things and PB/s of content

There are laggards in adopting v6, but they have not stopped the frontier
of internet to reaching billions of people and things.

> On Sep 16, 2021, at 9:23 AM, Ca By <cb.list6@gmail.com> wrote:
>
>
>
>
> This has nothing to do with IPv6, of course, other than that modern phones use
> VoLTE so within a mobile carrier's network your voice call is probably handled
> using IPv6 transport.
>
> Good point John.
>
> A lot of folks missed that ipv6 absorbed the scale growth in mobile, and mobile is what most eyeballs and be big content consider the internet to be. And, yes, mobile voice is called VoLTE and is most commonly deployed in the usa with ipv6.
>
> And most internet is called youtube / fb, and that is ipv6 too.
>
> This is where i live and work , 87% of mobiles on v6, voice and data
>
> https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/CombinedUSMobileCarriers.png
>
> This is where nanog seems to be (old man yells at cloud meme)
>
> https://static.wikia.nocookie.net/memepediadankmemes/images/0/01/297.jpg/revision/latest?cb=20180908193511
>
> I don’t see the failure of ipv6 in 2021. It is globally deployed, providing global address, to billions of things and PB/s of content
>
> There are laggards in adopting v6, but they have not stopped the frontier of internet to reaching billions of people and things.
>


Yeah, I think this is the thing that I see people most often missing. Yes your provider may not be doing IPv6, but many applications and providers may yet be IPv6 internally or IPv6 to the popular content.

I also say the number of people who store an IP as integer in a mysql(mariadb) backend is not to be underestimated.

I still see some people doing the split up the IPv6 to store it in multiple columns thing even in 2021 which is disappointing as it shows this backwards/legacy thinking.

If you’re seeing majority IPv4 bits, you likely have some choke point (CGN/FW) or similar gateway on the content side that needs a major update. I saw a post yesterday that someone used a unicode char to add an account nickname at their bank and it caused the entire bank to pause and them to get a phone call. Not sure if it’s true, but it rings true.

Be the one enabling the next-generation access and you’ll similarly see graphs like the mobile carriers see.

- Jared

> On Sep 16, 2021, at 06:35 , Jared Mauch <jared@puck.nether.net> wrote:
>
>
>
>> On Sep 16, 2021, at 9:23 AM, Ca By <cb.list6@gmail.com> wrote:
>>
>>
>>
>>
>> This has nothing to do with IPv6, of course, other than that modern phones use
>> VoLTE so within a mobile carrier's network your voice call is probably handled
>> using IPv6 transport.
>>
>> Good point John.
>>
>> A lot of folks missed that ipv6 absorbed the scale growth in mobile, and mobile is what most eyeballs and be big content consider the internet to be. And, yes, mobile voice is called VoLTE and is most commonly deployed in the usa with ipv6.
>>
>> And most internet is called youtube / fb, and that is ipv6 too.
>>
>> This is where i live and work , 87% of mobiles on v6, voice and data
>>
>> https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/CombinedUSMobileCarriers.png
>>
>> This is where nanog seems to be (old man yells at cloud meme)
>>
>> https://static.wikia.nocookie.net/memepediadankmemes/images/0/01/297.jpg/revision/latest?cb=20180908193511
>>
>> I don’t see the failure of ipv6 in 2021. It is globally deployed, providing global address, to billions of things and PB/s of content
>>
>> There are laggards in adopting v6, but they have not stopped the frontier of internet to reaching billions of people and things.
>>
>
>
> Yeah, I think this is the thing that I see people most often missing. Yes your provider may not be doing IPv6, but many applications and providers may yet be IPv6 internally or IPv6 to the popular content.
>
> I also say the number of people who store an IP as integer in a mysql(mariadb) backend is not to be underestimated.

Nothing wrong with this as long as it’s a 128 bit integer. ;-)

> I still see some people doing the split up the IPv6 to store it in multiple columns thing even in 2021 which is disappointing as it shows this backwards/legacy thinking.

UGH… I haven’t seen that in a while, sad to hear it’s still going on.

Owen

Owen DeLong wrote:

>>> You mean anywhere in the world. Calls to my number reach my cell phone no
>>> matter where I go.
>>
>> You are confusing number portability and call forwarding.

> Not exactly$B!D(B He is confusing number portability and roaming.

Wrong.

Mobility including, but not limited to, roaming (international
roaming of mobile phones is assumed) needs

1) access foreign environment

2) route packets to foreign network

Roaming today perform 1) by foreign network (often through
a chain of AAA) and 2) by home carrier as call forwarding, which
is very similar to IP mobility.

As we are talking about "Calls to my number reach my cell phone",
"call forwarding" is the most properly scoped explanation.

It should be noted that many on this thread misunderstand that
2) destroys route aggregation. However, call forwarding from
home carrier for roaming and mobility tunnel from home agent
for IP mobility is performed by end system without burdening
routing system of intermediate network and just scale.

Instead, many have wrongly assumed a poor alternative
to have a separate routing table entry for each mobile host
in global routing table, which does not scale.

Masataka Ohta

On 16 Sep 2021, at 8:58 AM, Eliot Lear <lear@ofcourseimright.com> wrote:
>
> John you were not the "sole network operator" on the directorate.[1] https://www.sobco.com/ipng/directorate.minutes/bigten.5.19.94 <https://www.sobco.com/ipng/directorate.minutes/bigten.5.19.94>
Eliot -

You are referencing the minutes of a rather large workshop (the Big10 confab) that had far more attendees that the IPng Directorate itself.

The list of directorate members is contained in RFC 1752 "The Recommendation for the IP Next Generation Protocol” in Appendix B, and is listed below for reference –

Appendix B - IPng Area Directorate

J. Allard - Microsoft <jallard@microsoft.com>
Steve Bellovin - AT&T <smb@research.att.com>
Jim Bound - Digital <bound@zk3.dec.com>
Ross Callon - Wellfleet <rcallon@wellfleet.com>
Brian Carpenter - CERN <brian.carpenter@cern.ch>
Dave Clark - MIT <ddc@lcs.mit.edu >
John Curran - NEARNET <curran@nic.near.net>
Steve Deering - Xerox <deering@parc.xerox.com>
Dino Farinacci - Cisco <dino@cisco.com>
Paul Francis - NTT <francis@slab.ntt.jp>
Eric Fleischmann - Boeing <ericf@atc.boeing.com>
Mark Knopper - Ameritech <mak@aads.com>
Greg Minshall - Novell <minshall@wc.novell.com>
Rob Ullmann - Lotus <ariel@world.std.com>
Lixia Zhang - Xerox <lixia@parc.xerox.com>

> And I'm not saying that there weren't arguments, but I am saying that nobody said, “wait for something better.” Rather, everyone was arguing for their preferred approach out of the ones I mentioned.
>

Also incorrect. The preferred transition approached of the recommended IPng candidate (SIPP) was IPAE, and that was actually dead-on-arrival. Per the same recommendation RFC -

The biggest problem the reviewers had with SIPP was with IPAE, SIPP's
transition plan. The overwhelming feeling was that IPAE is fatally
flawed and could not be made to work reliably in an operational
Internet.

This is what lead to the conception of the infamous Simple SIPP Transition (SST) approach as a stand-in Transition plan in order to allow for a decision to be made – and creation of IETF working groups to develop the respective transition mechanisms. At the time of the IPng decision there was actually _no_ “transition plan” – as the very mechanisms that were to be used (and that were eventually discarded as unworkable) were just placeholders for future IETF work.

Thanks,
/John

p.s. My views alone. Warning: contents may be hot / burn hazard

Baldur Norddahl wrote:

>>>>>> But in fact with local number portability, you cannot rely
>>> ^^^^^^^^^^^^^^^^^^^^^^^^

>>> You are confusing number portability and call forwarding

> I am not confusing anything. Nobody said anything about number
> portability in the above quote.

But, Shane Ronan wrote:

> But in fact with local number portability, you cannot rely on the
> county code to tell you where to route a telephone call anymore.
> Which is many calls result in a data dip to provide you the routing
> information from a central repository.

OK?

> Just pointing out that some assumptions about how voice call works is
> not true. Nor would it be smart to send traffic to another part of
> the world unnecessarily. Local calls stay local even when roaming.
> Please remember that signaling and voice is separate in the telco
> world which is why it compares poorly with IP. Except for the LISP
> protocol which does something similar.

I'm afraid you have too much complicated view on phone networks
and the Internet.

Masataka Ohta

John Curran wrote:

> If by "design choices" you mean the tradeoffs accepted in selecting a
> particular candidate protocol and declaring victory, then I$B!G(Bd
> strongly disagree.

What actually happened is that SIP was chosen but modified
by IPng directorates to pretend, for political purposes, IPng
were a merger of all the proposals only to make the result
totally unusable, during which address length was extended
from 8B to 16B to accommodate so infamous XNS style auto
configuration.

Masataka Ohta

On 16 Sep 2021, at 11:33 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> John Curran wrote:
>
>> If by "design choices" you mean the tradeoffs accepted in selecting a
>> particular candidate protocol and declaring victory, then I’d
>> strongly disagree.
>
> What actually happened is that SIP was chosen but modified
> by IPng directorates to pretend, for political purposes, IPng
> were a merger of all the proposals only to make the result
> totally unusable, during which address length was extended
> from 8B to 16B to accommodate so infamous XNS style auto
> configuration.

Masataka - You are correct, in that the design choices made for the final “IPng" weren’t actually any of the proposals as submitted, but rather an interesting compromise creation.

(My negative answer to Eliot’s "There is no evidence that any other design choices on the table at the time would have gotten us transitioned any faster, and a lot of evidence and analysis that the exact opposite is more likely” was simply noting that the design choices made about the “straightforward transition plan" was effectively to punt – i.e. despite lacking one, choosing declare victory anyway and leave it as an exercise for the reader. It’s fairly obvious that different choices here could have made a very significant difference in IPng deployment trajectory.)

Thanks,
/John

Disclaimer: my views alone - (no one else would wanted them…)

your memory of the procedural details is better than mine. you have my
sympathies. i was focused on the technical disater that has cost us
decades. but folk who i still consider friends were willing to throw
dren at the wall hoping it would stick so the ietf/iana was not taking
crap in the press for the looming disaster of running out of address
space. and here we are, decades later, still having to listen to
hysteria about running out of address space; just not in the new york
times. problem solved, eh?

we had to invent dnssec to find something that would deploy more slowly,
and with more gl!tches, than ipv6.

and have you seen what's going on in the 6man wg?!?!

randy

> On Sep 11, 2021, at 13:17 , John R. Levine <johnl@iecc.com> wrote:
>
>>> Indeed. They would send postcards to all their customers saying
>>> "Comcast has said they will cut off your access to Netflix on April 1,
>>> Call their president's office at 1-800-xxx-xxxx and tell them what you think."
>>
>> Nope… Netflix is fully available on IPv6 and actually looks forward to ISPs
>> doing this.
>
> OK, then Disney+ or Hulu or whoever. Peering wars never end well. Don't even need postcards, just stick the flyer in with the bill.

Is that really cheaper and easier than deploying IPv6? Really?

>> Now Amazon might send post cards saying “Comcast has said that they
>> will cut off your access to our store…”, but I suspect that the cost of such
>> a campaign and the collateral damage would be well in excess of the
>> cost of just adding IPv6 to their service.
>
> AWS has perfectly good support for IPv6 so they must have business reasons to stick with v4. But I expect the cost of putting up banners on the homepage saying to call your ISP, for people coming through the relevant ISP, would be pretty cheap, and Amazon's customers appear to like their accounts and their Prime quite a lot. Again, peering wars never end well.

This isn’t really the same as a peering war, however. They can’t really claim Comcast is going to cut you off. They’d have to admit that Comcast is going to start charging more for…

Remember, I didn’t suggest that Comcast turn off IPv4… I suggested that Comcast start passing along some of the added expense of maintaining IPv4 connectivity to the customers that want it.

> This ignores the question of what the advantage to the ISP would be other than bloody-mindedness. The world is not going to abandon IPv4 any time soon and the last time I looked, the cost of routing packets is the same regardless of which header they have.

You haven’t looked in depth, then. The cost of routing packets is the same. The cost of dealing with address shortages and supporting/maintaining the various hacks and workarounds intended to help mitigate that issue continues to increase.

As I have repeatedly stated, the perverse incentive here that drives things is that those who lag aren’t bearing most of the costs. Instead, like toxic polluters, they are able to externalize those costs to developers, eyeball ISPs, CDNs, and others while continuing the status quo.

The flyer in the bill thing works both ways. Comcast could just as easily put in a flyer that points out the facts of the situation:

1. There is a flaw in the addressing scheme currently in use in that it doesn’t have enough addresses for everyone.
2. There is a new-iso addressing scheme that has been in use for more than 20 years now.
3. Many services are available through either addressing scheme today.
4. The cost of preserving connectivity to the old addressing scheme is continuing to increase.
5. As a result, starting on <X date in the future>, we will be passing some of those costs on to customers who still
want to use the old addressing scheme in the form of an “IPv4 Surcharge”.
6. For more details and to see a list of popular services that do and don’t currently work with the new addressing scheme,
check <link>here</link>.

If the surcharge starts out at something silly like $2/month or even $5/month, I bet most customers just pay it.

Large chunks of the world (those that have IPv6 deployed) would love to abandon or mostly abandon IPv4 as soon
as possible. That possibility isn’t defined as “when everybody has IPv6”. It’s defined (for at least eyeball ISPs) as
“When enough of the content providers our customers care about are on IPv6 that the business we lose by turning
off IPv4 costs less than maintaining IPv4 for all of our customers.”

That day may not be today, but it is coming and I don’t think it’s as far off as you imagine.

The soft way for eyeball ISPs to approach that is to start passing along some of those costs to their customers by
making IPv4 an opt-in add-on to their Internet Service with a nominal charge. Sort of like the fee I used to pay when
I had cable TV service where they charged me ~$5 every month for “access to local sports” which I didn’t want
and repeatedly asked them to stop.

Owen

>> OK, then Disney+ or Hulu or whoever. Peering wars never end well. Don't even need postcards, just stick the flyer in with the bill.
>
> Is that really cheaper and easier than deploying IPv6? Really?

The cost of putting flyers in the bills rounds to zero, so yes, really.
I expect these companies all have plans to support v6 eventually, someday,
once they're retired and replaced all of the old junk that handles v6
poorly or not at all, but you know about accountants and depreciation.

> Remember, I didn’t suggest that Comcast turn off IPv4… I suggested that
> Comcast start passing along some of the added expense of maintaining
> IPv4 connectivity to the customers that want it.

Ah, so they should start adding a gratuitous charge for a feature they
have always provided as part of the basic service. How many milliseconds
do you think it'll take for the Congress to haul their CEO in front of a
committee?

> That day may not be today, but it is coming and I don’t think it’s as far off as you imagine.

Nothing personal, but people have been saying exactly that for about 25
years now. Please forgive me if I continue not to hold my breath.

R's,
John

> On Sep 17, 2021, at 21:03 , John R. Levine <johnl@iecc.com> wrote:
>
>>> OK, then Disney+ or Hulu or whoever. Peering wars never end well. Don't even need postcards, just stick the flyer in with the bill.
>>
>> Is that really cheaper and easier than deploying IPv6? Really?
>
> The cost of putting flyers in the bills rounds to zero, so yes, really. I expect these companies all have plans to support v6 eventually, someday, once they're retired and replaced all of the old junk that handles v6 poorly or not at all, but you know about accountants and depreciation.

Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai.
>
>> Remember, I didn’t suggest that Comcast turn off IPv4… I suggested that Comcast start passing along some of the added expense of maintaining IPv4 connectivity to the customers that want it.
>
> Ah, so they should start adding a gratuitous charge for a feature they have always provided as part of the basic service. How many milliseconds do you think it'll take for the Congress to haul their CEO in front of a committee?

I doubt that their CEO would get hauled in at all. Even if he did, I would think this would be one of the easiest hearings ever for them as literally, they could easily show the increased costs of continuing to provide IPv4 services and note that they didn’t want to jack up everyone’s bills to support the customers that need IPv4, so they’ve made IPv4 an opt-in value added service instead of punishing customers that don’t patronize laggards. (I’m sure their lawyers would say it better, I’m blunt).

>> That day may not be today, but it is coming and I don’t think it’s as far off as you imagine.
>
> Nothing personal, but people have been saying exactly that for about 25 years now. Please forgive me if I continue not to hold my breath.

Nope… People have been saying that IPv4 would stop being the lingua franca of the internet for 25+ years. There’s still hope for that, but I agree it’s been disappointingly and tragically slow.

OTOH, the idea of doing cost-recovery on the additional nuisance that is IPv4 is relatively novel and hasn’t been floated that I’m aware of more than 3 or 4 years ago.

Bottom line is that IPv4 continues to increase costs for eyeball providers. They’ll need to recover that cost. At some point, the cost will be enough of a differentiator that customers willing to accept v6-only service will get a break.

If they don’t do it as an IPv4 surcharge, they could do it as an IPv6-only discount… That might even be better. Either way, the net effect is the same… Suddenly, customers have a monetary advantage to push their content providers toward providing v6.

Owen

It appears that Owen DeLong via NANOG <owen@delong.com> said:
>> The cost of putting flyers in the bills rounds to zero, so yes, really. I expect these companies all have plans
>to support v6 eventually, someday, once they're retired and replaced all of the old junk that handles v6 poorly or
>not at all, but you know about accountants and depreciation.
>
>Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of
>adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai.

I wasn't talking about switches and routers. I was talking about every single piece of software and equipment that
they use for support and marketing and customer service and all the other stuff that big companies do.

As I may have said once or twice, eventuallly it'll all be replaced so it works on IPv6 but we're not holding our breath.

R's,
John

On Sat, Sep 18, 2021 at 2:39 PM John Levine <johnl@iecc.com> wrote:

> It appears that Owen DeLong via NANOG <owen@delong.com> said:
> >> The cost of putting flyers in the bills rounds to zero, so yes, really.
> I expect these companies all have plans
> >to support v6 eventually, someday, once they're retired and replaced all
> of the old junk that handles v6 poorly or
> >not at all, but you know about accountants and depreciation.
> >
> >Unless their infrastructure runs significantly on hardware and software
> pre-2004 (unlikely), so does the cost of
> >adding IPv6 to their content servers. Especially if they’re using a CDN
> such as Akamai.
>
> I wasn't talking about switches and routers. I was talking about every
> single piece of software and equipment that
> they use for support and marketing and customer service and all the other
> stuff that big companies do.
>
> As I may have said once or twice, eventuallly it'll all be replaced so it
> works on IPv6 but we're not holding our breath.
>

Glad you noted this. Thinking this was/is purely a hardware cycle problem
related to normal/forced upgrade strategies. On that point, most hardware
I know of from 2004 in larger networks is long fully depreciated and
sweating assets 15+ years can happen, but I don't personally think this is
the biggest issue.

As you noted John, its the plethora of software, support systems, tooling,
and most important in many environments - legacy customer management and
provisioning systems that can be the limiting factor. I recall looking
back when leading IPv6 turn-up, those were the biger problems to solve
for. Often such systems are extremely expensive to touch and working on
them required prioritization against direct revenue generating projects
(opportunity cost) . Replacing routers was just a money problem.

I am by far not saying I agree with choices made by hold-outs, but I also
understand this is for many, not just an engineering problem to solve.

regards,

Victor K


>
> R's,
> John
>

> As you noted John, its the plethora of software, support systems, tooling,
> and most important in many environments - legacy customer management and
> provisioning systems that can be the limiting factor. ...

Just looking around my office, I have a Cisco SPA112 two-port ATA. It's
been discontinued but Cisco says they will support it through 2025 and
they shipped a firmware update in 2019. It works fine on IPv4 behind a
NAT. It has no v6 support at all and never will. Multiply that by a
zillion and you can see that IPv4 isn't going away any time soon.

Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Fri, 17 Sep 2021 21:15:00 -0700
Owen DeLong via NANOG <nanog@nanog.org> wrote:

> Unless their infrastructure runs significantly on hardware and
> software pre-2004 (unlikely), so does the cost of adding IPv6 to
> their content servers. Especially if they’re using a CDN such as
> Akamai.

Owen, I have nothing but respect for you, but this is a
fantasy... I provide FTTx services to business and residential. I had
to fight, and grind, and test for over a year to get a mix of hardware
and software that would provide anything resembling IPv6 equivalent
services to most of our customers. The only devices in my network that
worked with few problems are my Adtran gpon/xgs-pon cards (try to find
DHCPv6 option-18 support on anything else)... EVERYTHING else I used
from my Juniper routers to customer CPE had to go through more rounds
of testing and bug fixes than I could name - for years.

I've provided static v6 services to business customers for a
long time (with no takers), but dynamic, scalable residential services
was very hard. There are still holes in our infrastructure because most
vendors I am dealing with are doing very little to no v6 testing and
still think I am a weirdo for asking for it. Every ACS vendor is
either just now working on it, or thinks they have it until I point out
to them that they don't. There have been some vendors that were good
to work with: Juniper fixed the bugs I reported once I was able to
prove to them it really was on there end (DHCPv6 relay server). ZyXel
has been good to work with; they care about and fix bugs that are
reported.

There are also big vendors I won't work with any more because
they do not have full v6 support for features I need, and they have no
plans to have it. I'm not a big enough customer for them to care about
what I want. I have devices with 2 year old software and zero v6
support and none is coming ever; these are not no-name vendors; they
are big.

People who think modern equipment is ready to provide native
dual-stack services at scale to their customers are either using stuff
very similar to mine, or are simply not doing it yet or have a lot of
compromises.

--TimH

I concur that the problem is not a routing hardware problem. It's a
perception problem with the various ISPs. I have fiber service with AT&T.

My little server farm endpoints all have IPv6 addresses, including the
edge router. I also have a plan to allocate IPv6 addresses to my LAN
devices, and to protect the LAN devices from outside interference by
rules in the NFTABLES firewall that include connection tracking on
outbound requests. (IPv4 will still use NAT to keep nefarious people
from probing my internals.)

Specifically, when I was doing my mail server refresh (moving from Red
Hat to Canonical) I decided it was time to offer IPv6 connectivity in
the mail server to "future proof" my setup. That included adding AAAA
records in my DNS zone files. Failure! The issues:

1. I learned that there are no "static addresses" in IPv6, as far as
AT&T was concerned. By all appearances, though, the IPv6 /64 is
relatively static, for now, similar to the way that early cable modem
deployments kept the same IPv4 addresses. (Until the cable people
started forcing changes on DHCP lease renewal, that is.)

2. My request for PTR records was denied, which means I can't satisfy
Best Practices for a mail server in the IPv6 space. No PTR records, no
redirection of ip6.apra space, nothing. I include AT&T's refusal below.

3. I don't know how to get an IPv6 allocation from ARIN, how to request
AT&T to route it, or how to deal with the DNS server issues. Oh, I know
how to configure BIND9; I would prefer using a 24/7/365 provider. For
example, my master zone files are with Register.com, so if my circuit
goes down the name resolution still happens. Register.com appears not
to provide reverse-DNS PTR zone support (in6.arpa). A Google search
turned up NOTHING for in6.arpa hosting.

That tells me that IPv6 is not "Internet Ready" for small users. Given
the level of FU responses I get trying to work with it, I will stop
banging my head against the wall.

So I stick with IPv4, because that will be the "standard" until the day
I die, as far as I can tell.

(I removed the AAAA record, so as not to confuse mail server that DO
operate IPv6.)

> Subject: RE: Need IPv6 PTR record for my IPv6 mail server
> Date: Mon, 19 Jul 2021 12:52:53 +0000
> From: Prov-DNS <prov-dns@att.com>
> To: Prov-DNS <prov-dns@att.com>, att@satchell.net <att@satchell.net>
>
>
> Hello
> We don't process DNS request on IPv6 addresses. We only process DNS
> request on IPv4 static assigned addresses. If you would like us to
> process a DNS request for you on a IPv4 address please provide the
> following information.
>
> IPv4 address you would like the record created for Host name you would > like that IP address pointed to
>
> Thanks
> Michael AT&T Prov-DNS
>
> -----Original Message-----
> From: Stephen Satchell <att@satchell.net>
> Sent: Friday, July 16, 2021 5:42 PM
> To: DNSUpdates cB <g12988@att.com>
> Subject: Need IPv6 PTR record for my IPv6 mail server
>
> Here is the record I need inserted into your ip6.arpa DNS zone:
>
>>
2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. 0
IN PTR smtp.satchell.net.
>
> This is the result from the question section of a dig(1) request for the PTR record for my IPv6 address 2600:1700:79b0:ddc0::32, and the fully-qualified domain name of the server.
>
> You can verify the information using dig smtp.satchell.net AAAA and
> checking the reverse.
>
> This is the only server in my collection that needs the IPv6 pointer.

I mostly agree with this. Even new hardware like eero doesn't do v6 by default. It's just off. So many things are like this. It's nice that LTE and other deployments have v6 by default. Last time I knew providers like t mobile are great but their MVNOs like Ultra Mobile do not do v6.

All this and we will get there. I'm expecting another decade or two though.

Sent from my TI-99/4a

> On Sep 18, 2021, at 4:29 PM, John R. Levine <johnl@iecc.com> wrote:
>
> IPv4 isn't going away any time soon.

Also, I realise I'm kinda taking your comment out of context and
jumping on it to harp on my favorite pet peeve, so, yeah, sorry about
that.

--TimH

On Sat, 18 Sep 2021 13:28:02 -0700
Tim Howe <tim.h@bendtel.com> wrote:

> On Fri, 17 Sep 2021 21:15:00 -0700
> Owen DeLong via NANOG <nanog@nanog.org> wrote:
>
> > Unless their infrastructure runs significantly on hardware and
> > software pre-2004 (unlikely), so does the cost of adding IPv6 to
> > their content servers. Especially if they’re using a CDN such as
> > Akamai.
>
> Owen, I have nothing but respect for you, but this is a
> fantasy... I provide FTTx services to business and residential. I had
> to fight, and grind, and test for over a year to get a mix of hardware
> and software that would provide anything resembling IPv6 equivalent
> services to most of our customers. The only devices in my network that
> worked with few problems are my Adtran gpon/xgs-pon cards (try to find
> DHCPv6 option-18 support on anything else)... EVERYTHING else I used
> from my Juniper routers to customer CPE had to go through more rounds
> of testing and bug fixes than I could name - for years.
>
> I've provided static v6 services to business customers for a
> long time (with no takers), but dynamic, scalable residential services
> was very hard. There are still holes in our infrastructure because most
> vendors I am dealing with are doing very little to no v6 testing and
> still think I am a weirdo for asking for it. Every ACS vendor is
> either just now working on it, or thinks they have it until I point out
> to them that they don't. There have been some vendors that were good
> to work with: Juniper fixed the bugs I reported once I was able to
> prove to them it really was on there end (DHCPv6 relay server). ZyXel
> has been good to work with; they care about and fix bugs that are
> reported.
>
> There are also big vendors I won't work with any more because
> they do not have full v6 support for features I need, and they have no
> plans to have it. I'm not a big enough customer for them to care about
> what I want. I have devices with 2 year old software and zero v6
> support and none is coming ever; these are not no-name vendors; they
> are big.
>
> People who think modern equipment is ready to provide native
> dual-stack services at scale to their customers are either using stuff
> very similar to mine, or are simply not doing it yet or have a lot of
> compromises.
>
> --TimH