RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

> 
> Pascal Thubert (pthubert) wrote:
> 
> > You're perfectly correct. This is exactly what the registration would
> > be for. I'm concerned about its adoption that I do not see coming on
> > Wi-Fi/ Ethernet, even for v6 (SLAAC) where the problem is a lot
> > worse*.
> 
> You can't expect people still working primarily on v6 have much sense of
> engineering.

That includes me

> 
> > * APs today snoop DHCP; DHCP is observable and stateful, with a
> > lifetime that allows to clean up. So snooping it is mostly good enough
> > there. The hassle is the SL in SLAAC which causes broadcasts and is
> > not deterministically observable; this problem is specific to IPv6. We
> > already have the registration to avoid snooping DHCP and SLAAC; yet we
> > do not observe any adoption in mainline APs and STAs.
> 
> As broadcast/multicast packets are first sent to APs as unicast packets with
> ACKs, snooping by APs should be reliable at L2.

Well, up to the N retries. After that the stack is not even aware that the 
multicast was not delivered. 

Oh but that's just the beginning of the story; yes we mostly can form an 
initial state and it mostly appears to work and people are mostly satisfied. 
And then you realize:

- there's no way to know how long the device will you that address
- there's no way to know how many addresses the device will form
- there's no way to know how many addresses the device has already formed and 
which (at least MLD can do that)
- there's no clean way to know is an address is still in use (e.g., without 
reviving it in the host stack)
- there's no way to know which is the most recent location of the address 
(unless you have a fine time distribution and that costs)
- there's no way to know if 2 locations are OK (anycast)
- there's no way to know for sure that the claimer is the owner

Snooping DHCP you expect:
- one address per MAC (that's it's pretty limiting but that protects the 
network)
- A MAC address or least a unique ID to differentiate duplicates (but not 
recognize a thief)
- An upper bound for the state lifetime based on the lease

Certainly a bad guy doing impersonation and DOS can play havoc in such network, 
but at least between good guys we get something we can operate.

I'm not saying that snooping DHCP is fully deterministic but it's orders of 
magnitude better than snooping SLAAC when it comes to forming a state like an 
association than SLAAC. Knowing that you base things like EVPN on such state, 
using SLAAC is building on sand.

Ideally you'd want:
- a negotiated contract for a number of addresses with a lifetime, etc
- a provable ownership so we route to the legitimate owner and can do SAVI
- a sense of mobility so we can route the packets to the latest location
- a sense of anycast vs unicast so we can install routing properly based on that
- the capability to indicate whether the address should be redistributed, a 
sense of weight in ECMP, etc...

We've done just that, and with that, we're effectively providing a 
deterministic state that we can redistribute in routing or ARP/ND proxy.

In the case of EVPN that gives this:
https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling

Then again, retrofitting the ND registration for IPv4 addresses is piece of 
cake, but IPv4 is DHCP only and the pain does not really feel; so people may 
not be inclined to make the steps for IPv4. To be seen.

> 
> So, by snooping DAD, which is ugly, ARP table can be constructed.

A Proof of Concept, yes, an enterprise-class-quality network, no. If you try, 
start populating the hot-line before you turn the lights on 😊

> 
> A problem, however, is that there is no ACK above L2, that is, there is no
> end to end ACK, which means, if something goes wrong above L2, the result can
> be weird.

Yes, and all the other things above. E.g., a DAD coming from the wire that is 
sent over the wireless is not deterministically delivered and a duplicate is 
often missed. I do not need to continue the endless list do I?

Keep safe;

Pascal

> 
>   Masataka Ohta

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Owen DeLong via NANOG]

> On Mar 31, 2022, at 20:51, Masataka Ohta  
> wrote:
> 
> Owen DeLong wrote:
> 
>> It still suffers from a certain amount of opacity across administrative 
>> domains.
> 
> So, if an IPv6 prefix is assigned to an apartment building and
> the building has no logging mechanism on how addresses are used
> within the building, the problem of audit trail opacity is
> suffered.
> 
> Thank you very much to have proven IPv6 useless.
> 
>   Masataka Ohta


No, the problem of address correlation to end user may still exist, but the 
address
Is transparent. The address in log files at the apartment complex matches the 
address
In log files at intervening networks matches the address in log files at the 
victim network.

Obviously, if the apartment complex has no log files, then yes, it remains 
relatively useless
In your one contrived corner case… That not being the more general and widely 
deployed
Case, I think that calling that proof that IPv6 is worthless proves more about 
your inane
Bias than anything else.

Owen

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Masataka Ohta]

Owen DeLong wrote:


It still suffers from a certain amount of opacity across administrative domains.


So, if an IPv6 prefix is assigned to an apartment building and
the building has no logging mechanism on how addresses are used
within the building, the problem of audit trail opacity is
suffered.

Thank you very much to have proven IPv6 useless.

Masataka Ohta

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Owen DeLong wrote:


Yep… He’s absolutely right… We need to find a way to get the networks that 
aren’t deploying IPv6 to
get off the dime and stop holding the rest of the world hostage in the IPv4 
backwater.

Owen




You keep championing that approach, essentially unchanged for the past 
20 years with an impressive record of partial success and much failure 
and I will fully support and applaud your efforts in doing so. I will 
also hope that it doesnt take another 20 to finally succeed, because as 
you point out, you require an extremely high level of participation 
before its Mission Accomplished.


And its not unreasonable to expect that until that approach succeeds, 
that others' efforts to work on the ongoing problem receive the same 
support and encouragement.


IPv6 uber-alles adherents had more than enough time to claim it was 
going to solve the problem without any need for anything else and to 
"request" (quite strongly and wrongly so in my opinion) that everyone 
rally their efforts around that.


Now its time for those adherents to reciprocate.

And here is a little bit of constructive criticism to the Evangelical 
approach. Essentially, you need to pivot from how their efforts can save 
the world into how their efforts can benefit themselves.


You want more people to use IPv6? Make it worth their while. Lower the 
barriers the cost the risks and increase the bennies.


The early adopters, the activists, those who define themselves by their 
altruism you already got.


Dont be surprised when so many balk at doing things they have no 
particular defined need or interest in doing when the primary 
beneficiaries arent themselves, but the primary cost carriers are.


Or we can just wait and see how the natural course of events eventually 
plays out. Still looks likely that IPv6 will eventually take over the 
internet, but it sure would be nice if IPv4 did not become completely 
unusable before that manages to occur.


Joe

End of Mariupol's Internet

[Sean Donelan]

The Last Days Of Mariupol’s Internet
https://www.forbes.com/sites/thomasbrewster/2022/03/31/the-last-days-of-mariupols-internet/

"Engineers who kept Ukraine’s port city online have gone missing or died 
in the carnage inflicted by Russia’s siege. Hope remains that Ukrainian 
cities knocked off the internet map will come back online fast once the 
shelling ends."

Re: What's a "normal" ratio of web sites to IP addresses...

[Owen DeLong via NANOG]

> On Mar 31, 2022, at 16:47 , Bill Woodcock  wrote:
> 
> 
> 
>> On Apr 1, 2022, at 12:15 AM, Bill Woodcock  wrote:
>> …in a run-of-the-mill web hoster?
>> I’m happy to take private replies and summarize/anonymize back to the list, 
>> if people prefer.
> 
> I asked the same question on Twitter, and got quite a lot of answers in both 
> places pretty quickly.  Thus far, 23 answers, with an average of about 
> 490,000 and a median of 1,500.
> 
> Obviously there are a lot of different factors that go into this, but the two 
> that were cited most frequently were that user who want their own individual 
> IP drive the number down, while large load-balancing/caching infrastructures 
> drive the number up.
> 
> Thank you all very much.  I appreciate the education, and I hope it’s useful 
> to others as well!
> 
>-Bill
> 

I would think that the 490,000 is more likely to reflect “web servers” per 
address vs. “web sites” per address.

I think that your mention of load-balancing and caching somewhat prove (or at 
least support) my speculation here.

I suspect that when you talk about “web sites” instead of “web servers”, the 
number probably falls somewhere in the sub-1k range.

For clarity, “https://www.amazon.com/[ …]” is a web 
site. It is almost certainly served by many many servers.

Prior to SNI, it was mostly 1 web server per address. In 2018, major CDNs were 
just starting to consider
ending support for non-SNI clients.

Owen

Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

iMac:owen (112) ~ % host www.amazon.com 
2022/03/31 17:16:40
www.amazon.com is an alias for tp.47cf2c8c9-frontier.amazon.com.
tp.47cf2c8c9-frontier.amazon.com is an alias for d3ag4hukkh62yn.cloudfront.net.
d3ag4hukkh62yn.cloudfront.net has address 143.204.129.80

and

iMac:owen (113) ~ % dig -t  www.amazon.com  
2022/03/31 17:26:36

; <<>> DiG 9.10.6 <<>> -t  www.amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33930
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.amazon.com.IN  

;; ANSWER SECTION:
www.amazon.com. 228 IN  CNAME   
tp.47cf2c8c9-frontier.amazon.com.
tp.47cf2c8c9-frontier.amazon.com. 45 IN CNAME   d3ag4hukkh62yn.cloudfront.net.

;; AUTHORITY SECTION:
d3ag4hukkh62yn.cloudfront.net. 46 INSOA ns-130.awsdns-16.com. 
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 0 msec
;; SERVER: 192.159.10.2#53(192.159.10.2)
;; WHEN: Thu Mar 31 17:26:50 PDT 2022
;; MSG SIZE  rcvd: 206

0.002u 0.017s 0:00.02 50.0% 0+0k 0+0io 2pf+0w
iMac:owen (114) ~ % dig -t  tp.47cf2c8c9-frontier.amazon.com
2022/03/31 17:26:50

; <<>> DiG 9.10.6 <<>> -t  tp.47cf2c8c9-frontier.amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;tp.47cf2c8c9-frontier.amazon.com. IN   

;; ANSWER SECTION:
tp.47cf2c8c9-frontier.amazon.com. 21 IN CNAME   d3ag4hukkh62yn.cloudfront.net.

;; AUTHORITY SECTION:
d3ag4hukkh62yn.cloudfront.net. 22 INSOA ns-130.awsdns-16.com. 
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 0 msec
;; SERVER: 192.159.10.2#53(192.159.10.2)
;; WHEN: Thu Mar 31 17:27:14 PDT 2022
;; MSG SIZE  rcvd: 188

0.002u 0.005s 0:00.00 0.0%  0+0k 0+0io 0pf+0w
iMac:owen (115) ~ % dig -t  d3ag4hukkh62yn.cloudfront.net.  
2022/03/31 17:27:14

; <<>> DiG 9.10.6 <<>> -t  d3ag4hukkh62yn.cloudfront.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63871
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;d3ag4hukkh62yn.cloudfront.net. IN  

;; AUTHORITY SECTION:
d3ag4hukkh62yn.cloudfront.net. 5 IN SOA ns-130.awsdns-16.com. 
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 0 msec
;; SERVER: 192.159.10.2#53(192.159.10.2)
;; WHEN: Thu Mar 31 17:27:31 PDT 2022
;; MSG SIZE  rcvd: 142


So… As I said… Amazon.

Owen


> On Mar 31, 2022, at 16:00 , Andras Toth  wrote:
> 
> https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-ipv6-only-subnets-and-ec2-instances/
>  
> 
> 
>> On 1 Apr 2022, at 06:44, Owen DeLong via NANOG  wrote:
>> 
>> In short:
>>  Amazon
>>  Alibaba
>>  Google Cloud
>> 
>> And a few other laggards that are key destinations that a lot of eyeball 
>> customers expect to be
>> able to reach.
>> 
>> Owen
>> 
>> 
>>> On Mar 29, 2022, at 13:53 , Jacques Latour >> > wrote:
>>> 
>>> So, in 25, 50 or 100 years from now, are we still going to be dual stack 
>>> IPv4/IPv6?
>>> When are we going to give up on IPv4?
>>> People can run IPv4 all they want inside their networks for 1000s of years.
>>> What will it take to be IPv6 only?
>>>  
>>> 😊
>>>  
>>> From: NANOG >> > On Behalf Of Owen 
>>> DeLong via NANOG
>>> Sent: March 29, 2022 3:52 PM
>>> To: Abraham Y. Chen mailto:ayc...@avinta.com>>
>>> Cc: NANOG mailto:nanog@nanog.org>>
>>> Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported 
>>> re: 202203261833.AYC
>>>  
>>> Submit an Internet draft, same as any other IP related enhancement gets 
>>> introduced.
>>>  
>>> What you’re really complaining about is that it’s been virtually impossible 
>>> to gain consensus to move anything IPv4 related forward in the IETF since 
>>> at least 2015.
>>>  
>>> Well… It’s a consensus process. If your idea isn’t getting consensus, then 
>>> perhaps it’s simply that the group you are seeking consensus from doesn’t 
>>> like your idea.
>>>  
>>> Your inability to convince the members of the various working groups that 
>>> your idea has merit isn’t necessar

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

> On Mar 31, 2022, at 15:32 , Joe Maimon  wrote:
> 
> 
> 
> Matthew Petach wrote:
>> 
>> 
>> In short, at the moment, you *can't* deploy IPv6 without also having IPv4
>> somewhere in your network.  IPv6 hasn't solved the problem of IPv4
>> address shortage, because you can't functionally deploy IPv6 without
>> also having at least some IPv4 addresses to act as endpoints.
>> 
>> For the people who already have IPv4 addresses to say "hey, that's
>> not a problem for us" to everyone who can't get IPv4 addresses is
>> exactly the problem warned against in section 6 of 
>> https://datatracker.ietf.org/doc/html/rfc7282:
>> 
>> "
>> 6 . One hundred 
>> people for and five people against might not be rough
>> consensus
>> 
>>Section 3   
>> discussed the idea of consensus being achieved when
>>objections had been addressed (that is, properly considered, and
>>accommodated if necessary).  Because of this, using rough consensus
>>avoids a major pitfall of a straight vote: If there is a minority of
>>folks who have a valid technical objection, that objection must be
>>dealt with before consensus can be declared. "
>> The point at which we have parity between IPv4 and IPv6 connectivity is the 
>> point
>> at which we can start to talk about sunsetting IPv4 and declaring it 
>> historic, and
>> no longer concern ourselves with address exhaustion.  Until then, so long as
>> being able to obtain IPv4 addresses is a mandatory step in being functional 
>> on
>> the internet, it is unreasonable to say that the address exhaustion problem 
>> is
>> "solved."
>> 
>> Matt
>> 
> 
> I dont know how many ways and times this needs to be said, but you said it 
> quite well.
> 
> Joe

Yep… He’s absolutely right… We need to find a way to get the networks that 
aren’t deploying IPv6 to
get off the dime and stop holding the rest of the world hostage in the IPv4 
backwater.

Owen

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

> But as anyone who has tried to deploy IPv6-only networks quickly discovers, 
> at the present time, you can't deploy an IPv6-only network with any 
> success on the global internet today.  There's too many IPv6-ish networks 
> out there that haven't fully established their infrastructure to be reachable 
> without v4 connectivity also in place.  In order to deploy an IPv6 network 
> today, you *must* also have IPv4 addresses to work with.  Try to ping 
> apple.com  via v6, or microsoft.com 
>  via v6, and see how far you get.
> Closer to home, try to ping juniper.com/juniper.net 
>  via v6, or nokia.com ,
> and you'll find there's a whole bunch of assumptions that you've got 
> some level of working IPv4 in the picture to talk to your hardware and 
> software vendors.
> 

While I can’t ping those, I did turn off IPv4 and successfully pinged (and 
downloaded
web pages from):
www.apple.com 
www.microsoft.com 
www.juniper.net 
www.nokia.com 

I wasn’t able to find  records for any useful variant of juniper.com 
, but since that’s
a bank (www.juniper.com  has a CNAME record pointing 
to www.juniper.egs1b.barclaycards.com),
I expect them to be laggards… To the best of my knowledge, very few banks have 
deployed
IPv6 in any meaningful way.

> In short, at the moment, you *can't* deploy IPv6 without also having IPv4 
> somewhere in your network.  IPv6 hasn't solved the problem of IPv4 
> address shortage, because you can't functionally deploy IPv6 without 
> also having at least some IPv4 addresses to act as endpoints. 

Well, yes and no. The only real limitation requiring you to “have some IPv4”
is the failure of other networks to deploy IPv6. That’s not exactly an 
architectural or
technical problem with IPv6, it’s a deployment issue.

> For the people who already have IPv4 addresses to say "hey, that's 
> not a problem for us" to everyone who can't get IPv4 addresses is 
> exactly the problem warned against in section 6 of 
> https://datatracker.ietf.org/doc/html/rfc7282 
> :
> 
> "
> 
> 6 .  One hundred 
> people for and five people against might not be rough
> consensus
> 
>Section 3  
> discussed the idea of consensus being achieved when
>objections had been addressed (that is, properly considered, and
>accommodated if necessary).  Because of this, using rough consensus
>avoids a major pitfall of a straight vote: If there is a minority of
>folks who have a valid technical objection, that objection must be
>dealt with before consensus can be declared. “

Again, yes and no. While the failure of some networks to deploy IPv6 is proving 
debilitating to other
networks (including mine) ability to move forward with deprecation of IPv4 it’s 
really hard for me to
view that as a technical problem with IPv6, rather than a problem with the 
failure of those networks.

> The point at which we have parity between IPv4 and IPv6 connectivity is the 
> point 
> at which we can start to talk about sunsetting IPv4 and declaring it 
> historic, and 
> no longer concern ourselves with address exhaustion.  Until then, so long as 
> being able to obtain IPv4 addresses is a mandatory step in being functional 
> on 
> the internet, it is unreasonable to say that the address exhaustion problem is
> "solved."

OK, it’s not solved. However, the solution is fully architected and widely 
deployed. The failure of some
networks to deploy the solution really isn’t a design problem or a protocol 
problem. Arguably, it’s not
really a technical problem. It’s certainly not a technical shortcoming of IPv6. 
It’s a deployment failure,
arguably a bureaucratic or political problem as much as anything.

Owen

Re: What's a "normal" ratio of web sites to IP addresses...

[Bill Woodcock]

> On Apr 1, 2022, at 12:15 AM, Bill Woodcock  wrote:
> …in a run-of-the-mill web hoster?
> I’m happy to take private replies and summarize/anonymize back to the list, 
> if people prefer.

I asked the same question on Twitter, and got quite a lot of answers in both 
places pretty quickly.  Thus far, 23 answers, with an average of about 490,000 
and a median of 1,500.

Obviously there are a lot of different factors that go into this, but the two 
that were cited most frequently were that user who want their own individual IP 
drive the number down, while large load-balancing/caching infrastructures drive 
the number up.

Thank you all very much.  I appreciate the education, and I hope it’s useful to 
others as well!

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: What's a "normal" ratio of web sites to IP addresses...

[David Hubbard]

I don't know that there is a normal as it likely depends heavily on the revenue 
per customer and the service's tolerance for giving out IP addresses.  It also 
depends heavily on the back end infrastructhre and what kind of service is 
being provided.  There's probably massive scale behind Cloudflare IP addresses. 
 There are middleware-style ecommerce and blog platforms where there is the 
same, i.e. lots of sites behind any given IP because every customer receives 
the same service from the same software; likely thousands or more per IP in 
that case.  As you get more custom, probably far less per IP as that's when 
sites tend to start being mapped to dedicated virtual machines / servers, 
shared hosting, etc. where it goes anywhere from a few hundred to one site on a 
dedicated server.

Sorry to go off on a tangent but this got me wanting to rant. __

Still, to this day, SEO "experts" continue to guide clients towards service 
platforms (hosting, ecommerce, blogs, etc.) where they know it remains possible 
to get an exclusive IP address because they are "sure" that will produce 
meaningful search positioning gains.  I started a thread on this topic on nanog 
about this back in what I think was 2003 because every business entity had an 
SEO expert insisting their various websites receive IP addresses on subnets 
that differed enough to be "distant" from one another because Google would 
otherwise penalize them.  I expressed frustration at that because it ensured 
sites that had no technical need for an exclusive IP address would get one 
anyway, wasting a rapidly depleting resource, and costing the provider in the 
process while they could still get address space.

A Google Director, Craig Silverstein, said this wasn't the case, but just 
casually in a slashdot interview.

Matt Cutts later refuted it directly in 2006:  
https://www.mattcutts.com/blog/myth-busting-virtual-hosts-vs-dedicated-ip-addresses/

And he made the point once more in a 2013 Youtube video.

Three semi-official statements on the subject, the most recent nine years ago.  
So, it hasn't done much to dissuade the SEO experts of continuing to steer 
their clients towards places they think an exclusive IP will be issued.  
Fortunately the huge rise of CDN's seems to be getting things back on track, 
because those can produce more meaningful SEO benefit from the faster transit 
to eyeballs, putting exclusive IP recommendations on the back burner.

David



On 3/31/22, 6:19 PM, "NANOG on behalf of Bill Woodcock" 
 wrote:

…in a run-of-the-mill web hoster?

This is really a question specifically for folks with web-site-hosting 
businesses.

If you had, say, ten million web site customers, each with their own unique 
domain name, how many IPv4 addresses would you think was a reasonable number to 
host those on?  HTTP name-based virtual-hosting means that you could, 
hypothetically, pile all ten million into a single IP address.  At the other 
end of the spectrum, you could chew up ten million IPv4 addresses, giving a 
unique one to each customer.  Presumably the actual practice lies somewhere 
in-between.  But what ratio do people in that business think is reasonable?  
10:1?  100:1?  1,000:1?

I’m happy to take private replies and summarize/anonymize back to the list, 
if people prefer.

Thanks!

-Bill

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Joe Maimon]

Matthew Petach wrote:




Unfortunately, the reason crazy-long prepends actually propagate so
widely in the internet core is because most of those decisions to prefer
your peer's customers are done using a relatively big and heavy hammer.


IOW if your peer or customer has prepended 5 times or more, dont 
LOCAL_PREF or maybe even de-LOCAL_PREF it





For the most part--if you think LOCAL_PREF is the right knob to use 
for moving
traffic, it probably means you need to go back and rethink your 
traffic engineering

approach.   ^_^;

Matt


I think more and perhaps different knobs were and still are needed.

Here is an idea, as part of the all extra processing updates have to go 
through nowadays, how about a long call back to each AS in the path 
using some sort of standardized service, perhaps published via DNS, sort 
of an automated looking glass results compared to update-out. And then 
the receiver, however many AS's away starts to get a much clearer 
picture of the intent all the through and maybe perhaps some much better 
intelligent automated properly reactive internet wide traffic 
engineering standards will emerge.


Until then I think a slew of standardized communities that elicit near 
universal and predictable standard reactions is probably the best bet. 
The problem is that shifting too much control to the advertiser makes it 
a non-starter from the point of view of the receiver, and then you can 
forget about deployment.


Would be nice to be able to publish your community scheme as simply 
conforming with RFCX and the to configure peers with process-rfcX 
statement and be mostly done.


Joe

Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Andras Toth]

https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-ipv6-only-subnets-and-ec2-instances/

> On 1 Apr 2022, at 06:44, Owen DeLong via NANOG  wrote:
> 
> In short:
>   Amazon
>   Alibaba
>   Google Cloud
> 
> And a few other laggards that are key destinations that a lot of eyeball 
> customers expect to be
> able to reach.
> 
> Owen
> 
> 
>> On Mar 29, 2022, at 13:53 , Jacques Latour  wrote:
>> 
>> So, in 25, 50 or 100 years from now, are we still going to be dual stack 
>> IPv4/IPv6?
>> When are we going to give up on IPv4?
>> People can run IPv4 all they want inside their networks for 1000s of years.
>> What will it take to be IPv6 only?
>>  
>> 😊
>>  
>> From: NANOG  On Behalf Of 
>> Owen DeLong via NANOG
>> Sent: March 29, 2022 3:52 PM
>> To: Abraham Y. Chen 
>> Cc: NANOG 
>> Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported 
>> re: 202203261833.AYC
>>  
>> Submit an Internet draft, same as any other IP related enhancement gets 
>> introduced.
>>  
>> What you’re really complaining about is that it’s been virtually impossible 
>> to gain consensus to move anything IPv4 related forward in the IETF since at 
>> least 2015.
>>  
>> Well… It’s a consensus process. If your idea isn’t getting consensus, then 
>> perhaps it’s simply that the group you are seeking consensus from doesn’t 
>> like your idea.
>>  
>> Your inability to convince the members of the various working groups that 
>> your idea has merit isn’t necessarily a defect in the IETF process… It might 
>> simply be a lack of merit in your ideas.
>>  
>> Owen
>>  
>> 
>> 
>> On Mar 26, 2022, at 15:43 , Abraham Y. Chen  wrote:
>>  
>> Hi, Justin:
>>  
>> 1)"... no one is stopping anyone from working on IPv4 ... ":   After 
>> all these discussions, are you still denying this basic issue? For example, 
>> there has not been any straightforward way to introduce IPv4 enhancement 
>> ideas to IETF since at least 2015. If you know the way, please make it 
>> public. I am sure that many are eager to learn about it. Thanks.
>>  
>> Regards,
>>  
>>  
>> Abe (2022-03-26 18:42)
>>  
>>  
>>  
>>  
>> On 2022-03-26 11:20, Justin Streiner wrote:
>> While the Internet is intended to allow the free exchange of information, 
>> the means of getting that information from place to place is and has to be 
>> defined by protocols that are implemented in a consistent manner (see: BGP, 
>> among many other examples).  It's important to separate the ideas from the 
>> plumbing.
>>  
>> That said, no one is stopping anyone from working on IPv4, so what personal 
>> freedoms are being impacted by working toward deploying IPv6, with an eye 
>> toward sunsetting IPv4 in the future?
>>  
>> Keep in mind that IPv4 started out as an experiment that found its way into 
>> wider use.  It's a classic case of a test deployment that suddenly mutated 
>> into a production service.  Why should we continue to expend effort to 
>> perpetuate the sins of the past, rather work toward getting v6 into wider 
>> use?
>>  
>> Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key pain 
>> point of IPv4 - address space exhaustion.
>>  
>> Thank you
>> jms
>>  
>> On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen  wrote:
>>  
>> 3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic / logic 
>> baseline that we need to sort out, first. That is, we must keep in mind that 
>> the Internet community strongly promotes "personal freedom". Assuming that 
>> by stopping others from working on IPv4 will shift their energy to IPv6 is 
>> totally contradicting such a principle. A project attracts contributors by 
>> its own merits, not by relying on artificial barriers to the competitions. 
>> Based on my best understanding, IPv6 failed right after the decision of "not 
>> emphasizing the backward compatibility with IPv4". It broke one of the 
>> golden rules in the system engineering discipline. After nearly three 
>> decades, still evading such fact, but defusing IPv6 issues by various 
>> tactics is the real impedance to progress, not only to IPv4 but also to IPv6.
> 

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Matthew Petach]

On Thu, Mar 31, 2022 at 3:16 PM Joe Maimon  wrote:

>
>
> Joe Provo wrote:
> > On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote:
> >> :) probably the longest prepend in the world.
> >>
> >> A thought though, is it breaking any standard or best practice
> procedures?
> >
> > That said, prepending pretty much anything more than your current view
> > of the Internet's diameter in ASNs is useless in practice. Cascading
> > effects are considered in
> > https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/
> > where a decent low number (5) is propsed.
> >
> > Chers,
> >
> > Joe
> >
>
> So is there a good way to signal along with a BGP route that the
> originator of the route wants you to know that this route has very high
> suckage factor and even if you normally prefer your peers customers
> whatever, you should perhaps think twice about that for this route,
> cause its really last resort.
>
> Because as-path is an overloaded multimeaning traffic influencing hammer
> that has imprecise and frequently undesirable results. And if that were
> not the case, than discussions of its relative size compared to internet
> diameter would be much more relevant.
>
> Joe
>
>
Unfortunately, the reason crazy-long prepends actually propagate so
widely in the internet core is because most of those decisions to prefer
your peer's customers are done using a relatively big and heavy hammer.

LOCAL_PREF is, in my opinion, the wrong tool to use, but it's what most
of the networks out there seem to have settled on, to the point of having
published BGP communities to use for controlling the LOCAL_PREF setting
on received routes: https://onestep.net/communities/

I've long practiced, and advocated for, the use of MEDs or tweaking origin
codes as a better way to nudge traffic towards customers, peers, customers
of peers, etc., because it still allows as-path to be a factor in nudging
traffic
away.   Prepend inbound 3 times on routes learned from your transit
provider,
but not on your peers, listen to MEDs from your peers, and enable
always-compare-med
and deterministic-med to allow values to be compared across different
pathways.

That way, someone trying to say "don't use this path" can do a simple
triple-prepend,
and see their traffic shift.  In our current world of using LOCAL_PREF,
however, the
poor customer keeps prepending more and more, and never sees their traffic
shift.
In desperation, they prepend the maximum number of times allowed, hoping
that
maybe this will somehow do the trick...not understanding that no matter
what they
do in the prepend realm, so long as their upstreams are using the
LOCAL_PREF
hammer, their prepends will fall on deaf ears.

For the most part--if you think LOCAL_PREF is the right knob to use for
moving
traffic, it probably means you need to go back and rethink your traffic
engineering
approach.   ^_^;

Matt

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Matthew Petach wrote:



In short, at the moment, you *can't* deploy IPv6 without also having IPv4
somewhere in your network.  IPv6 hasn't solved the problem of IPv4
address shortage, because you can't functionally deploy IPv6 without
also having at least some IPv4 addresses to act as endpoints.

For the people who already have IPv4 addresses to say "hey, that's
not a problem for us" to everyone who can't get IPv4 addresses is
exactly the problem warned against in section 6 of 
https://datatracker.ietf.org/doc/html/rfc7282:


"
6 . One 
hundred people for and five people against might not be rough

consensus

Section 3   
discussed the idea of consensus being achieved when
objections had been addressed (that is, properly considered, and
accommodated if necessary).  Because of this, using rough consensus
avoids a major pitfall of a straight vote: If there is a minority of
folks who have a valid technical objection, that objection must be
dealt with before consensus can be declared. "
The point at which we have parity between IPv4 and IPv6 connectivity 
is the point
at which we can start to talk about sunsetting IPv4 and declaring it 
historic, and
no longer concern ourselves with address exhaustion.  Until then, so 
long as
being able to obtain IPv4 addresses is a mandatory step in being 
functional on
the internet, it is unreasonable to say that the address exhaustion 
problem is

"solved."

Matt



I dont know how many ways and times this needs to be said, but you said 
it quite well.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Matthew Petach]

On Wed, Mar 30, 2022 at 12:47 PM Tom Beecher  wrote:

> If the IETF has really been unable to achieve consensus on properly
>> supporting the currently still dominant internet protocol, that is
>> seriously problematic and a huge process failure.
>>
>
> That is not an accurate statement.
>
> The IETF has achieved consensus on this topic. It's explained here by
> Brian Carpenter.
>
> https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDXyAUA/
>
> He expressly states with many +1s that if something IPv4 related needs to
> get worked on , it will be worked on, but the consensus solution to V4
> address exhaustion was IPng that became IPv6, so that is considered a
> solved problem.
>
> Some folks don't LIKE the solution, as is their right to do. But the
> problem of V4 address exhaustion is NOT the same thing as "I don't like the
> solution that they chose."
>

I suspect people differ in their understanding of the word "consensus":

https://www.merriam-webster.com/dictionary/consensus

"Definition of *consensus*

1a
: general agreement : UNANIMITY
"

Versus the IETF:
https://tools.ietf.org/id/draft-resnick-on-consensus-01.html
(and subsequently https://datatracker.ietf.org/doc/html/rfc7282 )

specifically, this paragraph:

"Any finding of rough consensus needs at some level to be a satisfactory
explanation to the person(s) raising the issue of why their concern is not
going to be dealt with. A good outcome is for the objector to be satisfied
that, although their issue is not being accommodated in the final product,
they understand and accept the outcome. Remember, if the objector feels
that the issue is so essential that it must be attended to, they always
have the option to file an appeal. A technical error is always a valid
basis for an appeal, and a chair or AD has the freedom and the
responsibility to say, "The group did not take this technical issue into
proper account." Simply having a number of people agreeing to dismiss an
objection is not enough."

It would seem that Brian Carpenter's message drifted more towards the
dictionary definition of "consensus" than what the IETF has historically
used to determine "consensus".

Brian seems to have tried to sweep under the carpet a very serious
problem without properly addressing it, by saying (direct quote):
"We shouldn't be fixing problems that IPv6 already fixes,
and shortage of addresses is certainly in that category."

But as anyone who has tried to deploy IPv6-only networks quickly discovers,
at the present time, you can't deploy an IPv6-only network with any
success on the global internet today.  There's too many IPv6-ish networks
out there that haven't fully established their infrastructure to be
reachable
without v4 connectivity also in place.  In order to deploy an IPv6 network
today, you *must* also have IPv4 addresses to work with.  Try to ping
apple.com via v6, or microsoft.com via v6, and see how far you get.
Closer to home, try to ping juniper.com/juniper.net via v6, or nokia.com,
and you'll find there's a whole bunch of assumptions that you've got
some level of working IPv4 in the picture to talk to your hardware and
software vendors.

In short, at the moment, you *can't* deploy IPv6 without also having IPv4
somewhere in your network.  IPv6 hasn't solved the problem of IPv4
address shortage, because you can't functionally deploy IPv6 without
also having at least some IPv4 addresses to act as endpoints.

For the people who already have IPv4 addresses to say "hey, that's
not a problem for us" to everyone who can't get IPv4 addresses is
exactly the problem warned against in section 6 of
https://datatracker.ietf.org/doc/html/rfc7282:

"


6 .  One
hundred people for and five people against might not be rough
consensus

   Section 3 
discussed the idea of consensus being achieved when
   objections had been addressed (that is, properly considered, and
   accommodated if necessary).  Because of this, using rough consensus
   avoids a major pitfall of a straight vote: If there is a minority of
   folks who have a valid technical objection, that objection must be
   dealt with before consensus can be declared. "



The point at which we have parity between IPv4 and IPv6 connectivity is the
point
at which we can start to talk about sunsetting IPv4 and declaring it
historic, and
no longer concern ourselves with address exhaustion.  Until then, so long
as
being able to obtain IPv4 addresses is a mandatory step in being functional
on
the internet, it is unreasonable to say that the address exhaustion problem
is
"solved."

Matt

What's a "normal" ratio of web sites to IP addresses...

[Bill Woodcock]

…in a run-of-the-mill web hoster?

This is really a question specifically for folks with web-site-hosting 
businesses.

If you had, say, ten million web site customers, each with their own unique 
domain name, how many IPv4 addresses would you think was a reasonable number to 
host those on?  HTTP name-based virtual-hosting means that you could, 
hypothetically, pile all ten million into a single IP address.  At the other 
end of the spectrum, you could chew up ten million IPv4 addresses, giving a 
unique one to each customer.  Presumably the actual practice lies somewhere 
in-between.  But what ratio do people in that business think is reasonable?  
10:1?  100:1?  1,000:1?

I’m happy to take private replies and summarize/anonymize back to the list, if 
people prefer.

Thanks!

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Joe Maimon]

Joe Provo wrote:

On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote:

:) probably the longest prepend in the world.

A thought though, is it breaking any standard or best practice procedures?


That said, prepending pretty much anything more than your current view
of the Internet's diameter in ASNs is useless in practice. Cascading
effects are considered in
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/
where a decent low number (5) is propsed.

Chers,

Joe
  


So is there a good way to signal along with a BGP route that the 
originator of the route wants you to know that this route has very high 
suckage factor and even if you normally prefer your peers customers 
whatever, you should perhaps think twice about that for this route, 
cause its really last resort.


Because as-path is an overloaded multimeaning traffic influencing hammer 
that has imprecise and frequently undesirable results. And if that were 
not the case, than discussions of its relative size compared to internet 
diameter would be much more relevant.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

> On Mar 30, 2022, at 17:00 , Joe Maimon  wrote:
> 
> 
> 
> Tom Beecher wrote:
>> 
>>If the IETF has really been unable to achieve consensus on properly
>>supporting the currently still dominant internet protocol, that is
>>seriously problematic and a huge process failure.
>> 
>> 
>> That is not an accurate statement.
>> 
>> The IETF has achieved consensus on this topic. It's explained here by Brian 
>> Carpenter.
>> 
>> https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDXyAUA/
> 
> As I have explained with my newly introduced consensus standards, there is no 
> such consensus.
> 
> To reiterate my consensus standards, consensus is only to be considered as 
> amongst stakeholders and IPv6 specific related stakes are not relevant to 
> IPv4. If you consider the reverse to be true as well, I think my version of 
> consensus would achieve a much wider and diverse consensus than the the 
> stated IETF's consensus.
> 
> Once a consensus has been proven invalid its beyond obnoxious to cling to it 
> as though it maintains its own reality field.

Yes, but you don’t have consensus for your new consensus standard, so…

Owen

Re: IPv6 Only

[Mark Andrews]

You have to try running IPv6 only occasionally to weed out the dependencies.  
You can do this on a per node basis.  Just turn off the IPv4 interface and see 
how you run. I do this periodically on my Mac and disable IPv4.  This also 
makes my recursive nameserver IPv6 only as well.  You then see what breaks like 
sites where one of the cdn’s is IPv4 only despite the page itself being 
reachable over IPv6. Or the nameservers are not reachable over IPv6. 

Write down what you find is broken and report it.

-- 
Mark Andrews

> On 1 Apr 2022, at 05:53, Matthew Petach  wrote:
> 
> 
> 
> 
>> On Thu, Mar 31, 2022 at 5:36 AM Jacques Latour  
>> wrote:
>> Exactly what I was asking, when and how will we collectively turn off the 
>> lights on IPv4?
> 
> Working on the World IPv6 Launch {day|week|forever} efforts, 
> I noticed an interesting pattern of companies that put up IPv6 
> resources, with all the associated quad-As, and patted themselves 
> on the back for making themselves available via IPv6; but I couldn't 
> request those quad-A records via anything but IPv4 transport to their 
> DNS servers.
> 
> I've seen similar behaviour with hardware vendors.  They have great 
> IPv6 support, their boxes forward and accept IPv6 packets just fine; 
> but, the deeper you dig, the more you find oddities, like syslog host 
> destinations that only accept v4 IP addresses, or a requirement for 
> an IPv4 router ID to be configured. 
> 
> I don't think we fully grasp just how wide the chasm is between 
> "we support IPv6" and "we can fully turn off IPv4".
> 
> There's a whole lot of "we support IPv6" in the world right now that 
> comes with lingering IPv4 tendrils that are often under the surface, 
> or in the darker corners of the config, that just keep working because 
> most of the IPv6 world is still either dual-stacked, or has a translation 
> layer that allows the lurking v4 bits to not cause issues.
> 
> I don't think we'll be nearly as close to being ready to turn off the lights 
> on IPv4 as we think we are, not just because of old customer CPE and 
> legacy boxes, but because of embedded assumptions deep in software 
> and firmware stacks.  For example, let's take a relatively modern 
> enterprise wireless platform:
> 
> https://www.arubanetworks.com/techdocs/AOS-CX/10.07/HTML/5200-7852/Content/Chp_ZTP/ztp-sup-aos-cx-10.htm
> "
> ZTP operations are supported over IPv4 connections only. IPv6 connections are 
> not supported for ZTP operations."
>  Sure, the devices pass IPv6 traffic just fine; but you'd better keep your 
> IPv4 
> network around so the devices can configure themselves after powering on.
> 
> There's a *lot* of code out there that's been carried forward for years, 
> with dark corners that haven't been touched for a while.  I think we're 
> going to be stumbling over "can't do that over IPv6 yet" areas for years 
> and years to come, not because of any willful myopia around the migration 
> from IPv4 to IPv6, but simply because it's code that doesn't get used very 
> often, and in dual-stack networks, it just keeps working the few times it 
> gets exercised.  The only time it would run into a problem is in a pure 
> IPv6-only network; and how many of those really exist in the world to 
> flag it as an issue?
> 
> And yet, in order to "turn off the lights on IPv4", we're going to have to 
> root through all those dark corners of code that haven't been touched 
> in years to update them to work in an IPv6-only world; and that's *really* 
> pushing the rock uphill, because that's work that isn't going to see any 
> cost recovery for it at all.  No customer is going to say "I won't buy your 
> product until you've rooted out every bit of IPv4-only code in your software".
> So, there's really no financial incentive for companies to work towards 
> getting their software ready for an IPv6-only world.
> 
> So--the tl;dr version of my answer to you?
> "when" is likely to be "not in any of our lifetimes"--because the "how" 
> requires completely non-monetizable effort on the part of companies 
> that have legacy codebases they're carrying forward.
> 
> Thanks!
> 
> Matt
> 
> 

Re: V6 still not supported

[Owen DeLong via NANOG]

> On Mar 30, 2022, at 10:09 , Jared Brown  wrote:
> 
> Randy Carpenter wrote:
 Owen DeLong via NANOG wrote:
 When your ISP starts charging $X/Month for legacy protocol support
>>> 
>>> Out of interest, how would this come about?
>> 
>> ISPs are facing ever growing costs to continue providing IPv4 services.
> Could you please be more specific about which costs you are referring to?
> 
> It's not like IP transit providers care if they deliver IPv4 or IPv6 bits 
> to
> you.
 
 Have you priced blocks of IPv4 addresses lately?
>>> IPv4 address blocks have a fixed one-time cost, not an ongoing $X/month 
>>> cost.
>>> 
>>> - Jared
>> 
>> How, exactly, would you propose a company recoup the cost?
>  There are many options, depending on the commercial relationship between ISP 
> and customer.
> 
>  The ISP may simply charge a single one-time fee per IPv4.
> 
>  The customer may choose to bring their own IPv4 blocks as many BGP customers 
> do.
> 
>  The ISP may chose not to charge separately per IPv4, as having those IPs 
> enables them to charge $Y/month for Internet service.
> 
>  And so on and so forth.
> 
>  Furthermore IPv4 addresses do not wear out. IPs can be reused upon customer 
> churn and excess blocks can be sold, if need be.
> 
> - Jared

A growing number of providers are charging $x/IPv4 address/month as a way to 
recoup that cost.

I expect that trend will continue.

While it may (MAY[1]) be a one-time fixed costs to the provider, it’s not 
likely to stay that way for the customers going forward.

Owen

[1] Modulo RIR fees and the possibility that due to capital constraints, said 
ISP may have chosen to lease addresses rather than purchase them.

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

> On Mar 30, 2022, at 09:16 , Joe Maimon  wrote:
> 
> 
> 
> Owen DeLong via NANOG wrote:
>> What you’re really complaining about is that it’s been virtually impossible 
>> to gain consensus to move anything IPv4 related forward in the IETF since at 
>> least 2015.
>> 
>> Well… It’s a consensus process. If your idea isn’t getting consensus, then 
>> perhaps it’s simply that the group you are seeking consensus from doesn’t 
>> like your idea.
> 
> If the IETF has really been unable to achieve consensus on properly 
> supporting the currently still dominant internet protocol, that is seriously 
> problematic and a huge process failure.

Perhaps it’s more a question of the definition of “properly supporting” than 
whether or not to do so.

> When vendors do that sort of thing people get up in arms. When open source 
> projects do that sort of thing, they get forked. When community grassroots 
> governance bodies do that sort of thing, I dont want to find out.

My best guess is that the closest example is BSD and it’s tragedy of CARP.

> Responsible stewardship of internet community standardization would be 
> excluding IPv6 strategic concerns from considerations of consensus on IPv4 
> issues.

We can agree to disagree about this. If enough people agree with you, perhaps 
you can get consensus for that. If enough people agree with me, perhaps not.

> In other words, if the only issues you can bring to bear on any matter 
> pertaining solely to IPv4 is all about IPv6, your not relevant to the process 
> and should be struck from the record.

You are entitled to your opinion.

> I would even go so far as to say that you are actually poisoning the process.

Now you’re bordering on ad hominem.

>> Your inability to convince the members of the various working groups that 
>> your idea has merit isn’t necessarily a defect in the IETF process… It might 
>> simply be a lack of merit in your ideas.
>> 
>> Owen
>> 
>> 
> This part is very good advice, perhaps restated as a lack of merit in the 
> idea when combined with much wider and diverse perspectives.
> 
> On the other hand, with no record and history of ideology driven agendas, the 
> IETF process would be a whole lot more trustworthy.

There’s no such thing as a human process without ideology driven agendas, so 
it’s hard to take such a comment seriously.

Owen

Re: V6 still not supported

[Owen DeLong via NANOG]

> On Mar 30, 2022, at 08:09 , Jared Brown  wrote:
> 
> Owen DeLong via NANOG wrote:
 When your ISP starts charging $X/Month for legacy protocol support
>>> 
>>> Out of interest, how would this come about?
>> 
>> ISPs are facing ever growing costs to continue providing IPv4 services.
>  Could you please be more specific about which costs you are referring to?

Costs of address acquisition
Costs of CGNAT systems in lieu of address acquisition costs
Costs of increasing support calls due to IPv4 life support measures in other 
networks.
etc.

>  It's not like IP transit providers care if they deliver IPv4 or IPv6 bits to 
> you.

True, but adding customers requires additional addresses at some point. IPv6 
addresses are cheap compared to IPv4 addresses.

Owen

Re: IPv6 Only

[Carsten Bormann]

On 2022-03-31, at 20:54, Matthew Petach  wrote:
> 
> And yet, in order to "turn off the lights on IPv4", we're going to have to 
> root through all those dark corners of code 

The part that you might be missing is that those dark corners are also where 
the vulnerabilities hide.

If a piece of software can’t do v6, it probably hasn’t been maintained for a 
long time.

With software bills of materials coming up, we may have a bit more leverage on 
these graveyard decks than we have had until now.

Your main argument unfortunately does hold water; the timeline you propose, 
maybe not so much.

Grüße, Carsten

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Owen DeLong via NANOG]

> On Mar 29, 2022, at 17:51 , Masataka Ohta  
> wrote:
> 
> Owen DeLong wrote:
> 
>>> As I repeatedly pointed out, end to end NAT is clean preserving
>>> the universal peer to peer nature of the Internet.
>> Nope… It really isn’t.
> 
> Wrong.
> 
>> The problem of audit trail opacity is still a major issue with any form
>> of stateful NAT.
> 
> How poorly you understand NAT.
> 
> As I wrote in my draft:
> 
>   Depending on how port numbers are shared, there are static and
>   dynamic E2ENAT or combinations of them. With static E2ENAT, an end
>   host is assigned port numbers statically, which is necessary for a
>   server with a stable IP address and a port number.
> 
> static E2ENAT is not, with your questionable terminology, stateful.
> 
> It is even possible to construct legacy NAT which dynamically,
> thus statefully, assign ports only from some static range,
> which does not need state maintenance, for each private IP
> address.
> 
>   Masataka Ohta

It still suffers from a certain amount of opacity across administrative domains.

Owen

Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

In short:
Amazon
Alibaba
Google Cloud

And a few other laggards that are key destinations that a lot of eyeball 
customers expect to be
able to reach.

Owen


> On Mar 29, 2022, at 13:53 , Jacques Latour  wrote:
> 
> So, in 25, 50 or 100 years from now, are we still going to be dual stack 
> IPv4/IPv6?
> When are we going to give up on IPv4?
> People can run IPv4 all they want inside their networks for 1000s of years.
> What will it take to be IPv6 only?
>  
> 😊
>  
> From: NANOG  > On Behalf Of Owen 
> DeLong via NANOG
> Sent: March 29, 2022 3:52 PM
> To: Abraham Y. Chen mailto:ayc...@avinta.com>>
> Cc: NANOG mailto:nanog@nanog.org>>
> Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported 
> re: 202203261833.AYC
>  
> Submit an Internet draft, same as any other IP related enhancement gets 
> introduced.
>  
> What you’re really complaining about is that it’s been virtually impossible 
> to gain consensus to move anything IPv4 related forward in the IETF since at 
> least 2015.
>  
> Well… It’s a consensus process. If your idea isn’t getting consensus, then 
> perhaps it’s simply that the group you are seeking consensus from doesn’t 
> like your idea.
>  
> Your inability to convince the members of the various working groups that 
> your idea has merit isn’t necessarily a defect in the IETF process… It might 
> simply be a lack of merit in your ideas.
>  
> Owen
>  
> 
> 
> On Mar 26, 2022, at 15:43 , Abraham Y. Chen  > wrote:
>  
> Hi, Justin:
>  
> 1)"... no one is stopping anyone from working on IPv4 ... ":   After 
> all these discussions, are you still denying this basic issue? For example, 
> there has not been any straightforward way to introduce IPv4 enhancement 
> ideas to IETF since at least 2015. If you know the way, please make it 
> public. I am sure that many are eager to learn about it. Thanks.
>  
> Regards,
>  
>  
> Abe (2022-03-26 18:42)
>  
>  
>  
>  
> On 2022-03-26 11:20, Justin Streiner wrote:
> While the Internet is intended to allow the free exchange of information, the 
> means of getting that information from place to place is and has to be 
> defined by protocols that are implemented in a consistent manner (see: BGP, 
> among many other examples).  It's important to separate the ideas from the 
> plumbing.
>  
> That said, no one is stopping anyone from working on IPv4, so what personal 
> freedoms are being impacted by working toward deploying IPv6, with an eye 
> toward sunsetting IPv4 in the future?
>  
> Keep in mind that IPv4 started out as an experiment that found its way into 
> wider use.  It's a classic case of a test deployment that suddenly mutated 
> into a production service.  Why should we continue to expend effort to 
> perpetuate the sins of the past, rather work toward getting v6 into wider use?
>  
> Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key pain 
> point of IPv4 - address space exhaustion.
>  
> Thank you
> jms
>  
> On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen  > wrote:
>  
> 3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic / logic 
> baseline that we need to sort out, first. That is, we must keep in mind that 
> the Internet community strongly promotes "personal freedom". Assuming that by 
> stopping others from working on IPv4 will shift their energy to IPv6 is 
> totally contradicting such a principle. A project attracts contributors by 
> its own merits, not by relying on artificial barriers to the competitions. 
> Based on my best understanding, IPv6 failed right after the decision of "not 
> emphasizing the backward compatibility with IPv4". It broke one of the golden 
> rules in the system engineering discipline. After nearly three decades, still 
> evading such fact, but defusing IPv6 issues by various tactics is the real 
> impedance to progress, not only to IPv4 but also to IPv6.

NANOG 85 Registration is now OPEN! + VIDEO | Internet Innovators

[Nanog News]

VIDEO | New Episode of "Internet Innovators"
*Kleinrock Tells His Story + History of the Internet *

Kleinrock's story begins on the streets of Harlem, where he credits his
ability to see the world "without pretense" and how this ideology has
influenced his research.

*Watch the full episode to learn more about:*

• Leonard's childhood
• The day an engineer was born
• The historic day where the first message was transmitted
• What the first message was, and why
• What Leonard would have done differently
• Internet 50 Bash
• Future predictions for the Internet
• What he thinks the Internet still hasn't gotten right
• His most recent project: the UCLA Connection Lab
• + More

*WATCH NOW
*

NANOG 85 Registration is Now OPEN!
*Our 85th Community-Wide gathering is June 6 - 8*

*Join us for the next meeting, NANOG 85. *

Registration is open for our upcoming meeting, June 6 - 8 in Montréal,
Québec. Attendees are welcome to attend in-person + virtually.

*REGISTER NOW * 

Safety + Travel for NANOG 85

Your health and safety are very important to us and NANOG is ready to host
everyone safely in Montreal.

We will require that everyone attending NANOG 85 be fully vaccinated
against COVID-19 no later than May 23, 2022.

*GUIDELINES *

Re: IPv6 Only

[Matthew Petach]

On Thu, Mar 31, 2022 at 5:36 AM Jacques Latour 
wrote:

> Exactly what I was asking, when and how will we collectively turn off the
> lights on IPv4?
>

Working on the World IPv6 Launch {day|week|forever} efforts,
I noticed an interesting pattern of companies that put up IPv6
resources, with all the associated quad-As, and patted themselves
on the back for making themselves available via IPv6; but I couldn't
request those quad-A records via anything but IPv4 transport to their
DNS servers.

I've seen similar behaviour with hardware vendors.  They have great
IPv6 support, their boxes forward and accept IPv6 packets just fine;
but, the deeper you dig, the more you find oddities, like syslog host
destinations that only accept v4 IP addresses, or a requirement for
an IPv4 router ID to be configured.

I don't think we fully grasp just how wide the chasm is between
"we support IPv6" and "we can fully turn off IPv4".

There's a whole lot of "we support IPv6" in the world right now that
comes with lingering IPv4 tendrils that are often under the surface,
or in the darker corners of the config, that just keep working because
most of the IPv6 world is still either dual-stacked, or has a translation
layer that allows the lurking v4 bits to not cause issues.

I don't think we'll be nearly as close to being ready to turn off the
lights
on IPv4 as we think we are, not just because of old customer CPE and
legacy boxes, but because of embedded assumptions deep in software
and firmware stacks.  For example, let's take a relatively modern
enterprise wireless platform:

https://www.arubanetworks.com/techdocs/AOS-CX/10.07/HTML/5200-7852/Content/Chp_ZTP/ztp-sup-aos-cx-10.htm
"

   - ZTP operations are supported over IPv4 connections only. IPv6
   connections are not supported for ZTP operations."

 Sure, the devices pass IPv6 traffic just fine; but you'd better keep your
IPv4
network around so the devices can configure themselves after powering on.

There's a *lot* of code out there that's been carried forward for years,
with dark corners that haven't been touched for a while.  I think we're
going to be stumbling over "can't do that over IPv6 yet" areas for years
and years to come, not because of any willful myopia around the migration
from IPv4 to IPv6, but simply because it's code that doesn't get used very
often, and in dual-stack networks, it just keeps working the few times it
gets exercised.  The only time it would run into a problem is in a pure
IPv6-only network; and how many of those really exist in the world to
flag it as an issue?

And yet, in order to "turn off the lights on IPv4", we're going to have to
root through all those dark corners of code that haven't been touched
in years to update them to work in an IPv6-only world; and that's *really*
pushing the rock uphill, because that's work that isn't going to see any
cost recovery for it at all.  No customer is going to say "I won't buy your
product until you've rooted out every bit of IPv4-only code in your
software".
So, there's really no financial incentive for companies to work towards
getting their software ready for an IPv6-only world.

So--the tl;dr version of my answer to you?
"when" is likely to be "not in any of our lifetimes"--because the "how"
requires completely non-monetizable effort on the part of companies
that have legacy codebases they're carrying forward.

Thanks!

Matt

Re: Cogent ...

[Matthew Petach]

On Thu, Mar 31, 2022 at 9:05 AM Paul Timmins  wrote:

> On 3/31/22 11:38, Laura Smith via NANOG wrote:
> > However, perhaps someone would care to elaborate (either on or off-list)
> what the deal is with the requirement to sign NDAs with Cogent before
> they'll discuss things like why they still charge for BGP, or indeed any
> other technical or pricing matters. Seems weird ?!?
>
> Same reason your employer doesn't want employees telling each other
> their salary. Not every similarly situated customer pays the same for
> the same service.
>
>
Having fought that issue[0], I'd like to point out that employees
voluntarily
sharing salary data is federally protected speech in the US, and cannot
be waived through an employment contract:

https://www.nlrb.gov/about-nlrb/rights-we-protect/your-rights/your-rights-to-discuss-wages#:~:text=Under%20the%20National%20Labor%20Relations,for%20mutual%20aid%20or%20protection
.

"Under the National Labor Relations Act (NLRA or the Act), employees have
the right to communicate with other employees at their workplace about
their wages.  Wages are a vital term and condition of employment, and
discussions of wages are often preliminary to organizing or other actions
for mutual aid or protection. "
..."policies that specifically prohibit the discussion of wages are
unlawful."

I understand the parallelism you were aiming for, but
given how many people labour under the mistaken
notion that US companies can forbid you from talking
about your compensation, I felt it prudent to point out
that's actually not a terribly good comparison.   ^_^;

Thanks!

Matt


[0]
https://www.quora.com/My-coworker-asked-about-my-salary-how-should-I-respond/answer/Matthew-Petach

RE: A few questions regarding about RPKI/invalids

[Drew Weaver]

Want to give credit to 3356, after I contacted them they eliminated all of the 
bad routes coming in via legacy Global Crossing.

-Drew

-Original Message-
From: Job Snijders  
Sent: Wednesday, March 30, 2022 10:33 AM
To: Drew Weaver 
Cc: 'nanog@nanog.org' 
Subject: Re: A few questions regarding about RPKI/invalids

On Wed, Mar 30, 2022 at 01:29:25PM +, Drew Weaver wrote:
> Ex 45.176.191.0/24   3356 3549 11172 270150
> 
> RPKI ROA entry for 45.176.191.0/24-24
>   Origin-AS: 265621
> 
> Two questions:
> 
> First, are you also seeing this on this specific route?

It is visible in a few places, but the 61% score in for example RIPE stat is 
very low, which is a strong hint some kind of issue exists:
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ripe.net_ui2013_45.176.191.0-252F24-23tabId-3Drouting&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=lYqCT_cLHEX_5kNdAyPNFZ0xb8PC2MWeYQvGDwUnkAg&s=a_zBm6uyGLeXstr_JYZejbgBz1sOSpo4IxwKZ5YOoT0&e=

> Second, is there a certain number of "expected" invalid routes? (not 
> including unknowns)

Through large transit providers that do RPKI ROV with 'invalid == reject' 
you'll generally see less than a 100 invalids at any given time (1299, 174, 
3257, 3303, 6830, etc).

Then there are large transit providers who (as far as the public record is 
concerned) have not yet deployed RPKI ROV on their EBGP edges. Via AS
6762 I see ~ 2,300 invalids, and via AS 6461 about 3,000 invalids.

For historical perspective: this 3,000 upperbound number used to be ~
6,000 back in the 'pre RPKI era' in 2018/2019.

> Third, how are you handling specifically the large number of routes 
> from 3356 3549 which invalid origin AS? Are you just "letting the 
> bodies hit the floor"? or are you carving those out somehow?

I'd reject them. Why carve out an exception merely because the number is 
'large'? :-)

Kind regards,

Job

Re: PoE, Comcast Modems, and Service OutagesPyle

[Grant Taylor via NANOG]

On 3/31/22 8:40 AM, Abraham Y. Chen wrote:
3)    So, it is possible that the site with the reported "PoE induced" 
issues may be somehow experiencing the above related phenomena. This 
kind of situations are almost impossible to duplicate at another site. 
It has to be diagnosed with pains-taking detective efforts, such as 
inserting isolation subsystems suggested by one colleague. Since this 
phenomenon takes a month or so to show up, discipline and patience are 
the virtue.


I fully acknowledge that such things /are/ possible.  However I believe 
they are somewhere between quite and extremely rare.


My belief is that the support technician was using something that's just 
true enough or possible enough as an excuse to justify something and 
make it someone else's problem.


This is another reason why I'd go for the $100 optical coupling.  Mostly 
so that I could politely pat said technician on the cheek saying "Yes, 
that's possible, but it's not the problem we're discussing in this case 
because of optical coupling / electrical isolation."




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Cogent ...

[Laura Smith via NANOG]

--- Original Message ---

On Thursday, March 31st, 2022 at 16:43, Joe Greco  wrote:

> On Thu, Mar 31, 2022 at 03:38:15PM +, Laura Smith via NANOG wrote:
>

> Because they know that the sillier bits will be poked fun at on NANOG
>
> if they allow them to be disclosed?
>


The ironic thing is they demand NDAs and yet they don't comply with requests to 
stop unsolicited marketing despite written historical promises that they would.

RE: EXTERNAL: Re: Cogent ...

[Ray Orsini via NANOG]

It's illegal to prevent employees from discussing salary. Are you saying Cogent 
is doing unlawful things?


Ray Orsini
Chief Executive Officer
OIT, LLC
 305.967.6756 x1009 |  305.571.6272
 r...@oit.co |  www.oit.co
 oit.co/ray
How are we doing? We'd love to hear your feedback. https://go.oit.co/review
-Original Message-
From: NANOG  On Behalf Of Paul Timmins
Sent: Thursday, March 31, 2022 11:57 AM
To: nanog@nanog.org
Subject: EXTERNAL: Re: Cogent ...

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you are unsure, please forward this email to the CSE team for 
review.


On 3/31/22 11:38, Laura Smith via NANOG wrote:
> However, perhaps someone would care to elaborate (either on or off-list) what 
> the deal is with the requirement to sign NDAs with Cogent before they'll 
> discuss things like why they still charge for BGP, or indeed any other 
> technical or pricing matters. Seems weird ?!?

Same reason your employer doesn't want employees telling each other their 
salary. Not every similarly situated customer pays the same for the same 
service.

Re: MAP-T (was: Re: V6 still not supported)

[Ben Plimpton]

BR support is maturing nicely.  A few other vendors with implementations:
Arista - 
https://www.arista.com/en/support/toi/eos-4-24-0f/14495-map-t-border-relay 
Nokia - 
https://infocenter.nokia.com/public/7750SR140R4/index.jsp?topic=%2Fcom.sr.msisa%2Fhtml%2Fnat.html
Netgate/TNSR - https://docs.netgate.com/tnsr/en/latest/map/index.html

Thx,
Ben

> On Mar 25, 2022, at 3:44 PM, Rajiv Asati (rajiva) via NANOG  
> wrote:
> 
> FWIW, MAP has been deployed by few operators (in at least 3 continents that I 
> am aware of).
> 
> Charter communications is one of the public references (see NANOG preso 
> https://www.youtube.com/watch?v=ZmfYHCpfr_w).
> 
> MAP (CPE function) has been supported in OpenWRT software (as well as many 
> CPE vendor implementations) for few years now;
> MAP (BR function) has been supported by few vendors including Cisco (in 
> IOS-XE and XR).
> 
> Cheers,
> Rajiv 
> 
> https://openwrt.org/packages/pkgdata_owrt18_6/map-t 
> https://openwrt.org/docs/guide-user/network/map
> 
> 
> 
> -Original Message-
> From: NANOG  on behalf of Vasilenko 
> Eduard via NANOG 
> Reply-To: Vasilenko Eduard 
> Date: Friday, March 25, 2022 at 11:17 AM
> To: Jared Brown , "nanog@nanog.org" 
> Subject: RE: MAP-T (was: Re: V6 still not supported)
> 
>Hi Jared,
>Theoretically, MAP is better. But 
> 
>1. Nobody has implemented it for the router.
>The code for the CGNAT engine gives the same cost/performance.
>No promised advantage from potentially stateless protocol.
> 
>2.MAP needs much bigger address space (not everybody has) because:
>a) powered-off subscribers consume their blocks anyway
>b) it is not possible to add "on the fly" additional 64 ports to the 
> particular subscriber that abuse some Apple application (and go to 1k ports 
> consumption) that may drive far above any reasonable limit of ports per subs.
>Design should block a big enough number of UDP/TCP ports for every subs 
> (even most silent/conservative).
> 
>Ed/
>-Original Message-
>From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] 
> On Behalf Of Jared Brown
>Sent: Friday, March 25, 2022 4:49 PM
>To: nanog@nanog.org
>Subject: MAP-T (was: Re: V6 still not supported)
> 
>Most IPv6 transition mechanisms involve some form of (CG)NAT. After 
> watching a NANOG presentation on MAP-T, I have a question regarding this.
> 
>Why isn't MAP-T more prevalent, given that it is (almost) stateless on the 
> provider side?
> 
>Is it CPE support, the headache of moving state to the CPE, vendor 
> support, or something else?
> 
> 
>NANOG 2017
>Mapping of Address and Port using Translation MAP T: Deployment at Charter 
> Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w
> 
> 
>- Jared
> 

Re: Cogent ...

[Paul Timmins]

On 3/31/22 11:38, Laura Smith via NANOG wrote:

However, perhaps someone would care to elaborate (either on or off-list) what 
the deal is with the requirement to sign NDAs with Cogent before they'll 
discuss things like why they still charge for BGP, or indeed any other 
technical or pricing matters. Seems weird ?!?


Same reason your employer doesn't want employees telling each other 
their salary. Not every similarly situated customer pays the same for 
the same service.

Re: Cogent ...

[Aaron Wendel]

I've used Cogent for years and have never been asked to sign an NDA with 
them.


Of the 4 providers I use regularly they are the second highest price so 
I wouldn't consider them cheap any more either.


There's no better or worse than any transit provider these days.

Aaron

On 3/31/2022 10:38 AM, Laura Smith via NANOG wrote:

Hmmm

Spring has sprung and the waft of drivel from a new season Cogent salesdroid 
filled my telephone earpiece today.

I've never liked the Cogent way of business and my understanding of their IP transit is 
that it falls into the "cheap for a reason" category.

However, perhaps someone would care to elaborate (either on or off-list) what 
the deal is with the requirement to sign NDAs with Cogent before they'll 
discuss things like why they still charge for BGP, or indeed any other 
technical or pricing matters. Seems weird ?!?

Laura


--

Aaron Wendel
Chief Technical Officer
Wholesale Internet, Inc. (AS 32097)
(816)550-9030
http://www.wholesaleinternet.com

Re: Cogent ...

[David Hubbard]

I recently cancelled a circuit with them that began life as transit and 
converted to P2P, where the BGP fee never disappeared, and had been fighting 
them on it for eight months.  Now that the circuit is gone they've switched to 
completely ignore mode.  So, not likely I'll use them again.  I did the initial 
conversion because I got tired of customers with Google IPv6 issues and 
fortunately had a P2P need it could satisfy for a bit of time.  

On 3/31/22, 11:40 AM, "NANOG on behalf of Laura Smith via NANOG" 
 wrote:

Hmmm

Spring has sprung and the waft of drivel from a new season Cogent 
salesdroid filled my telephone earpiece today.

I've never liked the Cogent way of business and my understanding of their 
IP transit is that it falls into the "cheap for a reason" category.

However, perhaps someone would care to elaborate (either on or off-list) 
what the deal is with the requirement to sign NDAs with Cogent before they'll 
discuss things like why they still charge for BGP, or indeed any other 
technical or pricing matters. Seems weird ?!?

Laura

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Masataka Ohta]

Vasilenko Eduard via NANOG wrote:


IMHO: IETF is only partially guilty. Who was capable to predict in
1992-1994 that:

- Wireless would become so popular (WiFi is from 1997)


IP mobility WG of IETF was formed in 1992.


- Hardware forwarding (PFE) would be invented (1997) that would have
a big additional cost to implement Enhanced Headers


Optional IPv4 headers was considered harmful, IIRC before 1992,
which has nothing to do with TCAM.


- Encryption would never have a small enough cost to make it
mandatory


Cost of encryption is small enough. The problem is to securely
share keys, for example, between a source and a router to let
the router generate secure ICMP.


- Router would be available in every smallest thing that makes
distributed address acquisition redundant (hi SLAAC)


Local router is always available for a network with two
or more links, which was why SLAAC were a good idea.


We should be fair


You should.

Masataka Ohta

Re: Cogent ...

[Joe Greco]

On Thu, Mar 31, 2022 at 03:38:15PM +, Laura Smith via NANOG wrote:
> However, perhaps someone would care to elaborate (either on or off-
> list) what the deal is with the requirement to sign NDAs with Cogent 
> before they'll discuss things like why they still charge for BGP, or 
> indeed any other technical or pricing matters. Seems weird ?!?

Because they know that the sillier bits will be poked fun at on NANOG
if they allow them to be disclosed?

Because if you can't talk about your pricing, then they aren't as 
likely to be facing customers who know how cheap it was sold to some
other party?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Cogent ...

[Laura Smith via NANOG]

Hmmm

Spring has sprung and the waft of drivel from a new season Cogent salesdroid 
filled my telephone earpiece today.

I've never liked the Cogent way of business and my understanding of their IP 
transit is that it falls into the "cheap for a reason" category.

However, perhaps someone would care to elaborate (either on or off-list) what 
the deal is with the requirement to sign NDAs with Cogent before they'll 
discuss things like why they still charge for BGP, or indeed any other 
technical or pricing matters. Seems weird ?!?

Laura

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Dear Colleagues:

0)    I would like to summarize this thread of discussion with the 
following:


1)    It has been well-known in democracy that too much emphasis on 
"majority consensus" may not be really good for the intended goal. For 
example, if the general opinions in the ancient time prevailed and the 
objectors prosecuted, we probably are still living in a world of 
believing that the earth is flat and the sun rotates around the earth! 
Science and technology make advances due to a few stubborn and forward 
looking hard workers, not by popular wisdom.


2)    No one should be "defending" the decision of going to IPv6 three 
decades ago. There is no need to, because it was based on the best 
information and knowledge at that time. Now, after two decades of 
"experimenting", we have enough data to analyze and a lot of 
alternatives to review. There is nothing improper to revise the current 
Internet course that was set by engineers of at least two generations ago.


3)    It puzzles me deeply that the voices of the "Internet-way 
followers" these days have been so loud. What happened to the rebellion 
behaviors of restless young generations? Or, such voices come from those 
who made the choice three decades ago and refuse to update?


Regards,


Abe (2022-03-31 11:20)



On 2022-03-31 08:35, Vasilenko Eduard via NANOG wrote:

IMHO: IETF is only partially guilty. Who was capable to predict in 1992-1994 
that:

- Wireless would become so popular (WiFi is from 1997) and wireless would 
emulate multicast so badly (hi SLAAC)
- Hardware forwarding (PFE) would be invented (1997) that would have a big 
additional cost to implement Enhanced Headers
- Encryption would never have a small enough cost to make it mandatory
- Router would be available in every smallest thing that makes distributed 
address acquisition redundant (hi SLAAC)

We should be fair - it was not possible to guess.

Ed/
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Joe Maimon
Sent: Thursday, March 31, 2022 3:01 AM
To: Tom Beecher
Cc: NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC



Tom Beecher wrote:

 If the IETF has really been unable to achieve consensus on properly
 supporting the currently still dominant internet protocol, that is
 seriously problematic and a huge process failure.


That is not an accurate statement.

The IETF has achieved consensus on this topic. It's explained here by
Brian Carpenter.

https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDX
yAUA/

As I have explained with my newly introduced consensus standards, there is no 
such consensus.

To reiterate my consensus standards, consensus is only to be considered as 
amongst stakeholders and IPv6 specific related stakes are not relevant to IPv4. 
If you consider the reverse to be true as well, I think my version of consensus 
would achieve a much wider and diverse consensus than the the stated IETF's 
consensus.

Once a consensus has been proven invalid its beyond obnoxious to cling to it as 
though it maintains its own reality field.


He expressly states with many +1s that if something IPv4 related needs
to get worked on , it will be worked on,

IPv4 still needs address exhaustion solutions.


but the consensus solution to V4 address exhaustion was IPng that
became IPv6, so that is considered a solved problem.

IPv6 is not a solution. Its a replacement that does not have the same problem. 
Which could be a solution to the problem, but only if the replacement happens 
on schedule. However, so long as the replacement hasnt happened, we still are 
dealing with the problem.

The IETF made a stupendously bad bet that IPv6 would happen in time.
That is the kind of bet that you better be right about. They were a
decade+ wrong. That they have the audacity and temerity to continue
doubling down on that would be funny if it wasnt so outrageous, wrong and 
harmful.

Let us re-examine the premise. When did it become acceptable to quash work on 
one protocol because of the existence of another one that is preferred by the 
quashers?

Or in other words, the way you are framing things makes it seem as if the IETF 
has with intent and malice chosen to extend or at the very least ignore 
exhaustion issues for actual internet users so as to rig the system for their 
preferred outcome.


Some folks don't LIKE the solution, as is their right to do.

I agree. I like most of IPv6 just fine. Not SLAAC, not multicast l2 resolution, 
not addressing policy, not the chaos of choice of inadequate interoperability 
approaches, not the denial of features desired by users, not the pmtud, not the 
fragmentation, and many other warts. I dont even like the notation schemes. 
They require multiple vision passes.

I do like the extra bits. Just not the way they are being frittered.

The real crux of the matter is that it did not work. Address exhaustion ha

Re: IPv6 "bloat" history

[Masataka Ohta]

Pascal Thubert (pthubert) wrote:


You're perfectly correct. This is exactly what the registration would
be for. I'm concerned about its adoption that I do not see coming on
Wi-Fi/ Ethernet, even for v6 (SLAAC) where the problem is a lot
worse*.


You can't expect people still working primarily on v6 have
much sense of engineering.


* APs today snoop DHCP; DHCP is observable and stateful, with a
lifetime that allows to clean up. So snooping it is mostly good
enough there. The hassle is the SL in SLAAC which causes broadcasts
and is not deterministically observable; this problem is specific to
IPv6. We already have the registration to avoid snooping DHCP and
SLAAC; yet we do not observe any adoption in mainline APs and STAs.


As broadcast/multicast packets are first sent to APs as unicast
packets with ACKs, snooping by APs should be reliable at L2.

So, by snooping DAD, which is ugly, ARP table can be constructed.

A problem, however, is that there is no ACK above L2, that is,
there is no end to end ACK, which means, if something goes wrong
above L2, the result can be weird.

Masataka Ohta

Re: PoE, Comcast Modems, and Service OutagesPyle

[Abraham Y. Chen]

Hi, Colleagues:

0)    I would like to share a personal experience of a different setting 
to offer an angle for looking into this puzzling topic.


1)    During my graduate study, I was doing microwave experiments in the 
laboratory. On a six foot bench, I had a series (maybe a dozen or so) of 
waveguide components (made of metal, either solid copper or silver 
plated) connected together as the test bed. With a half dozen or so 
equipment attached to them at various points to serve as the energy 
source or sink as well as detection instruments. The setup exhibited 
randomly and unpredictable behaviors. After awhile, my advisor brought 
up the topic of "Ground Loops" that could introduce the interference in 
mysterious manners. This is a phenomenon whereby minuscule electric 
current flowing along metallic parts (even though they may appear to 
have no "resistance" in between) that are connected to the system common 
potential reference (the "ground") via slightly different paths. These 
could be very small resistance path between two points or high 
resistance leakage source. The resultant electric potentials among the 
subsystems of interest could be significant enough to affect the outputs 
of sensitive instruments.


2)    After much cut-&-try, including plugging all instruments into the 
same electric extension strip with no avail, I finally floated the AC 
power cords of all instruments (using three-to-two prong adapters) but 
kept only the most sensitive node in the system connected to the AC 
power source "ground". Although this was against the electric safety 
code, I finally got consistent results. With clear record of the 
configuration, I even could take the waveguide setup apart and then 
reassembled days later to repeat the same results. Years later, I 
applied the same philosophy to a smart-meter PCB design which got a 
better precision than the chip manufacturer's demon board could.


3)    So, it is possible that the site with the reported "PoE induced" 
issues may be somehow experiencing the above related phenomena. This 
kind of situations are almost impossible to duplicate at another site. 
It has to be diagnosed with pains-taking detective efforts, such as 
inserting isolation subsystems suggested by one colleague. Since this 
phenomenon takes a month or so to show up, discipline and patience are 
the virtue.


4)    On the other hand, a product that can build up certain "memory" of 
the disturbances like the above and to the point of requiring periodical 
power cycling to flush clear the issue is definitely a sign of defect 
design, based on my old school training.


Regards,


Abe (2022-03-31 10:40)


On 2022-03-30 15:57, Joe Greco wrote:

On Wed, Mar 30, 2022 at 05:52:06PM +, Livingood, Jason wrote:

  Their crappy equipment needing rebooting every few weeks, not ridiculous.
Their purchasing gear from incompetent vendors who cannot be standards

 compliant for PoE PD negotiation, tragically plausible.

Many customers buy their own cable modem. You can lease an Xfinity
device as well and those function pretty nicely these days but YMMV.
But typically a device reboot is a way to quickly solve a few
different kinds of problems, which is why techs will often recommend
it as an initial step (you can generally assume that there's data
behind what occurs when any one of tens of thousands of support reps
suggesting something to a customer - support at scale is data-driven).

No one's doubting all of that -- support is best when data-driven, scale
or otherwise.  But that's actually the issue here.  There's no data that
I know of to suggest widespread PoE ghost current buildups, and, given
the audience here, no one else has popped up with a clear "me too".

PoE is typically negotiated by modern switches, 24v Unifi special
jobbies aside, so it's all DC on cables that are already handling
differential signalling.


He's got graphs showing it every 24 hours?  Liar, liar, pants on fire,

 lazy SOB is looking for an excuse to clear you off the line.

Could well be from noise ingress - lots of work goes into finding &
fixing ingress issues. Hard to say unless we look in detail at the
connection in question and the neighborhood node.

No doubt.  There's huge amounts of room for problems to be introduced
into last mile networks.  But, again, this isn't about general problems.
This is about a tech claiming it's due to PoE, and that he's seen it
often before.

I certainly have a lot of sympathy for cable techs, but that doesn't
mean I want to swallow any random garbage they want to blame issues on.
Please just tell me it's the chipmunks getting feisty and nibbling on
the copper if you want to feed me a line...

... JG




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Opinions on Arista for BGP?

[David Hubbard]

Hi all, would love to get any current opinions (on or off list) on the 
stability of Arista’s BGP implementation these days.  Been many years since I 
last looked into it and wasn’t ready for a change yet.  Past many years have 
been IOS XR on NCS5500 platform and Arista everywhere but the edge.  I’ve been 
really happy with them in the other roles, so am thinking about edge now.  I do 
like and use XR’s RPL, and prefix/as/community/object sets, but we can live 
without via our own config management if there aren’t easy equivalents.  No 
fancy needs at all, just small web server networks, so just need reliable eBGP 
and internal OSPF/OSPFv3.

Thanks,

David

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

Hi Eduard

And SDN, and overlays, and... I certainly agree with what you're saying. 

This is why the L3 tech has to keep evolving as a survival trait. It's a 
delicate balance between evolving too quickly and producing the impression on 
unstable tech in the one hand, and stalling in the prehistory that you describe 
on the other, ask a dino when you meet one.

I argue that there are IPv6 RFCs to accommodate the cases I've seen on this 
list, but that the capabilities are largely ignored and -consequently- did not 
necessarily pass the PM barrier. Stalled we are indeed, but not for the lack of 
IETF work.

Keep safe;

Pascal



> -Original Message-
> From: NANOG  On Behalf Of
> Vasilenko Eduard via NANOG
> Sent: jeudi 31 mars 2022 14:36
> To: Joe Maimon ; Tom Beecher 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> IMHO: IETF is only partially guilty. Who was capable to predict in 1992-1994
> that:
> 
> - Wireless would become so popular (WiFi is from 1997) and wireless would
> emulate multicast so badly (hi SLAAC)
> - Hardware forwarding (PFE) would be invented (1997) that would have a big
> additional cost to implement Enhanced Headers
> - Encryption would never have a small enough cost to make it mandatory
> - Router would be available in every smallest thing that makes distributed
> address acquisition redundant (hi SLAAC)
> 
> We should be fair - it was not possible to guess.
> 
> Ed/
> -Original Message-
> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On
> Behalf Of Joe Maimon
> Sent: Thursday, March 31, 2022 3:01 AM
> To: Tom Beecher 
> Cc: NANOG 
> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> 
> 
> Tom Beecher wrote:
> >
> > If the IETF has really been unable to achieve consensus on properly
> > supporting the currently still dominant internet protocol, that is
> > seriously problematic and a huge process failure.
> >
> >
> > That is not an accurate statement.
> >
> > The IETF has achieved consensus on this topic. It's explained here by
> > Brian Carpenter.
> >
> > https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDX
> > yAUA/
> 
> As I have explained with my newly introduced consensus standards, there is no
> such consensus.
> 
> To reiterate my consensus standards, consensus is only to be considered as
> amongst stakeholders and IPv6 specific related stakes are not relevant to
> IPv4. If you consider the reverse to be true as well, I think my version of
> consensus would achieve a much wider and diverse consensus than the the
> stated IETF's consensus.
> 
> Once a consensus has been proven invalid its beyond obnoxious to cling to it
> as though it maintains its own reality field.
> 
> >
> > He expressly states with many +1s that if something IPv4 related needs
> > to get worked on , it will be worked on,
> 
> IPv4 still needs address exhaustion solutions.
> 
> > but the consensus solution to V4 address exhaustion was IPng that
> > became IPv6, so that is considered a solved problem.
> 
> IPv6 is not a solution. Its a replacement that does not have the same
> problem. Which could be a solution to the problem, but only if the
> replacement happens on schedule. However, so long as the replacement hasnt
> happened, we still are dealing with the problem.
> 
> The IETF made a stupendously bad bet that IPv6 would happen in time.
> That is the kind of bet that you better be right about. They were a
> decade+ wrong. That they have the audacity and temerity to continue
> doubling down on that would be funny if it wasnt so outrageous, wrong and
> harmful.
> 
> Let us re-examine the premise. When did it become acceptable to quash work on
> one protocol because of the existence of another one that is preferred by the
> quashers?
> 
> Or in other words, the way you are framing things makes it seem as if the
> IETF has with intent and malice chosen to extend or at the very least ignore
> exhaustion issues for actual internet users so as to rig the system for their
> preferred outcome.
> 
> >
> > Some folks don't LIKE the solution, as is their right to do.
> 
> I agree. I like most of IPv6 just fine. Not SLAAC, not multicast l2
> resolution, not addressing policy, not the chaos of choice of inadequate
> interoperability approaches, not the denial of features desired by users, not
> the pmtud, not the fragmentation, and many other warts. I dont even like the
> notation schemes. They require multiple vision passes.
> 
> I do like the extra bits. Just not the way they are being frittered.
> 
> The real crux of the matter is that it did not work. Address exhaustion has
> not been alleviated. For many years now and who knows how much longer.
> 
> > But the problem of V4 address exhaustion is NOT the same thing as "I
> > don't like the solution that they chose."
> 
> The problem of V4 address exhaustion is NOT the same thing as t

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Vasilenko Eduard via NANOG]

IMHO: IETF is only partially guilty. Who was capable to predict in 1992-1994 
that:

- Wireless would become so popular (WiFi is from 1997) and wireless would 
emulate multicast so badly (hi SLAAC)
- Hardware forwarding (PFE) would be invented (1997) that would have a big 
additional cost to implement Enhanced Headers
- Encryption would never have a small enough cost to make it mandatory
- Router would be available in every smallest thing that makes distributed 
address acquisition redundant (hi SLAAC)

We should be fair - it was not possible to guess.

Ed/
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Joe Maimon
Sent: Thursday, March 31, 2022 3:01 AM
To: Tom Beecher 
Cc: NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC



Tom Beecher wrote:
>
> If the IETF has really been unable to achieve consensus on properly
> supporting the currently still dominant internet protocol, that is
> seriously problematic and a huge process failure.
>
>
> That is not an accurate statement.
>
> The IETF has achieved consensus on this topic. It's explained here by 
> Brian Carpenter.
>
> https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDX
> yAUA/

As I have explained with my newly introduced consensus standards, there is no 
such consensus.

To reiterate my consensus standards, consensus is only to be considered as 
amongst stakeholders and IPv6 specific related stakes are not relevant to IPv4. 
If you consider the reverse to be true as well, I think my version of consensus 
would achieve a much wider and diverse consensus than the the stated IETF's 
consensus.

Once a consensus has been proven invalid its beyond obnoxious to cling to it as 
though it maintains its own reality field.

>
> He expressly states with many +1s that if something IPv4 related needs 
> to get worked on , it will be worked on,

IPv4 still needs address exhaustion solutions.

> but the consensus solution to V4 address exhaustion was IPng that 
> became IPv6, so that is considered a solved problem.

IPv6 is not a solution. Its a replacement that does not have the same problem. 
Which could be a solution to the problem, but only if the replacement happens 
on schedule. However, so long as the replacement hasnt happened, we still are 
dealing with the problem.

The IETF made a stupendously bad bet that IPv6 would happen in time. 
That is the kind of bet that you better be right about. They were a 
decade+ wrong. That they have the audacity and temerity to continue
doubling down on that would be funny if it wasnt so outrageous, wrong and 
harmful.

Let us re-examine the premise. When did it become acceptable to quash work on 
one protocol because of the existence of another one that is preferred by the 
quashers?

Or in other words, the way you are framing things makes it seem as if the IETF 
has with intent and malice chosen to extend or at the very least ignore 
exhaustion issues for actual internet users so as to rig the system for their 
preferred outcome.

>
> Some folks don't LIKE the solution, as is their right to do.

I agree. I like most of IPv6 just fine. Not SLAAC, not multicast l2 resolution, 
not addressing policy, not the chaos of choice of inadequate interoperability 
approaches, not the denial of features desired by users, not the pmtud, not the 
fragmentation, and many other warts. I dont even like the notation schemes. 
They require multiple vision passes.

I do like the extra bits. Just not the way they are being frittered.

The real crux of the matter is that it did not work. Address exhaustion has not 
been alleviated. For many years now and who knows how much longer.

> But the problem of V4 address exhaustion is NOT the same thing as "I 
> don't like the solution that they chose."

The problem of V4 address exhaustion is NOT the same thing as turn on
IPv6 and wait for the rest of the world to do the same.

When considered in that manner the IETF's bet looks even worse.

What I dont like is that they were wrong. What I dislike even more is that they 
refuse to admit it and learn from their mistakes.

Joe

> On Wed, Mar 30, 2022 at 12:18 PM Joe Maimon  > wrote:
>
>
>
> Owen DeLong via NANOG wrote:
>
> >
> > Well… It’s a consensus process. If your idea isn’t getting
> consensus,
> > then perhaps it’s simply that the group you are seeking
> consensus from
> > doesn’t like your idea.
>

Consensus processes are vulnerable to tyranny of a well positioned minority.

Joe

Re: IPv6 Only

[Jacques Latour]

Exactly what I was asking, when and how will we collectively turn off the 
lights on IPv4?

> -Original Message-
> From: NANOG  On
> Behalf Of Mark Andrews
> Sent: March 30, 2022 7:29 PM
> To: NANOG 
> Subject: [EXT] Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6
> still not supported re: 202203261833.AYC
> 
> Sites looking at the traffic they get and saying, you know what all our
> customers connect to us over IPv6 with some of them also connecting over
> IPv4.  I think we can stop supporting IPv4 now.
> 
> ISP’s saying this IPv4aaS isn’t getting much traffic anymore lets out source 
> it
> for the few customers that are still using it.  Lots of ISPs are well down the
> path leading to this point by turning off IPv4 on the access networks.
> 
> Home / enterprise networks.  All my gear is IPv6 capable and supports
> IPv4aaS for the few legacy
> IPv4 sites I need to connect to.  This is happening today.
> 
> In the end almost all the IPv4 traffic with be with the third party IPv4aaS
> providers and collectively they will decide to turn off the lights.
> 
> > On 30 Mar 2022, at 07:53, Jacques Latour  wrote:
> >
> > So, in 25, 50 or 100 years from now, are we still going to be dual stack
> IPv4/IPv6?
> > When are we going to give up on IPv4?
> > People can run IPv4 all they want inside their networks for 1000s of years.
> > What will it take to be IPv6 only?
> >
> > 😊
> >
> > From: NANOG  On
> Behalf
> > Of Owen DeLong via NANOG
> > Sent: March 29, 2022 3:52 PM
> > To: Abraham Y. Chen 
> > Cc: NANOG 
> > Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not
> > supported re: 202203261833.AYC
> >
> > Submit an Internet draft, same as any other IP related enhancement gets
> introduced.
> >
> > What you’re really complaining about is that it’s been virtually impossible
> to gain consensus to move anything IPv4 related forward in the IETF since at
> least 2015.
> >
> > Well… It’s a consensus process. If your idea isn’t getting consensus, then
> perhaps it’s simply that the group you are seeking consensus from doesn’t
> like your idea.
> >
> > Your inability to convince the members of the various working groups that
> your idea has merit isn’t necessarily a defect in the IETF process… It might
> simply be a lack of merit in your ideas.
> >
> > Owen
> >
> >
> >
> > On Mar 26, 2022, at 15:43 , Abraham Y. Chen 
> wrote:
> >
> > Hi, Justin:
> >
> > 1)"... no one is stopping anyone from working on IPv4 ... ":   
> > After all
> these discussions, are you still denying this basic issue? For example, there
> has not been any straightforward way to introduce IPv4 enhancement ideas
> to IETF since at least 2015. If you know the way, please make it public. I am
> sure that many are eager to learn about it. Thanks.
> >
> > Regards,
> >
> >
> > Abe (2022-03-26 18:42)
> >
> >
> >
> >
> > On 2022-03-26 11:20, Justin Streiner wrote:
> > While the Internet is intended to allow the free exchange of information,
> the means of getting that information from place to place is and has to be
> defined by protocols that are implemented in a consistent manner (see: BGP,
> among many other examples).  It's important to separate the ideas from the
> plumbing.
> >
> > That said, no one is stopping anyone from working on IPv4, so what
> personal freedoms are being impacted by working toward deploying IPv6,
> with an eye toward sunsetting IPv4 in the future?
> >
> > Keep in mind that IPv4 started out as an experiment that found its way
> into wider use.  It's a classic case of a test deployment that suddenly
> mutated into a production service.  Why should we continue to expend
> effort to perpetuate the sins of the past, rather work toward getting v6 into
> wider use?
> >
> > Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key pain
> point of IPv4 - address space exhaustion.
> >
> > Thank you
> > jms
> >
> > On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen 
> wrote:
> >
> > 3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic / logic
> baseline that we need to sort out, first. That is, we must keep in mind that
> the Internet community strongly promotes "personal freedom". Assuming
> that by stopping others from working on IPv4 will shift their energy to IPv6 
> is
> totally contradicting such a principle. A project attracts contributors by its
> own merits, not by relying on artificial barriers to the competitions. Based 
> on
> my best understanding, IPv6 failed right after the decision of "not
> emphasizing the backward compatibility with IPv4". It broke one of the
> golden rules in the system engineering discipline. After nearly three decades,
> still evading such fact, but defusing IPv6 issues by various tactics is the 
> real
> impedance to progress, not only to IPv4 but also to IPv6.
> 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

Fun, I had a parallel experience with NEMO that I implemented in IOS. 

But I mostly read the fate of MIP and NEMO as a lack of ask. Which is similar 
to the lack of desire today for the uplifts we made to IPv6 as a whole, and ND 
in particular.

Anyway, RPL has a lot to do with what we learned there, including the abstract 
objective function that yields the metrics you are talking about, typically 
including things like ETX/ETX^2, RSSI and LQI.

So yes, things that make sense eventually emerge.

Keep safe.

Pascal

> -Original Message-
> From: William Allen Simpson 
> Sent: jeudi 31 mars 2022 14:10
> To: nanog@nanog.org
> Cc: Pascal Thubert (pthubert) ; Masataka Ohta
> 
> Subject: Re: IPv6 "bloat" history
> 
> On 3/31/22 7:44 AM, William Allen Simpson wrote:
> > [heavy sigh]
> >
> > All of these things were well understood circa 1992-93.
> >
> > That's why the original Neighbor Discovery was entirely link state.
> >
> > ND link state announcements handled the hidden terminal problem.
> 
> Also, it almost goes without saying that the original ND tried to handle the
> near-far problem.  For example, where I'm talking to a far away AP streaming
> to the TV in front of me.
> 
> At my home, I've had to wire the TV.  Streaming to the AP, then the AP
> sending the same traffic over the same wireless band to the TV caused lots of
> drops and jitter.
> 
> The near-far problem can be detected and solved.  That's the reason for the
> Metric field.
> 
> Furthermore, one of the messages in this thread mentioned trying to backport
> v6 features to v4.
> 
> We've already been down that road.  IPsec and MobileIP were developed for v6.
> After quitting the v6 project(s), I'd backported both of them to v4.  Like
> v6, then they were assigned to others who ruined them.
> Committee-itis at its worst.

RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

Don't sigh! You envisioned it and we built it, William.

We have IPv6 mesh networks with thousands on nodes per mesh deployed around 
you. The standard is called WI-SUN. WI-SUN totals millions of nodes deployed in 
North America; so what you described cannot not only be envisioned as you did, 
it can be built and deployed at scale, even on low power far reach wireless.

The core L3 components for Wi-SUN are RFC 8505 which is your link state ND 
thingy, RFC 6550 that does the routing over what OSPF called P2MP and which 
really means non-transitive, and RFC 9010 that redistribute the former in the 
latter. We are now working on registering multicast, anycast and prefixes in 
the same model.

It's just that the wired world (including operators) are mostly unaware of 
these capabilities. Whether they are even interested is not a given either. 
Louis the XVth said "après moi le déluge". I read pretty much the same thing on 
the list in the recent days as a migration strategy. 

Certainly, complaining from a comfort zone is a lot easier than acting out to 
solve the problem. "La critique est aisée mais l'art est difficile" is another 
good one.

I claim that bashing at the IETF for IPv6 as it was 20 years ago is unfair and 
that a little refresh / resync is in order. If what we produced since in an 
attempt to solve the issues you describe can help, then ask for it, amend it, 
say something, so something.

Today, decoupling the L1/2 (physical) network from the L3 abstractions of 
subnet and link is totally doable. This yields a world of possibilities for 
deployments. For all those (or the very few) who care, there's 
https://datatracker.ietf.org/doc/html/draft-thubert-6man-ipv6-over-wireless-06

Keep safe;

Pascal

PS : When I say that DHCP mostly does the trick is not that I like it, but that 
customers (think EVPN) are reasonably happy with the result, while SLAAC is a 
lot worse for pretty much the whole collection of its design points, and cherry 
on the cake, the onlink model.

> -Original Message-
> From: William Allen Simpson 
> Sent: jeudi 31 mars 2022 13:44
> To: nanog@nanog.org
> Cc: Pascal Thubert (pthubert) ; Masataka Ohta
> 
> Subject: Re: IPv6 "bloat" history
> 
> On 3/29/22 5:21 AM, Pascal Thubert (pthubert) via NANOG wrote:
> > * APs today snoop DHCP; DHCP is observable and stateful, with a lifetime
> that allows to clean up. So snooping it is mostly good enough there. The
> hassle is the SL in SLAAC which causes broadcasts and is not
> deterministically observable; this problem is specific to IPv6. We already
> have the registration to avoid snooping DHCP and SLAAC; yet we do not observe
> any adoption in mainline APs and STAs.
> >
> 
> [heavy sigh]
> 
> All of these things were well understood circa 1992-93.
> 
> That's why the original Neighbor Discovery was entirely link state.
> 
> ND link state announcements handled the hidden terminal problem.
> (That is, where node A can hear node B, node B can hear node C, and node C
> can hear node A, but A cannot hear C.)  ND LSAs are/were flexible enough to
> handle both AP (cell) and mesh (AMPR) networks.
> 
> Thus, it was not reliant on central Access Points.  We envisioned mesh
> networks were the future.  Each node should handle its own discovery and
> routing.
> 
> SLAAC is bloat.
> 
> RIPv6 is bloat.
> 
> DHCPv6 is bloat.
> 
> Those are reasons operators have been complaining about IPv6.

Re: IPv6 "bloat" history

[William Allen Simpson]

On 3/31/22 7:44 AM, William Allen Simpson wrote:

[heavy sigh]

All of these things were well understood circa 1992-93.

That's why the original Neighbor Discovery was entirely link state.

ND link state announcements handled the hidden terminal problem.


Also, it almost goes without saying that the original ND tried to
handle the near-far problem.  For example, where I'm talking to a far
away AP streaming to the TV in front of me.

At my home, I've had to wire the TV.  Streaming to the AP, then the
AP sending the same traffic over the same wireless band to the TV
caused lots of drops and jitter.

The near-far problem can be detected and solved.  That's the reason
for the Metric field.

Furthermore, one of the messages in this thread mentioned trying to
backport v6 features to v4.

We've already been down that road.  IPsec and MobileIP were developed
for v6.  After quitting the v6 project(s), I'd backported both of
them to v4.  Like v6, then they were assigned to others who ruined them.
Committee-itis at its worst.

Re: IPv6 "bloat" history

[William Allen Simpson]

On 3/29/22 5:21 AM, Pascal Thubert (pthubert) via NANOG wrote:

* APs today snoop DHCP; DHCP is observable and stateful, with a lifetime that 
allows to clean up. So snooping it is mostly good enough there. The hassle is 
the SL in SLAAC which causes broadcasts and is not deterministically 
observable; this problem is specific to IPv6. We already have the registration 
to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in 
mainline APs and STAs.



[heavy sigh]

All of these things were well understood circa 1992-93.

That's why the original Neighbor Discovery was entirely link state.

ND link state announcements handled the hidden terminal problem.
(That is, where node A can hear node B, node B can hear node C,
and node C can hear node A, but A cannot hear C.)  ND LSAs are/were
flexible enough to handle both AP (cell) and mesh (AMPR) networks.

Thus, it was not reliant on central Access Points.  We envisioned
mesh networks were the future.  Each node should handle its own
discovery and routing.

SLAAC is bloat.

RIPv6 is bloat.

DHCPv6 is bloat.

Those are reasons operators have been complaining about IPv6.

RE: CGNAT scaling cost (was Re: V6 still not supported)

[Vasilenko Eduard via NANOG]

No.
I have already forgotten that SDH did exist (and yes, I remember X.25 - I have 
operated X.25 network).
I was talking in the next message about 100GE.
In fact, the situation would be similar for 10E too.

Ed/
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Masataka Ohta
Sent: Thursday, March 31, 2022 3:56 AM
To: nanog@nanog.org
Subject: Re: CGNAT scaling cost (was Re: V6 still not supported)

Vasilenko Eduard via NANOG wrote:

> CGNAT cost was very close to 3x compared to routers of the same 
> performance.

That should be because you are comparing cost of carrier, that is telco, grade 
NAT and consumer grade routers.

Remember the cost of carrier grade datalink of SONET/SDH.

Masataka Ohta

RE: A straightforward transition plan (was: Re: V6 still not supported)

[Pascal Thubert (pthubert) via NANOG]

Hi Mark and all:

Indeed, we have a plethora of IPv4 encapsulation and 4-to-6 techniques. 

I read somewhere down the threads that we (at IETF) made a "stupendously" bad 
bet thinking that IPv6 would be generalized quickly thanks to those techniques.

Being partially guilty of that (e.g., but not limited to, USPTO 7,443,880 filed 
in 2004 that became 464XLAT), I can see that the 4-to-6 step involving CG NATs 
and all was a too big step to be taken. It's not a step, it's a 100m jump. 

Looking at it from a distance, I came to challenge that it is even a 
requirement to the transition plan. If we look at it, a stack that is not 
capable of IPv6 is now a legacy stack. It's ultimate goal is probably to 
connect a legacy IPv4 client application to a legacy IPv4 server and it will 
not need anything more in its whole life. For that use case, both app and 
server can live forever as they are, as far as the plan is concerned, provided 
that we continue to give them a 464XLAT or a DSlite tunnel, which is not that 
hard if the numbers are counted.

If we accept that connecting that legacy device with any future IPv6-only 
application is effectively a non-goal, then we open the thought process to a 
migration that takes several baby steps, each step easy to make, as opposed to 
the large one that proved unfeasible in 20 years. 

Instead, what we really want for this plan is to design feasible baby steps, 
each representing connectivity between a level of evolution and the next, BUT 
NOT attempting to provide connectivity between the first level (legacy IPv4 
only app) and the ultimate level (IPv6-only networks and servers). Something 
like  1<->2<->..<->N as opposed to 1<->N which proved unfeasible.

My view of the steps we'd need to make:

- extend the size of public IPv4 addressable realms. I read the ask in many 
threads in this list
- extend that to some IPv6-only end-points leveraging the above
- extend that to generic IPv6

With design constraints that make this deployable:
 
- allow IPv4-only network domains
- allow IPv6-only network domains  
- use stateless NATs only
- allow the NAT to be anywhere from bump in the stack to X-only realm borders

Does this seem desirable to you?

If so, yes, we can make that happen. Then we'll see how the IPvx domains play 
GO together, based on real usefulness vs cost.

Pascal



> -Original Message-
> From: NANOG  On Behalf Of Mark
> Andrews
> Sent: jeudi 31 mars 2022 1:32
> To: NANOG 
> Subject: Re: A straightforward transition plan (was: Re: V6 still not
> supported)
> 
> 
> 
> > On 26 Mar 2022, at 21:51, Philip Homburg 
> wrote:
> >
> >>> If there is a magical transition technology that allows an IPv6-only
> >>> host t
> >> o
> >>> talk to an IPv4-only host, then let's deploy it.
> >>
> >> DNS64/NAT64, DS-Lite, 6rd, 464XLAT, MAP-T, MAP-E, ? pick a transition
> >> protocol and see what happens!  (with more coming every year...)
> >
> > The problem with these is that they are not full solutions. That's why
> > we get new ones every year: everybody picks the subset of the problem
> > they want solve.
> >
> > To go over the ones you listed:
> > - 6rd. That's the odd one out here. 6rd privdes IPv6 over an IPv4
> > infrastructure. Very useful when there was not a lot of IPv6 native.
> > Not a good approach for organisations that lack IPv4 addresses. Also
> > not a good approach if you want to switch off IPv4 at some point.
> > - DS-Lite, MAP-T, MAP-E. Good for connecting CPEs to IPv4aaS over an
> > IPv6-only backbone. Downstream from the CPE is dual stack. For this
> > reason those protocols do not see much use outside ISP networks. Got a
> > great transition technology because hosts will keep IPv4 until the
> > last IPv4 on the internet is gone. It is a bit of an IETF failure that
> > we have so many ways to connect a CPE to IPv4aaS.
> > - NAT64/DNS64. This is the closest to an actual transition technology.
> > Unfortunately it is completely flawed in too many ways.
> > - 464XLAT fixes many issues with NAT64/DNS64. The downside is again
> > that hosts have to have an IPv4 stack until forever and in addition to
> > that a complex IPv4-to-IPv6 translation module. That fails the
> > requirement that an IPv6 stack should have roughly the same complexity
> > as IPv4 and talk to IPv4-only.
> >
> > Basically, there is no solution to the transition problem. There are
> > lots of partial solutions, each with their own advantages and
> disadvantages.
> >
> > If we could go back in time, then developing NAT64 along with IPv6 and
> > making sure the translation really works including edge cases like
> > IPv4 literals, DNS A records, NAT traversal, etc. would have made a
> > difference.
> >
> > I don't know if such translation gateways were considered, I can't
> > recall much discussion about them. By the time the IPv6 socket API was
> > created it was already too late to get things like IPv4 literals right.
> 
> DS-Lite was designed to be implemented in the node.  You can run IPv6