Re: DC Power choices (was Re: Network visibility)

[Bryan Fields]

On 10/22/21 1:13 AM, Jay R. Ashworth wrote:
> It was, in fact, pretty impressive to look at.  But I was a little worried 
> about 
> the loading on the building frame.  :-)
> 
> And while I think there might be advantages in running power supplies in gear
> at -48, I'd want to rectify it in the cage, preferably from 480/3ph.

High voltage DC (400v) has all the advantages of DC with none of the lossy
drawbacks of -48v.  What's nice is most every AC PSU now will run off it with
minor modifications, so it's trivial for vendors to support.  Nokia and
Juniper even do it in the same AD/HVDC supply.

I like DC, it's much simpler, but it's a lower volume product.  One advantage
to AC is I can call any electrocution and they can run a cable in a pinch for
me.  DC, even though it's the same physics, is harder to find experienced tech
to work with.

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: IPv6 and CDN's

[Fred Baker]

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

> On Oct 23, 2021, at 1:55 PM, Christopher Morrow  
> wrote:
> 
>> On Sat, Oct 23, 2021, 15:17 Fred Baker  wrote:
>> I think you will find that there are some places in which getting IPv6 
>> network service has been difficult, and as a result even IPv6-
> 
> 
> Fred, do you mean places like, all of Verizon FiOS?

That would be an example. If I traceroute to an ipv6 address, the fact that I 
get a response is proof that the path works. F root has some servers for which, 
MOU be damned, there is no working IPv6 path. Mumble…

>> capable equipment is not reachable by IPv6. Those are, however, few and far 
>> between.
>> 
>> Sent using a machine that autocorrects in interesting ways...
>> 
>> > On Oct 23, 2021, at 6:04 AM, David Conrad  wrote:
>> > 
>> > So, in theory, all the root servers should be available via IPv6 and, as 
>> > far as I can tell, they are.

Re: IPv6 and CDN's

[Bryan Fields]

On 10/23/21 9:30 AM, Ca By wrote:
>> Until IPv6 becomes provides a way to make money for the ISP, I don't see it
>> being offered outside of the datacenter.
> 
> 87% of mobiles in the usa are ipv6
> 
> https://www.worldipv6launch.org/measurements/

Mobile is different, v6 makes financial sense as CG NAT doesn't scale to 400m
cell phones in north America. (does NANOG scope include Mexico?)

That said most (all) IPv6 cellular providers still don't use it for end to end
connectivity, as inbound connections are silently dropped.  In the US if you
want inbound connectivity to work via cellular, you must to buy the static IP
service from Verizon, and it has no IPv6 support, and no plans for it in the
future.

Oddly enough the MVNO services over T-Mobile seem to allow inbound IPv6, but
TMO proper doesn't.  V6 that works everywhere would simplify a _huge_
connectivity problem for me.


-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: IPv6 and CDN's

[Bryan Fields]

On 10/23/21 9:03 AM, David Conrad wrote:
> Bryan,
>
>> Even the DNS root servers are not 100% reachable via IPv6.
> 
> Excepting temporary failures, they are as far as I am aware. Why do you
> think they aren’t?

I can't reach C, 2001:500:2::c, from many places in v6 land.  My home and
secondary data center can't reach it, but my backup VM's at another data
center can.



> However, the IANA team is not the enforcement arm of the Internet. If a
> root server operator chooses to not abide by RFC 7720, there is nothing the
> IANA team can do unilaterally other than make the root server operator
> aware of the fact.

Surely IANA has the power to compel a root server operator to abide by policy
or they lose the right to be a root server?

>> Until IPv6 becomes provides a way to make money for the ISP, I don't see
>> it being offered outside of the datacenter.
> 
> Different markets, different approaches.  In the areas I’ve lived in Los
> Angeles, commodity residential service via AT&T (1 Gbps up/down fiber) and
> Spectrum (varying speeds) is dual stack by default (as far as I can tell).
> I suspect all it would take would be one of the providers in your area to
> offer IPv6 and advertise the fact in their marketing to cause the others to
> fall into line.

Prior ISP charged me $15/month per IPv4 address and a mandatory router rent of
$10/month.  New one gets $5/month per IPv4 address.  The reason for this is IP
scarcity.  They have plenty of v4 space, so this allows them to charge for it.
v6 isn't going to make them any more money as they can't charge for it.


-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: IPv6 and CDN's

[Christopher Morrow]

On Sat, Oct 23, 2021, 15:17 Fred Baker  wrote:

> I think you will find that there are some places in which getting IPv6
> network service has been difficult, and as a result even IPv6-


Fred, do you mean places like, all of Verizon FiOS?


capable equipment is not reachable by IPv6. Those are, however, few and far
> between.
>
> Sent using a machine that autocorrects in interesting ways...
>
> > On Oct 23, 2021, at 6:04 AM, David Conrad  wrote:
> >
> > So, in theory, all the root servers should be available via IPv6 and, as
> far as I can tell, they are.
>

Re: IPv6 and CDN's

[Gustav Ulander]

And ipv4 I presume so there is still easier and cost less money to just go with 
that. 
From our point as an MSP no customer has a requirement that they want to be 
able to be reached via IPV6 so it’s still cheaper to buy up IPV4 address space 
and do a lot of nat than to convert all our services to function properly with 
IPV6. 
Sure one could argue that they should have been made that way from the 
beginning but without customer demand why would we spend the money? 

//Gustav 


> 23 okt. 2021 kl. 15:33 skrev Ca By :
> 
> 
> 
> 
>> On Fri, Oct 22, 2021 at 8:48 AM Bryan Fields  wrote:
>> On 10/22/21 11:13 AM, Job Snijders via NANOG wrote:
>> > Another aspect that flabbergasts me anno 2021 is how there *still* are
>> > BGP peering disputes between (more than two) major global internet service
>> > providers in which IPv6 is 'held hostage' as part of slow commercial
>> > negotiations. Surely end-to-end IPv6 connectivity should be a priority?
>> 
>> Even the DNS root servers are not 100% reachable via IPv6.  I would think 
>> IANA
>> would have some standard about reachability for root operators.
>> 
>> FWIW, I just was able to change my home office internet (I reside in the most
>> densely populated county of Florida).  The new provider sold me a dual stack
>> connection, however when they came to deliver it, there was no IPv6 as
>> promised.  After spending almost a week playing phone tag, I finally got some
>> one with clue.  I was told they have no support if IPv6 and no plans to ever
>> support IPv6 as there is no way to monetize it.
>> 
>> This leaves me in the same position as my prior circuit via the local cable
>> co. (no plans to offer IPv6) but at least it's faster than the 2 meg up cable
>> service.
>> 
>> Until IPv6 becomes provides a way to make money for the ISP, I don't see it
>> being offered outside of the datacenter.
> 
> 87% of mobiles in the usa are ipv6
> 
> https://www.worldipv6launch.org/measurements/
> 
> 
> 
> 
>> 
>> -- 
>> Bryan Fields
>> 
>> 727-409-1194 - Voice
>> http://bryanfields.net

Re: [routing-wg] Relative size of IRR registries

[Rubens Kuhl]

You are right on all counts but (3). IRRd 4.2 has a feature called
scope filter, and the results below had the following in effect:

scopefilter:

prefixes:

- 10.0.0.0/8

- 172.16.0.0/12

- 192.168.0.0/16

asns:

- 23456

- 64496-64511

So they already excluded those easy to detect unassigned blocks. It
doesn't exclude blocks that are assigned by IANA but not yet by a
RIR/NIR (like Team Cymru bogon feeds), but is good enough.


Rubens

On Sat, Oct 23, 2021 at 2:43 PM Aliaksei Sheshka  wrote:
>
> To understand the impact of the non-auth registries one need to
> eliminate from their obj count 1) route/AS-SET objects which are also
> present in the authoritative registries 2) prefixes which can be
> derived from the RPKI ROA data 3) outright wrong data like private and
> invalid ranges.
> Additionally to eliminate 4) stale data, which is more challenging yet
> possible to estimate. Remove 5) non-cooperative registries.
>
> After all that I found that for my cases non-authoritative registries
> are more burden than help.
>
> Your mileage may vary.
>
>
>
>
>
>
> On Sat, 23 Oct 2021 09:48:40 -0300
> Rubens Kuhl  wrote:
>
> > Recent discussions about ARIN-NONAUTH made me wonder what would be the
> > impact of discontinuing *-NONAUTH IRR registries. These are the
> > current size of all IRR registries I was able to mirror, ordered by
> > the number of aut-num objects.
> >
> >
> > source | total obj | rt obj | aut-num obj
> > RIPE 948401 368596 37284
> > APNIC 879374 572495 17737
> > RADB 1533619 1344618 8787
> > TC 21423 8531 3412
> > ARIN 134512 50543 2211
> > RIPE-NONAUTH 58436 54807 2163
> > AFRINIC 121639 94734 2057
> > IDNIC 8541 4574 1713
> > ALTDB 25598 18319 1395
> > LACNIC 8008 4742 1039
> > ARIN-NONAUTH 67715 62471 939
> > WCGDB 65135 62849 773
> > NTTCOM 453257 444518 548
> > JPIRR 13404 11398 425
> > LEVEL3 111770 91524 299
> > CANARIE 1869 1455 177
> > BELL 29827 29613 105
> > BBOI 1291 924 56
> > RGNET 74 40 6
> > NESTEGG 8 4 2
> > REACH 20310 18207 2
> > HOST 2 0 1
> > OPENFACE 25 17 1
> > PANIX 42 40 1
> >
>

Re: ipv4 on mobile networks

[Michael Thomas]

On 10/23/21 11:52 AM, Ca By wrote:



On Sat, Oct 23, 2021 at 10:33 AM Michael Thomas  wrote:

So I'm curious how the mobile operators deploying ipv6 to the
handsets are dealing with ipv4. The simplest would be to get the
phone a routable ipv4 address, but that would seemingly exacerbate
the reason they went to v6 in the first place.

First, consider that the 3  major cell carriers in the usa each have 
100 million customers.  Also, consider they all now have a home 
broadband angle. Where do 100 million ipv4 addresses come from?  Not 
rfc 1918, not arin, … and we are just talking about customer ip 
addresses, not considering towers, backend systems, call centers, 
retail ….


So the genesis of 464xlat / rfc 6877 is that ipv4 cannot go where we 
need to go, the mobile architecture must be ipv6 to be comply with the 
e2e principle and not constrain the scaling of the customers / edge. 
Other cell carriers believe in operating many unique ipv4 networks … 
like a 10.0.0.0/8  per metro, but even that breaks 
down and cannot scale… and you end up with proxies / nats / sbcs 
everywhere just to make internal apps like ims work, which is a lot of 
state.


464, that's what i was looking for... there are so many transition 
schemes i wasn't sure which one they chose. So it's essentially double 
NAT'ing. Does that require TURN too for streaming? I can't remember what 
the limitations of STUN are.




Are carriers NAT'ing somewhere along the line? If so, where? Like
does the phone encapsulate v4 in 4-in-6? Or does the phone get a
net 10 address and it gets NAT'd by the carrier?


~80% of traffic goes to fb, goog, yt, netflix, bing, o364, hbomax, 
apple tv, … all of which are ipv6. So, only 20% of traffic requires 
nat, when you have ipv6. I am hoping tiktoc and aws move to be default 
on for ipv6 soon.


Yeah, aws is the most glaring since it probably hosts a significant 
portion of the long tail. it appears that aws only supports v6 with 
vpn's. Google only appears to support v6 if you use their load balancer. 
Sad.


Mike

Re: IPv6 and CDN's

[Fred Baker]

I think you will find that there are some places in which getting IPv6 network 
service has been difficult, and as a result even IPv6-capable equipment is not 
reachable by IPv6. Those are, however, few and far between.

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

> On Oct 23, 2021, at 6:04 AM, David Conrad  wrote:
> 
> So, in theory, all the root servers should be available via IPv6 and, as far 
> as I can tell, they are.

Re: ipv4 on mobile networks

[Ca By]

On Sat, Oct 23, 2021 at 10:33 AM Michael Thomas  wrote:

> So I'm curious how the mobile operators deploying ipv6 to the handsets are
> dealing with ipv4. The simplest would be to get the phone a routable ipv4
> address, but that would seemingly exacerbate the reason they went to v6 in
> the first place.
>
First, consider that the 3  major cell carriers in the usa each have 100
million customers.  Also, consider they all now have a home broadband
angle. Where do 100 million ipv4 addresses come from?  Not rfc 1918, not
arin, … and we are just talking about customer ip addresses, not
considering towers, backend systems, call centers, retail ….

So the genesis of 464xlat / rfc 6877 is that ipv4 cannot go where we need
to go, the mobile architecture must be ipv6 to be comply with the e2e
principle and not constrain the scaling of the customers / edge. Other cell
carriers believe in operating many unique ipv4 networks … like a 10.0.0.0/8
per metro, but even that breaks down and cannot scale… and you end up with
proxies / nats / sbcs everywhere just to make internal apps like ims work,
which is a lot of state.

Are carriers NAT'ing somewhere along the line? If so, where? Like does the
> phone encapsulate v4 in 4-in-6? Or does the phone get a net 10 address and
> it gets NAT'd by the carrier?
>

~80% of traffic goes to fb, goog, yt, netflix, bing, o364, hbomax, apple
tv, … all of which are ipv6. So, only 20% of traffic requires nat, when you
have ipv6. I am hoping tiktoc and aws move to be default on for ipv6 soon.

The nats dont scale well and take the brunt of attacks, so services that
require nat suffer. Real shame, but they have a path to improve performance
by deploying ipv6.  Thats why performance driven companies use ipv6 (fb,
goog, akamai, …)

>
> It seems also for mobile carriers there is incentive for as much transit
> as possible for native v6 to the servers. Or is the deployment of v6 mainly
> within the carrier network itself and it's NAT'd somewhere?
>
> Basically what does a typical v6/v4 architecture look like for a mobile
> carrier these days?
>
> Mike
>
>
> On 10/23/21 8:13 AM, Brian Johnson wrote:
>
>
>
> On Oct 23, 2021, at 8:30 AM, Ca By  wrote:
>
> 87% of mobiles in the usa are ipv6
>
> https://www.worldipv6launch.org/measurements/
>
>
>
> Agreed. When they have to connect to an IPv4 only host, they do some type
> of AFTR. These devices have never known a world outside of this situation.
> That is a major difference.
>
>
>
>
>
>> --
>> Bryan Fields
>>
>> 727-409-1194 - Voice
>> http://bryanfields.net
>
>
>

ipv4 on mobile networks

[Michael Thomas]

So I'm curious how the mobile operators deploying ipv6 to the handsets 
are dealing with ipv4. The simplest would be to get the phone a routable 
ipv4 address, but that would seemingly exacerbate the reason they went 
to v6 in the first place. Are carriers NAT'ing somewhere along the line? 
If so, where? Like does the phone encapsulate v4 in 4-in-6? Or does the 
phone get a net 10 address and it gets NAT'd by the carrier?


It seems also for mobile carriers there is incentive for as much transit 
as possible for native v6 to the servers. Or is the deployment of v6 
mainly within the carrier network itself and it's NAT'd somewhere?


Basically what does a typical v6/v4 architecture look like for a mobile 
carrier these days?


Mike


On 10/23/21 8:13 AM, Brian Johnson wrote:




On Oct 23, 2021, at 8:30 AM, Ca By  wrote:

87% of mobiles in the usa are ipv6

https://www.worldipv6launch.org/measurements/




Agreed. When they have to connect to an IPv4 only host, they do some 
type of AFTR. These devices have never known a world outside of this 
situation. That is a major difference.







--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: IPv6 and CDN's

[Brian Johnson]

> On Oct 23, 2021, at 8:30 AM, Ca By  wrote:
> 
> 87% of mobiles in the usa are ipv6
> 
> https://www.worldipv6launch.org/measurements/ 
> 
> 

Agreed. When they have to connect to an IPv4 only host, they do some type of 
AFTR. These devices have never known a world outside of this situation. That is 
a major difference.


> 
> 
> 
> -- 
> Bryan Fields
> 
> 727-409-1194 - Voice
> http://bryanfields.net 

Re: IPv6 and CDN's

[Ca By]

On Fri, Oct 22, 2021 at 8:48 AM Bryan Fields  wrote:

> On 10/22/21 11:13 AM, Job Snijders via NANOG wrote:
> > Another aspect that flabbergasts me anno 2021 is how there *still* are
> > BGP peering disputes between (more than two) major global internet
> service
> > providers in which IPv6 is 'held hostage' as part of slow commercial
> > negotiations. Surely end-to-end IPv6 connectivity should be a priority?
>
> Even the DNS root servers are not 100% reachable via IPv6.  I would think
> IANA
> would have some standard about reachability for root operators.
>
> FWIW, I just was able to change my home office internet (I reside in the
> most
> densely populated county of Florida).  The new provider sold me a dual
> stack
> connection, however when they came to deliver it, there was no IPv6 as
> promised.  After spending almost a week playing phone tag, I finally got
> some
> one with clue.  I was told they have no support if IPv6 and no plans to
> ever
> support IPv6 as there is no way to monetize it.
>
> This leaves me in the same position as my prior circuit via the local cable
> co. (no plans to offer IPv6) but at least it's faster than the 2 meg up
> cable
> service.
>
> Until IPv6 becomes provides a way to make money for the ISP, I don't see it
> being offered outside of the datacenter.


87% of mobiles in the usa are ipv6

https://www.worldipv6launch.org/measurements/





> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>

Re: IPv6 and CDN's

[David Conrad]

Bryan,

On Oct 22, 2021, at 11:45 AM, Bryan Fields  wrote:
> On 10/22/21 11:13 AM, Job Snijders via NANOG wrote:
>> Another aspect that flabbergasts me anno 2021 is how there *still* are
>> BGP peering disputes between (more than two) major global internet service
>> providers in which IPv6 is 'held hostage' as part of slow commercial
>> negotiations. Surely end-to-end IPv6 connectivity should be a priority?
> 
> Even the DNS root servers are not 100% reachable via IPv6.

Excepting temporary failures, they are as far as I am aware. Why do you think 
they aren’t?

> I would think IANA
> would have some standard about reachability for root operators.

I think you might misunderstand relationships here.

The IANA team’s standards are what the community defines. In the case of the 
root operators, RFC 7720 says “root service” must be available via IPv6 and 
RSSAC-001 (“Service Expectations of Root Servers”, 
https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf)
 says:

"[E.3.1-B] Individual Root Servers will deliver the service in conformance to 
IETF standards and requirements as described in RFC 7720 [4] and any other IETF 
standards-defined Internet Protocol as deemed appropriate."

So, in theory, all the root servers should be available via IPv6 and, as far as 
I can tell, they are.

However, the IANA team is not the enforcement arm of the Internet. If a root 
server operator chooses to not abide by RFC 7720, there is nothing the IANA 
team can do unilaterally other than make the root server operator aware of the 
fact.

> Until IPv6 becomes provides a way to make money for the ISP, I don't see it
> being offered outside of the datacenter.

Different markets, different approaches.  In the areas I’ve lived in Los 
Angeles, commodity residential service via AT&T (1 Gbps up/down fiber) and 
Spectrum (varying speeds) is dual stack by default (as far as I can tell).  I 
suspect all it would take would be one of the providers in your area to offer 
IPv6 and advertise the fact in their marketing to cause the others to fall into 
line.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Relative size of IRR registries

[Rubens Kuhl]

Recent discussions about ARIN-NONAUTH made me wonder what would be the
impact of discontinuing *-NONAUTH IRR registries. These are the
current size of all IRR registries I was able to mirror, ordered by
the number of aut-num objects.


source | total obj | rt obj | aut-num obj
RIPE 948401 368596 37284
APNIC 879374 572495 17737
RADB 1533619 1344618 8787
TC 21423 8531 3412
ARIN 134512 50543 2211
RIPE-NONAUTH 58436 54807 2163
AFRINIC 121639 94734 2057
IDNIC 8541 4574 1713
ALTDB 25598 18319 1395
LACNIC 8008 4742 1039
ARIN-NONAUTH 67715 62471 939
WCGDB 65135 62849 773
NTTCOM 453257 444518 548
JPIRR 13404 11398 425
LEVEL3 111770 91524 299
CANARIE 1869 1455 177
BELL 29827 29613 105
BBOI 1291 924 56
RGNET 74 40 6
NESTEGG 8 4 2
REACH 20310 18207 2
HOST 2 0 1
OPENFACE 25 17 1
PANIX 42 40 1