Re: IPv6 woes - RFC

[Valdis Klētnieks]

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 breakup was keeping the accounting records
so they could bill the customer)


pgpaqJDQHc0BT.pgp
Description: PGP signature

Re: IPv6 woes - RFC

[John Levine]

It appears that Bill Woodcock  said:
>> The next thought was SMTP
>
>I assume someone’s tried using MX record precedence to do this?   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  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

[Owen DeLong via NANOG]

> On Sep 8, 2021, at 11:57 , Niels Bakker  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

[Niels Bakker]

* 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

[Owen DeLong via NANOG]

> 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

[Owen DeLong via NANOG]

> On Sep 8, 2021, at 00:49 , Mark Tinka  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

[Owen DeLong via NANOG]

> On Sep 7, 2021, at 23:50 , Saku Ytti  wrote:
> 
> On Tue, 7 Sept 2021 at 19:51, Owen DeLong  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: if not v6, what?

[Owen DeLong via NANOG]

> On Sep 7, 2021, at 19:51 , Masataka Ohta  
> wrote:
> 
> Niels Bakker wrote:
> 
>>> As for well known port, we can specify non-default port numbers
>>> in URLs (I'm not sure whether it works for mailto: or not) or.
>>> in the future, things like DNS SRV RRs should be helpful.
>> This absolutely doesn't work.
> 
> Thank you very much for your emotional and unfounded
> comment.

It’s neither. There’s no support for SRV RRs in virtually any of the software
that would need it in order for this to be a viable solution and it does not 
appear
to be coming any time soon.

That’s a fact. Not unfounded and not emotional.

You, yourself admit that mailto: URLs don’t have space for a port number (though
you express uncertainty, I assure you that they don’t).


>> And DNS SRV RRs have roughly zero uptake for stuff that matters (web, email).
> 
> I know SRV and other similar proposals so far are not
> very compatible with URL syntax and should better be
> simplified.

I think the bigger problem is that SRV just hasn’t really caught on and I 
suspect isn’t
likely to.

In reality, the effort to modify all the code to support SRV wouldn’t be 
significantly less
than what is required to do IPv6 which would (mostly) obviate the need for SRV 
as
service-specific IP addresses would be easy to assign. The significant problem 
here,
no matter how many different ways we attempt to hack around it is address 
shortage.
The solution to that is more addresses (i.e. IPv6).

>>> Then, to run servers at home, we only need some not-well-known
>>> ports forwarded, which can be default or value added service of
>>> your local ISP, just like fixed IP addresses today.
> 
>> Oh and we need to work around the whole IP reputation system that governs 
>> email today.
> IP reputation system must evolve to be IP+port reputation
> system, which is not my problem.

ROFLMAO — as if that’s at all likely to happen.

Further, you have the problem that the port side where this matters is ephemeral
meaning that multiple systems (which need different reputations) share the same
source address+port combination, so it doesn’t really help.

No, IP reputation system must evolve to support 128 bit addresses and some level
of heuristic determination of how many of those 128 bits should be applied to a 
given
reputation (probably defaulting to 64 and working left from there).

Owen

Spoofer Report for NANOG for Aug 2021

[CAIDA Spoofer Project]

In response to feedback from operational security communities,
CAIDA's source address validation measurement project
(https://spoofer.caida.org) is automatically generating monthly
reports of ASes originating prefixes in BGP for systems from which
we received packets with a spoofed source address.
We are publishing these reports to network and security operations
lists in order to ensure this information reaches operational
contacts in these ASes.

This report summarises tests conducted within usa, can.

Inferred improvements during Aug 2021:
ASNName   Fixed-By
2120002021-08-01
208188 PUGET-SOUND-NETWORKS   2021-08-04
40676  AS406762021-08-04
19531  NODESDIRECT2021-08-29

Further information for the inferred remediation is available at:
https://spoofer.caida.org/remedy.php

Source Address Validation issues inferred during Aug 2021:
ASNName   First-Spoofed Last-Spoofed
6939   HURRICANE 2016-02-22   2021-08-31
577BACOM 2016-03-09   2021-08-30
209CENTURYLINK-US-LEGACY-QWEST   2016-08-16   2021-08-25
6128   CABLE-NET-1   2016-09-03   2021-08-15
20412  CLARITY-TELECOM   2016-09-30   2021-08-31
6181   FUSE-NET  2016-10-10   2021-08-29
11427  TWC-11427-TEXAS   2016-10-21   2021-08-27
1403   EBOX  2016-11-12   2021-08-19
22898  ATLINK2016-12-16   2021-08-30
701UUNET 2017-06-14   2021-08-27
63296  AWBROADBAND   2017-09-01   2021-08-27
23089  HOTWIRE-COMMUNICATIONS2017-09-30   2021-08-31
1  AKAMAI2018-02-14   2021-08-11
393564 SPOKANE   2018-06-05   2021-08-24
33452  RW2018-09-19   2021-08-24
5078   ONENET-AS-1   2020-04-06   2021-08-28
11525  HRTC  2020-06-27   2021-08-26
56207  Converge  2021-03-26   2021-08-27
13876  FIBER-64  2021-05-20   2021-08-28
2900   WN-AZ 2021-08-24   2021-08-24
8038   6CONNECT  2021-08-30   2021-08-30

Further information for these tests where we received spoofed
packets is available at:
https://spoofer.caida.org/recent_tests.php?country_include=usa,can_block=1

Please send any feedback or suggestions to spoofer-i...@caida.org

Re: if not v6, what?

[Masataka Ohta]

Mark Andrews wrote:


I know SRV and other similar proposals so far are not
very compatible with URL syntax and should better be
simplified.


The only thing difficult to map was non-default ports and that could
easily have been addressed.


That's why simplification is desired. See below.


Remember SRV required a seperate RFC to
specify how to map existing services on to it. HTTPS just prefixed the
label "_”.  That could have easily been done with SRV.

HTTPS and SVBC are just SRV on steroids.


Nothing should be HTTPS specific. What is essentially necessary
is to map:

:["@"]

and

:["@"]":"

to

:["@"]":"

and

:["@"]":"

for which RRs like:

_. MAP  

should be just enough.


But if you insist, UPnP by Microsoft has been implemented
on almost all NAT boxes. There even exists PCP.


But how much has been implemented in CGNs and how many ISP’s
enable it if it is implemented?


As most users are satisfied without port forwarding and even
those who aren't merely need static configuration on CGNs,
why do you bother?

> Getting IPv4 continue to work
> just add layer upon layer of hacks which we are all continuing
> to pay for.

We don't need any new mechanism to keep using IPv4 if users can
accept external servers, which is the usual case for SMTP and DNS.

On the other hand, people still insisting on IPv6 are,
as you can see here, still arguing for hacks, most of which
are well known and already abandoned but, worse, some of
which are new.

Masataka Ohta

Re: IPv6 woes - RFC

[Mark Tinka]

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

[Bill Woodcock]

> On Sep 8, 2021, at 10:24 AM, Bjørn Mork  wrote:
> The next thought was SMTP

I assume someone’s tried using MX record precedence to do this?   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



signature.asc
Description: Message signed with OpenPGP

Re: IPv6 woes - RFC

[Brandon Butterworth]

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

[Saku Ytti]

On Wed, 8 Sept 2021 at 11:24, Bjørn Mork  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

[Bjørn Mork]

Saku Ytti  writes:

> On Tue, 7 Sept 2021 at 19:51, Owen DeLong  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

[Mark Tinka]

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

[Etienne-Victor Depasquale via NANOG]

>
> 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  wrote:

>
>
> On 9/8/21 09:35, Etienne-Victor Depasquale wrote:
>
>
> If the Telecom Infra Project
>  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

[Mark Tinka]

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



If the Telecom Infra Project 
 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

[Mark Tinka]

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

[Etienne-Victor Depasquale via NANOG]

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

[Saku Ytti]

On Wed, 8 Sept 2021 at 10:25, Mark Tinka  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

Re: IPv6 woes - RFC

[Mark Tinka]

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.

Re: IPv6 woes - RFC

[Saku Ytti]

On Tue, 7 Sept 2021 at 19:51, Owen DeLong  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