Re: IPv6 and CDN's

[Fred Baker]

> On Oct 26, 2021, at 9:11 AM, David Conrad  wrote:
> 
> There has been some effort to create a governance model for the root server 
> system (see 
> https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) but I 
> believe it has gotten bogged down in the question of “what do you do when a 
> root server operator isn’t doing the job ‘right’ (whatever that means and 
> after figuring out who decides) but doesn’t want to give up being a root 
> server operator?”.

Unless you actually read the document. The process is that the fact is 
recognized and documented, the Designation and Removal function advises the 
ICANN board, they adopt a resolution, and instruct the IANA to remove the 
addresses from the relevant files, and from that point on nobody NEW tries to 
usevtheRSO. If someone does ask the company a question, they might or might not 
respond, and it might even have correct data, but then again might not. We 
can’t control who sends us requests, and we don’t have a black list.

Re: IPv6 and CDN's

[Oliver O'Boyle]

On Fri., Nov. 26, 2021, 19:41 Michael Thomas,  wrote:

>
> On 11/26/21 4:39 PM, Jean St-Laurent wrote:
>
> But CFOs like monetization. Was that thread about IPv6 or CFO?
>
>
> Amazon's in this case. They are monetizing their lack of v6 support
> requiring you go through all kinds of expensive hoops instead of doing the
> obvious and routing v6 packets.
>

They're getting better at it, at least. They also recently added v6 support
in their NLBs and you can get a /56 for every VPC for direct access. I
don't think they offer BYO v6 yet, as they do for v4, but it will come.


Mike
>
>
>
> *From:* Michael Thomas  
> *Sent:* November 26, 2021 7:37 PM
> *To:* Oliver O'Boyle  
> *Cc:* Jean St-Laurent  ; Ca By
>  ; North American Network
> Operators' Group  
> *Subject:* Re: IPv6 and CDN's
>
>
>
> That's a start, I guess. Before all they had was some weird VPN something
> or other. Let me guess though: they are monetizing their market failure.
>
>

Re: IPv6 and CDN's

[Michael Thomas]

On 11/26/21 4:39 PM, Jean St-Laurent wrote:


But CFOs like monetization. Was that thread about IPv6 or CFO?



Amazon's in this case. They are monetizing their lack of v6 support 
requiring you go through all kinds of expensive hoops instead of doing 
the obvious and routing v6 packets.


Mike


*From:*Michael Thomas 
*Sent:* November 26, 2021 7:37 PM
*To:* Oliver O'Boyle 
*Cc:* Jean St-Laurent ; Ca By ; 
North American Network Operators' Group 

*Subject:* Re: IPv6 and CDN's

That's a start, I guess. Before all they had was some weird VPN 
something or other. Let me guess though: they are monetizing their 
market failure.

RE: IPv6 and CDN's

[Jean St-Laurent via NANOG]

But CFOs like monetization. Was that thread about IPv6 or CFO?

 

From: Michael Thomas  
Sent: November 26, 2021 7:37 PM
To: Oliver O'Boyle 
Cc: Jean St-Laurent ; Ca By ; North 
American Network Operators' Group 
Subject: Re: IPv6 and CDN's

 

That's a start, I guess. Before all they had was some weird VPN something or 
other. Let me guess though: they are monetizing their market failure.

Re: IPv6 and CDN's

[Michael Thomas]

On 11/26/21 4:30 PM, Oliver O'Boyle wrote:
AWS has been gradually improving support and adding features. They 
just announced this service, which might help with adoption:


https://aws.amazon.com/about-aws/whats-new/2021/11/aws-nat64-dns64-communication-ipv6-ipv4-services/


That's a start, I guess. Before all they had was some weird VPN 
something or other. Let me guess though: they are monetizing their 
market failure.


Mike





On Fri., Nov. 26, 2021, 19:28 Michael Thomas,  wrote:


On 11/26/21 4:15 PM, Jean St-Laurent wrote:


We now have apple and fb saying ipv6 is faster than ipv4.

If we can onboard Amazon, Netflix, Google and some others, then
it is a done deal that ipv6 is indeed faster than ipv4.

Hence, an easy argument to tell your CFO that you need IPv6 for
your CDN.


Netflix is already v6 ready. The biggest obstacle is probably aws
because that's where a lot of the long tail of the internet
resides. Lobbying them would get the most bang for the buck.

Mike

Re: IPv6 and CDN's

[Oliver O'Boyle]

AWS has been gradually improving support and adding features. They just
announced this service, which might help with adoption:

https://aws.amazon.com/about-aws/whats-new/2021/11/aws-nat64-dns64-communication-ipv6-ipv4-services/


On Fri., Nov. 26, 2021, 19:28 Michael Thomas,  wrote:

>
> On 11/26/21 4:15 PM, Jean St-Laurent wrote:
>
> We now have apple and fb saying ipv6 is faster than ipv4.
>
>
>
> If we can onboard Amazon, Netflix, Google and some others, then it is a
> done deal that ipv6 is indeed faster than ipv4.
>
>
>
> Hence, an easy argument to tell your CFO that you need IPv6 for your CDN.
>
> Netflix is already v6 ready. The biggest obstacle is probably aws because
> that's where a lot of the long tail of the internet resides. Lobbying them
> would get the most bang for the buck.
>
> Mike
>
>

Re: IPv6 and CDN's

[Michael Thomas]

On 11/26/21 4:15 PM, Jean St-Laurent wrote:


We now have apple and fb saying ipv6 is faster than ipv4.

If we can onboard Amazon, Netflix, Google and some others, then it is 
a done deal that ipv6 is indeed faster than ipv4.


Hence, an easy argument to tell your CFO that you need IPv6 for your CDN.

Netflix is already v6 ready. The biggest obstacle is probably aws 
because that's where a lot of the long tail of the internet resides. 
Lobbying them would get the most bang for the buck.


Mike

RE: IPv6 and CDN's

[Jean St-Laurent via NANOG]

We now have apple and fb saying ipv6 is faster than ipv4.

 

If we can onboard Amazon, Netflix, Google and some others, then it is a done 
deal that ipv6 is indeed faster than ipv4.

 

Hence, an easy argument to tell your CFO that you need IPv6 for your CDN.

 

Xmas is coming so the budget season. Who knows. You might get lucky this year.

 

From: NANOG  On Behalf Of Michael 
Thomas
Sent: November 26, 2021 6:20 PM
To: Ca By 
Cc: nanog@nanog.org
Subject: Re: IPv6 and CDN's

 

 

On 11/26/21 3:11 PM, Ca By wrote:

 

 

On Fri, Nov 26, 2021 at 6:07 PM Michael Thomas mailto:m...@mtcc.com> > wrote:

 

On 11/26/21 1:44 PM, Jean St-Laurent via NANOG wrote:

Here are some maths and 1 argument kicking ass pitch for CFO’s that use iphones.

Apple tells app devs to use IPv6 as it's 1.4 times faster than IPv4

https://www.zdnet.com/article/apple-tells-app-devs-to-use-ipv6-as-its-1-4-times-faster-than-ipv4/

 

Build around that maybe?

 

This really hits my bs meter big time. I can't see how nat'ing is going to 
cause a 40% performance hit during connections. The article also mentions http2 
(and later v3) which definitely make big improvements so I'm suspecting that 
the author is conflating them.

Mike

 

Ok, take the same ipv6 is faster claim from facebook

 

https://www.internetsociety.org/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/

 

 

Still really thin with details of why. At least this says that they are NAT'ing 
v4 at *their* edge. But 99% of the lag of filling your newsfeed is their 
backend and transport, not connection times so who knows what they are actually 
measuring. Most NAT'ing is done at the consumer end by your home router in any 
case. 

Mike

Re: Latency/Packet Loss on ASR1006

[Fiona Weber via NANOG]

Hi

we see similar problems on ASR1006-X with ESP100 and MIP100. At about 
~45 Gbit/s of traffic (on ~30k PPPoE Sessions and ~700k CGN sessions) 
the QFP utilization skyrockets from ~45 % straight to ~95 % :(
I don't know if it's the CGN sessions or the traffic/packets causing the 
load increase, the datasheet says it supports something like 10M 
sessions but maybe not if you really intend to push packets through it?
We have not seen such spikes with way higher pps, but lower CGN session 
count, when we had DDoS Attacks against end customers.


Fiona

On 11/26/21 20:09, Colin Legendre wrote:

Hi,

We have ...

ASR1006  that has following cards...
1 x ESP40
1 x SIP40
4 x SPA-1x10GE-L-V2
1 x 6TGE
1 x RP2

We've been having latency and packet loss during peak periods...

We notice all is good until we reach 50% utilization on output of...

'show platform hardware qfp active datapath utilization summary'

Literally ... 47% good... 48% good... 49% latency to next hop goes 
from 1ms to 15-20ms... 50% we see 1-2% packet-loss and 30-40ms 
latency... 53% we see 60-70ms latency and 8-10% packet loss.


Is this expected... the ESP40 can only really push 20G and then starts 
to have performance issues?




---
Colin Legendre

Re: IPv6 and CDN's

[Michael Thomas]

On 11/26/21 3:11 PM, Ca By wrote:



On Fri, Nov 26, 2021 at 6:07 PM Michael Thomas  wrote:


On 11/26/21 1:44 PM, Jean St-Laurent via NANOG wrote:


Here are some maths and 1 argument kicking ass pitch for CFO’s
that use iphones.

*Apple tells app devs to use IPv6 as it's 1.4 times faster than IPv4*


https://www.zdnet.com/article/apple-tells-app-devs-to-use-ipv6-as-its-1-4-times-faster-than-ipv4/

Build around that maybe?



This really hits my bs meter big time. I can't see how nat'ing is
going to cause a 40% performance hit during connections. The
article also mentions http2 (and later v3) which definitely make
big improvements so I'm suspecting that the author is conflating them.

Mike


Ok, take the same ipv6 is faster claim from facebook

https://www.internetsociety.org/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/


Still really thin with details of why. At least this says that they are 
NAT'ing v4 at *their* edge. But 99% of the lag of filling your newsfeed 
is their backend and transport, not connection times so who knows what 
they are actually measuring. Most NAT'ing is done at the consumer end by 
your home router in any case.


Mike

Re: IPv6 and CDN's

[Ca By]

On Fri, Nov 26, 2021 at 6:07 PM Michael Thomas  wrote:

>
> On 11/26/21 1:44 PM, Jean St-Laurent via NANOG wrote:
>
> Here are some maths and 1 argument kicking ass pitch for CFO’s that use
> iphones.
>
> *Apple tells app devs to use IPv6 as it's 1.4 times faster than IPv4*
>
>
> https://www.zdnet.com/article/apple-tells-app-devs-to-use-ipv6-as-its-1-4-times-faster-than-ipv4/
>
>
>
> Build around that maybe?
>
> This really hits my bs meter big time. I can't see how nat'ing is going to
> cause a 40% performance hit during connections. The article also mentions
> http2 (and later v3) which definitely make big improvements so I'm
> suspecting that the author is conflating them.
>
> Mike
>

Ok, take the same ipv6 is faster claim from facebook

https://www.internetsociety.org/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/



>

Re: IPv6 and CDN's

[Michael Thomas]

On 11/26/21 1:44 PM, Jean St-Laurent via NANOG wrote:


Here are some maths and 1 argument kicking ass pitch for CFO’s that 
use iphones.


*Apple tells app devs to use IPv6 as it's 1.4 times faster than IPv4*

https://www.zdnet.com/article/apple-tells-app-devs-to-use-ipv6-as-its-1-4-times-faster-than-ipv4/

Build around that maybe?


This really hits my bs meter big time. I can't see how nat'ing is going 
to cause a 40% performance hit during connections. The article also 
mentions http2 (and later v3) which definitely make big improvements so 
I'm suspecting that the author is conflating them.


Mike

RE: IPv6 and CDN's

[Jean St-Laurent via NANOG]

With that specific line directly from Apple:

 

"And when IPv6 is in use, the median connection setup is 1.4 times faster than 
IPv4. This is primarily due to reduced NAT usage and improved routing."

 

There it is, Improved routing.

 

Jean

 

From: Jean St-Laurent  
Sent: November 26, 2021 4:44 PM
To: 'Mike Hammett' ; 'Jose Luis Rodriguez' 

Cc: 'nanog@nanog.org' 
Subject: RE: IPv6 and CDN's

 

Here are some maths and 1 argument kicking ass pitch for CFO’s that use iphones.

Apple tells app devs to use IPv6 as it's 1.4 times faster than IPv4

https://www.zdnet.com/article/apple-tells-app-devs-to-use-ipv6-as-its-1-4-times-faster-than-ipv4/

 

Build around that maybe?

 

Jean

 

From: Mike Hammett mailto:na...@ics-il.net> > 
Sent: November 26, 2021 11:56 AM
To: Jose Luis Rodriguez mailto:jlrodrig...@gmail.com> >
Cc: nanog@nanog.org  ; Jean St-Laurent 
mailto:j...@ddostest.me> >
Subject: Re: IPv6 and CDN's

 

Care to explain because the alternative seems pretty self-evident.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

 

  _  

RE: IPv6 and CDN's

[Jean St-Laurent via NANOG]

Here are some maths and 1 argument kicking ass pitch for CFO’s that use iphones.

Apple tells app devs to use IPv6 as it's 1.4 times faster than IPv4

https://www.zdnet.com/article/apple-tells-app-devs-to-use-ipv6-as-its-1-4-times-faster-than-ipv4/

 

Build around that maybe?

 

Jean

 

From: Mike Hammett  
Sent: November 26, 2021 11:56 AM
To: Jose Luis Rodriguez 
Cc: nanog@nanog.org; Jean St-Laurent 
Subject: Re: IPv6 and CDN's

 

Care to explain because the alternative seems pretty self-evident.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

 

  _  

Re: SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Gavin Henry]

On Fri, 26 Nov 2021, 18:59 Max Tulyev,  wrote:

> Hi Gavin,
>

Hi Max,


> I thought to do something similar ;)
>

What stopped you creating something? Or did you? Interested :)



> As I can see in the code, you count somebody as a bad actor just because
> of one UDP packet is received. It is a bad idea, because it is easy to
> spoof that packet and make a DoS against some good actor.
>

The next stage is to tag these probes as passive, then reply in SIP, like
you say and allow registrations and calls etc then mark them as aggressive.

I'm not actually replying to the packets, so no reflection attacks.


> Right way: you have to simulate a SIP dialog with this actor, i.e. reply
> them something and wait for the reaction. If the reaction will be like
> in a normal SIP call processing - congratulations, you found a hacker!
> If not, like you sent them a packet they do not expect - it is a DoS and
> a spoofed packet.
>

Agreed!

Thank you for reading and your reply.

>

RE: Latency/Packet Loss on ASR1006

[Tony Wicks]

https://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/200674-Throughput-issues-on-ASR1000-Series-rout.html

 

So many years since I have used an asr1000 but, honestly you have an esp40 in a 
box with 10x10G interfaces? That’s a very underpowered processor for that job. 
The ESP40 was designed for a box that would have 1G interfaces and perhaps a 
couple of 10’s. The ASR1000 is a CPU based box, everything goes back to the 
processor and remember cisco math means half duplex not full.

 

From: NANOG  On Behalf Of Colin 
Legendre
Sent: Saturday, 27 November 2021 8:09 am
To: nanog 
Subject: Latency/Packet Loss on ASR1006

 

Hi,

 

We have ...

 

ASR1006  that has following cards...

1 x ESP40

1 x SIP40

4 x SPA-1x10GE-L-V2

1 x 6TGE

1 x RP2

 

We've been having latency and packet loss during peak periods...

 

We notice all is good until we reach 50% utilization on output of...

 

'show platform hardware qfp active datapath utilization summary'

 

Literally ... 47% good... 48% good... 49% latency to next hop goes from 1ms to 
15-20ms... 50% we see 1-2% packet-loss and 30-40ms latency... 53% we see 
60-70ms latency and 8-10% packet loss.

 

Is this expected... the ESP40 can only really push 20G and then starts to have 
performance issues?

 

 

 

---
Colin Legendre

Latency/Packet Loss on ASR1006

[Colin Legendre]

Hi,

We have ...

ASR1006  that has following cards...
1 x ESP40
1 x SIP40
4 x SPA-1x10GE-L-V2
1 x 6TGE
1 x RP2

We've been having latency and packet loss during peak periods...

We notice all is good until we reach 50% utilization on output of...

'show platform hardware qfp active datapath utilization summary'

Literally ... 47% good... 48% good... 49% latency to next hop goes from 1ms
to 15-20ms... 50% we see 1-2% packet-loss and 30-40ms latency... 53% we see
60-70ms latency and 8-10% packet loss.

Is this expected... the ESP40 can only really push 20G and then starts to
have performance issues?



---
Colin Legendre

Re: SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Max Tulyev]

Hi Gavin,

I thought to do something similar ;)

As I can see in the code, you count somebody as a bad actor just because 
of one UDP packet is received. It is a bad idea, because it is easy to 
spoof that packet and make a DoS against some good actor.


Right way: you have to simulate a SIP dialog with this actor, i.e. reply 
them something and wait for the reaction. If the reaction will be like 
in a normal SIP call processing - congratulations, you found a hacker! 
If not, like you sent them a packet they do not expect - it is a DoS and 
a spoofed packet.


24.11.21 23:19, Gavin Henry пише:

Hi all,

I hope you don't mind the post, but thought this might be of use and
in the spirit of release early, release often I've done an alpha
release:

https://github.com/SentryPeer/SentryPeer

There's a presentation too if you'd like to watch/read where I hope to
go with this:

https://blog.tadsummit.com/2021/11/17/sentrypeer/

Working on the API and web UI next, then the p2p part of it. Feel free
to submit any feature requests or have a play :-)

Thanks for reading and any feedback is welcome!

Weekly Global IPv4 Routing Table Report

[Routing Table Analysis Role Account]

This is an automated weekly mailing describing the state of the Gobal
IPv4 Routing Table  as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

Global IPv4 Routing Table Report   04:00 +10GMT Sat 27 Nov, 2021

  BGP Table  as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  872472
Prefixes after maximum aggregation (per Origin AS):  330087
Deaggregation factor:  2.64
Unique aggregates announced (without unneeded subnets):  421607
Number of IPv4 prefixes with ROAs (including AS0):   247772
Total ASes present in the Internet Routing Table: 72382
Prefixes per ASN: 12.05
Origin-only ASes present in the Internet Routing Table:   62143
Origin ASes announcing only one prefix:   25685
Transit ASes present in the Internet Routing Table:   10239
Transit-only ASes present in the Internet Routing Table:357
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  53
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:   893
Number of instances of unregistered ASNs:   897
Number of 32-bit ASNs allocated by the RIRs:  37925
Number of 32-bit ASNs visible in the Routing Table:   31495
Prefixes from 32-bit ASNs in the Routing Table:  145183
Number of bogon 32-bit ASNs visible in the Routing Table:24
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:862
Number of addresses announced to Internet:   3071623936
Equivalent to 183 /8s, 21 /16s and 67 /24s
Percentage of available address space announced:   83.0
Percentage of allocated address space announced:   83.0
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  290843

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   231533
Total APNIC prefixes after maximum aggregation:   64938
APNIC Deaggregation factor:3.57
Prefixes being announced from the APNIC address blocks:  226709
Unique aggregates announced from the APNIC address blocks:93050
APNIC Region origin ASes present in the Internet Routing Table:   12153
APNIC Prefixes per ASN:   18.65
APNIC Region origin ASes announcing only one prefix:   3493
APNIC Region transit ASes present in the Internet Routing Table:   1710
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 37
Number of APNIC region 32-bit ASNs visible in the Routing Table:   7333
Number of APNIC addresses announced to Internet:  773087360
Equivalent to 46 /8s, 20 /16s and 96 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-151865
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:256209
Total ARIN prefixes after maximum aggregation:   118264
ARIN Deaggregation factor: 2.17
Prefixes being announced from the ARIN address blocks:   255844
Unique aggregates announced from the ARIN address blocks:122186
ARIN Region origin ASes present in the Internet 

Re: IPv6 and CDN's

[Mike Hammett]

Care to explain because the alternative seems pretty self-evident. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Jose Luis Rodriguez"  
To: "Jean St-Laurent"  
Cc: nanog@nanog.org 
Sent: Friday, November 26, 2021 8:16:53 AM 
Subject: Re: IPv6 and CDN's 

Well … YMMV. We’ve been running v6 for years, and it didn’t really make a dent 
in spend or boxes or rate of v4 depletion. Big part of the problem in our neck 
of the woods is millions of v4-only terminals … as well as large customer/gov 
bids requiring tons of v4 address space. 

> On Nov 26, 2021, at 07:04, Jean St-Laurent via NANOG  wrote: 
> 
> With a kicking ass pitch 
> 
> -Original Message- 
> From: NANOG  On Behalf Of Mark 
> Tinka 
> Sent: November 26, 2021 5:52 AM 
> To: nanog@nanog.org 
> Subject: Re: IPv6 and CDN's 
> 
> 
> 
>> On 11/3/21 22:13, Max Tulyev wrote: 
>> 
>> Implementing IPv6 reduces costs for CGNAT. You will have (twice?) less 
>> traffic flow through CGNAT, so cheaper hardware and less IPv4 address 
>> space. Isn't it? 
> 
> How to express that in numbers CFO can take to the bank? 
> 
> Mark. 
> 

Re: IPv6 and CDN's

[Jose Luis Rodriguez]

Well … YMMV. We’ve been running v6 for years, and it didn’t really make a dent 
in spend or boxes or rate of v4 depletion. Big part of the problem in our neck 
of the woods is millions of v4-only terminals … as well as large customer/gov 
bids requiring tons of v4 address space. 

> On Nov 26, 2021, at 07:04, Jean St-Laurent via NANOG  wrote:
> 
> With a kicking ass pitch
> 
> -Original Message-
> From: NANOG  On Behalf Of Mark Tinka
> Sent: November 26, 2021 5:52 AM
> To: nanog@nanog.org
> Subject: Re: IPv6 and CDN's
> 
> 
> 
>> On 11/3/21 22:13, Max Tulyev wrote:
>> 
>> Implementing IPv6 reduces costs for CGNAT. You will have (twice?) less 
>> traffic flow through CGNAT, so cheaper hardware and less IPv4 address 
>> space. Isn't it?
> 
> How to express that in numbers CFO can take to the bank?
> 
> Mark.
> 

Re: IPv6 and CDN's

[Frank Habicht]

On 26/11/2021 13:52, Mark Tinka wrote:

On 11/3/21 22:13, Max Tulyev wrote:
Implementing IPv6 reduces costs for CGNAT. You will have (twice?) less 
traffic flow through CGNAT, so cheaper hardware and less IPv4 address 
space. Isn't it?


How to express that in numbers CFO can take to the bank?


"want to buy 5 of those shiny new CGNAT boxes or only 2 ?"

Frank

RE: IPv6 and CDN's

[Jean St-Laurent via NANOG]

With a kicking ass pitch

-Original Message-
From: NANOG  On Behalf Of Mark Tinka
Sent: November 26, 2021 5:52 AM
To: nanog@nanog.org
Subject: Re: IPv6 and CDN's



On 11/3/21 22:13, Max Tulyev wrote:

> Implementing IPv6 reduces costs for CGNAT. You will have (twice?) less 
> traffic flow through CGNAT, so cheaper hardware and less IPv4 address 
> space. Isn't it?

How to express that in numbers CFO can take to the bank?

Mark.

Re: SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Gavin Henry]

On Thu, 25 Nov 2021 at 00:53, Eric Kuhnke  wrote:
>
> Anecdotally, anyone that's had reason to manually go through logs for port 
> 5060 SIP for any public facing ipv4 /32 will see the vast amounts of random 
> "things" out there on the internet trying common extension password combos to 
> register.
>
> It's been a large amount of background noise on the internet for a very log 
> time now.

Hi Eric,

Have you done anything with this data before?

Thanks.

Re: IPv6 and CDN's

[Mark Tinka]

On 11/3/21 22:13, Max Tulyev wrote:

Implementing IPv6 reduces costs for CGNAT. You will have (twice?) less 
traffic flow through CGNAT, so cheaper hardware and less IPv4 address 
space. Isn't it?


How to express that in numbers CFO can take to the bank?

Mark.

Re: Validating multi-path in production?

[Mark Tinka]

On 11/12/21 23:47, Jeff Tantsura wrote:


LAG - Micro BFD (RFC7130) provides per constituent livability.


Not sure if this has changed, but the last time I looked into it, Micro 
BFD's for LAG's was only supported and functional on point-to-point 
Ethernet links.


In cases where you are running a LAN, it did not apply.

We gave up running BFD on LAG's on LAN's, because of this issue.

Mark.