Mailing List Archive

1 2 3 4 5 6 7 8 9 ... 11  View All
Re: IPv6 woes - RFC [ In reply to ]
>
> 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
Re: IPv6 woes - RFC [ In reply to ]
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.
Re: IPv6 woes - RFC [ In reply to ]
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.
Re: IPv6 woes - RFC [ In reply to ]
>
> 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
Re: IPv6 woes - RFC [ In reply to ]
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.
Re: IPv6 woes - RFC [ In reply to ]
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
Re: IPv6 woes - RFC [ In reply to ]
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
Re: IPv6 woes - RFC [ In reply to ]
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
Re: IPv6 woes - RFC [ In reply to ]
> 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
Re: IPv6 woes - RFC [ In reply to ]
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.
Re: IPv6 woes - RFC [ In reply to ]
> 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
Re: IPv6 woes - RFC [ In reply to ]
> 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
Re: IPv6 woes - RFC [ In reply to ]
> 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
Re: IPv6 woes - RFC [ In reply to ]
* 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.
Re: IPv6 woes - RFC [ In reply to ]
> 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
Re: IPv6 woes - RFC [ In reply to ]
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
Re: IPv6 woes - RFC [ In reply to ]
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)
Re: IPv6 woes - RFC [ In reply to ]
> 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
Re: IPv6 woes - RFC [ In reply to ]
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
Re: IPv6 woes - RFC [ In reply to ]
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
Re: IPv6 woes - RFC [ In reply to ]
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
Re: IPv6 woes - RFC [ In reply to ]
> 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
Re: IPv6 woes - RFC [ In reply to ]
> 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
Re: IPv6 woes - RFC [ In reply to ]
> 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
Re: IPv6 woes - RFC [ In reply to ]
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

1 2 3 4 5 6 7 8 9 ... 11  View All