Geo location Contacts

[Brian]

Good day all. I am trying to find contacts at ipdata.co and ipinfo.io. I
recently acquired new ip space and most places have updated. But the above
2 have not and still show CA as the location for this ip space. Please feel
free to email me off the list.

Thank you
Brian

Dual Homed BGP

[Brian]

Hello all. I am having a hard time trying to articulate why a Dual Home ISP
should have full tables. My understanding has always been that full tables
when dual homed allow much more control. Especially in helping to prevent
Async routes.


Am I crazy?

Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Brian]

> On Feb 17, 2020, at 10:38 AM, Gene LeDuc  wrote:

Does this thread make me not only think about the days of old, but also
makes me feel older! Not going back as far as some here but around
1993ish...

My first connection back in the day was a shell account I was given as
consultant and reseller for what was TIAC (then became PSI). I was also
at the time running a 6 line MajorBBS system (prior to WorldGroup). TIAC
allowed multiple concurrent logins to the shell so I purchased the
MajorBBS dialout module and had it login to my shell account which my
cosysop crafted a nice menu for basic feature usage such as
ftp/lynx/irc/etc. Users could then use my dialout feature into my shell
and do what they were looking to do. 

Being somewhat out in the sticks and having a decent dial area coverage
it in a sense allowed me to become my local region's first ISP of sorts.
It was a hack but it worked and users were more than happy since for
many even dialing up to AOL or Compuserve was a toll call then.

-- 
If Confucius were alive today:
"A computing device left in the OFF power state never crashes" 
-
73 de Brian N1URO
IPv6 Certified
SMTP: n1uro-at-n1uro.ampr.org

Re: Router Suggestions

[Brian]

Yes I too looked into that. And it was not near that price. Please send me
and email off list. I would like to know where I might find that.

On Mon, Jun 15, 2020 at 2:58 PM Forrest Christian (List Account) <
li...@packetflux.com> wrote:

> We just got a MX204 quote and it was close to 2.5x the price you're
> quoting, with apparently the minimum license needed for full tables, and
> Next Day replacement.   So if it's really $11K, please shoot me an email
> off list.   Or if someone has a better place to get a decent quote for a
> MX204, or can clarify where this quote might have went wrong, that would be
> useful too.
>
> We're also looking at going the virtual router route where we put 2-3
> servers in a HA cluster loaded up with 10Gb interfaces and running some
> sort of routing software.  In case you didn't catch on, I'm fairly early in
> running this idea through the paces, although it seems like this is a
> pretty common thing nowadays.
>
> On Mon, Jun 15, 2020 at 6:02 AM Colton Conor 
> wrote:
>
>> For around $11,000 right now, you can get a brand new Juniper MX204
>> router. Alternatively, you can get a used MX240 / MX480 with quad power
>> supplies, redundant quad core RE's, and 2 16X10G MIC cards for around
>> $12,000.
>>
>> My question, is there anything else worth looking at in this price range
>> / port configuration? Open to both new and used options. Looking to take
>> full BGP routes.
>>
>>
>>
>
> --
> - Forrest
>

Re: Comcast DNS Assistance?

[Brian]

I as well seem to be having issues resolving DNS on comcast.

On Mon, Jul 6, 2020 at 8:57 AM Dave Dechellis  wrote:

> Hello,
>
> Last night we made some changes to our DNS-SEC environment at Tufts
> University and all changes seem to have propagated - but we're having
> issues resolving against Comcast's DNS servers.
>
> All DNS-SEC checking seems to be looking good post changes and other
> ISPs are resolving fine.
>
> Is there anyone from Comcast who might be able to validate behavior?
> I'm assuming it might take up to 1 day for TTL propagation.
>
> Thanks
> Dave
> david.dechel...@tufts.edu
>

Yahoo! admin

[Brian]

If there's a Yahoo! admin on list that can contact me offlist I'd
appreciate it. You have a TLS issue on IPv6 only that your front line
customer care people insist is an email sending related issue.

Please tell me the only way to speak to someone there is to pay a
monthly fee when your own coders are breaking your own services.

Thanks.

Ipv6 help

[Brian]

Is there anyway to deploy ipv6 and push ipv4  traffic end to end across the
ipv6 network. With out having an ipv4 address for everything that is ipv6?
If someone could reach out off list if there is a real solution to deploy
ipv6 as almost middleware.

Re: Serious Juniper Hardware EoL Announcements

[Brian]

>From Juniper...

"you are correct that there isn’t a native 10G SFP+ form factor offered
with the 304.



QSA adapters are qualified (say for example, Nvidia), and from there it can
support native 10G Bidi, WDM, etc. The economics per-port, obviously, get a
little expensive with this approach if a lot of native 10G is needed and
breakout isn’t an option.



Thanks!"



Oh and also I just got the call, Juniper is forcing a Price Hike in July.

On Tue, Jun 14, 2022 at 9:10 AM t...@pelican.org  wrote:

> > The MX204 is pure shocker! Unless the MX304 will come with a
> > license-based approach to run at MX204 pricing, that is Juniper shooting
> > themselves in the foot.
>
> Unless I'm missing a trick, the MX304 doesn't have an answer to installing
> DWDM, bidi, or other fancy optics in the SPF+ ports on the MX204.  QSFP+
> breakout to 4 x 10G is supported, but only 4 x vanilla 1310 optics - you'll
> need an external OEO solution if you want fancy 10G options.
>
> It otherwise seems a nice box on paper, although substantially more
> expensive than the MX204.
>
> Cheers,
> Tim.
>
>
>

Gmail admin

[Brian]

Is there a gmail admin that can contact me offlist?
Thanks much.

Re: Are any of you starting to get AI robocalls?

[Brian]

On Thu, 2018-04-05 at 07:55 -0700, Brian Kantor wrote:

> So the logical conclusion is that caller ID is useless as an
> anti-vspam measure and the situation is hopeless, so the only
> solution is to not personally answer the phone at all -- let voice
> mail take a message.

Pretty much. We've received calls here with the CID displaying as our
own info, and others coming up as a neighbor's number. Some even appear
as law enforcement when they're scammers looking for donations to
charities that don't exist. I suppose if you're going to commit one
crime, go for broke.

> This is what I have adopted on my personal landline.  With the
> ringers disconnected.  Although I get probably a half-dozen incoming
> calls a day, perhaps one a week will leave a message.  Most of those
> messages are recorded announcements that started playing even before
> the voicemail greeting finished.

I've been enjoying quiet on a VoIP line with asterisk. Those who I
know/expect/desire calls from I can route them directly to my extension,
those others get the IVR. It works parallel to IP routing. I can go a
few days without hearing my phone ring yet my logs are filled with
spammers/telemarketing calls. Robo-dialers have no clue which extension
a human may be at, and I've been doing this for over 15 years with great
success. With a digium wildcard, this can work for POTS lines as well.

Need a Level3 Contact

[Brian]

Hi,

I have a prefix that isn't being accepted by Level3. Can someone from
Level3 could contact. Off list is fine.

-brian

Re: IP KVM suggestions

[Brian]

> On 1/30/2012 11:05 AM, nanog-request  nanog.org wrote:
> > --
> >
> > Message: 8
> > Date: Mon, 30 Jan 2012 12:09:16 -0600
> > From: "Express Web Systems"  expresswebsystems.com>
> > To: "'NANOG'"  nanog.org>
> > Subject: RE: IP KVM suggestions
> > Message-ID: <033601ccdf7a$481d0f90$d8572eb0$@com>
> > Content-Type: text/plain;   charset="us-ascii"
> >
> >> > I have a need for a small, portable, web based IP kvm with decent
> >> > features that doesn't break the bank.  Preferably something that
> >> > supports ISO mounting from http or ftp and USB connectivity.  Would
> >> > also prefer something browser independent.  Small plugin like the
> >> > Raritan devices would be acceptable too. It will be used internally for
> >> > Remote access while building devices pre deployment to customers.  Any
> >> > suggestions?
> >> > 
> >> > Thanks!
> >> > 
> >> > Blake

Brian  live.com> writes:

Hi Blake,

Are you familiar with the PX device (http://minicom.com/kvm_px.htm)? We have it 
placed at several customer sites, and so far extremely reliable. It comes with 
VM included, but can with a special power cable also give you remote power 
control. I give it two thumbs up.

Cheers,
Brian

Re: Incorrect GeoIP filtering of 185.83.72.0/22

[Brian Ellwood]

Adam,

ip2location.com has that IP block listed as "(DCH) Data Center/Web 
Hosting/Transit” which we’ve seen cause issues for residential users in the 
past, most notably on Cogent IP space.

We worked with supp...@ip2location.com to have the address block re-analyzed 
and updated to "(ISP) Fixed Line ISP” which resolved many of the issues users 
had accessing various streaming CDN services.

HTH

> On Oct 30, 2020, at 08:27, Adam Pavlidis  wrote:
> 
> Hello,
> 
> We are reaching out to NANOG since the following issue is mostly observed in 
> US-based service providers.
> 
> We are advertising the prefix 185.83.72.0/22, that seems to be blocked by 
> various popular US-based services, thus our customers originating from this 
> prefix have trouble reaching such services. Indicatively:
> 
> Atlassian (AMAZON), Adobe (AKAMAI) .
> 
> To the best of our understanding, the blocking is enforced due to US / EU 
> sanctions against Iran. The prefix was purchased by us - Lamda Hellix SA ( 
> AS56910 based in GREECE, EUROPE ) - approximately 8 months ago.
> 
> We followed the necessary process as instructed by RIPE for changing the 
> ownership of the prefix.
> 
> Therefore, we kindly ask those of you that use/maintain/operate GeoIP 
> databases to update your records.
> 
> Most importantly, we would be grateful if you could share with us 
> (n...@lamdahellix.com) which Geo databases are mainly used in the US for this 
> purpose.
> 
> Kind regards,
> 
> Adam Pavlidis
> 

Re: nike.com->nike.com/ca

[Dantzig, Brian]

When you send a DNS query to 8.8.8.8 it goes to the “nearest” resolver. Not 
nearest in terms of location since 8.8.8.8 is an anycast address and exists in 
many locations. It’s the BGP path to 8.8.8.8 that determines nearest. Next, the 
resolver does it’s thing and sends a query to the akamai DNS. That DNS is 
probably also an anycast address so again, how close is it? Akamai then tries 
to geo locate you but they have the IP of Google, not you. You get an IP and 
connect to that. Everything up till now probably doesn’t matter as it’s 
probably not the DNS that is causing what you see. The IP is not Nike but 
rather an akamai proxy. When you connect to akamai proxy, the proxy can see 
your IP and may do the Geo location lookup and pass what it thinks as your 
location to the content server. When it gets to the content server, it may use 
that Geo information but possibly not. It’s likely it’s not the content server 
but a load balancer. In either case, they may ignore any Geo lookup done by 
akamai and try to locate the incoming IP. Well, that’s actually the address of 
the akamai proxy. Hopefully the developers thought of this and had akamai pass 
your IP in a header and geo locate on that. It’s probably the content server 
that is sending an HTTP redirect to get you to the “/ca” location on the site.

So there can be as many as 4 different times you are being geo-located. Which 
on actually matters is difficult to tell. Assuming Nike did a good job, it’s 
probably the Akamai proxy going the geo-locate and the code on the content 
server is consuming that and redirecting you to the location specific part of 
the site.


[Medline_Signiture2]<http://www.medline.com/?cmpid=eid:signature-logo-US-Sales>



Brian Dantzig
Senior Network Engineer
Information Services
Medline Industries, Inc.
www.medline.com<http://www.medline.com/?cmpid=eid:signature-link-US-Sales>


Office:  +1-847-837-2795
Mobile:+1-847-276-7169
bdant...@medline.com<mailto:bdant...@medline.com>





From: NANOG  on behalf of Mike 
Hammett 
Date: Thursday, January 7, 2021 at 7:40 AM
To: "Becki Kain (.)" 
Cc: "nanog@nanog.org" 
Subject: Re: nike.com->nike.com/ca

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.

Don't use other people's recursive DNS servers.


-
Mike Hammett
Intelligent Computing 
Solutions<https://urldefense.com/v3/__http:/www.ics-il.com/__;!!PoMpmxQzTok3!ux8PfKjcSqtK4NIlYhAFgw_77-3nVmlJpycBphh5cAH6N7iVD7qYTePDshTAj8XL$>
[http://www.ics-il.com/images/fbicon.png]<https://urldefense.com/v3/__https:/www.facebook.com/ICSIL__;!!PoMpmxQzTok3!ux8PfKjcSqtK4NIlYhAFgw_77-3nVmlJpycBphh5cAH6N7iVD7qYTePDsgWgvwtA$>[http://www.ics-il.com/images/googleicon.png]<https://urldefense.com/v3/__https:/plus.google.com/*IntelligentComputingSolutionsDeKalb__;Kw!!PoMpmxQzTok3!ux8PfKjcSqtK4NIlYhAFgw_77-3nVmlJpycBphh5cAH6N7iVD7qYTePDsmwqFBfz$>[http://www.ics-il.com/images/linkedinicon.png]<https://urldefense.com/v3/__https:/www.linkedin.com/company/intelligent-computing-solutions__;!!PoMpmxQzTok3!ux8PfKjcSqtK4NIlYhAFgw_77-3nVmlJpycBphh5cAH6N7iVD7qYTePDsoegf7B0$>[http://www.ics-il.com/images/twittericon.png]<https://urldefense.com/v3/__https:/twitter.com/ICSIL__;!!PoMpmxQzTok3!ux8PfKjcSqtK4NIlYhAFgw_77-3nVmlJpycBphh5cAH6N7iVD7qYTePDsu_J-rGV$>
Midwest Internet 
Exchange<https://urldefense.com/v3/__http:/www.midwest-ix.com/__;!!PoMpmxQzTok3!ux8PfKjcSqtK4NIlYhAFgw_77-3nVmlJpycBphh5cAH6N7iVD7qYTePDsoXLVPSN$>
[http://www.ics-il.com/images/fbicon.png]<https://urldefense.com/v3/__https:/www.facebook.com/mdwestix__;!!PoMpmxQzTok3!ux8PfKjcSqtK4NIlYhAFgw_77-3nVmlJpycBphh5cAH6N7iVD7qYTePDss384qEC$>[http://www.ics-il.com/images/linkedinicon.png]<https://urldefense.com/v3/__https:/www.linkedin.com/company/midwest-internet-exchange__;!!PoMpmxQzTok3!ux8PfKjcSqtK4NIlYhAFgw_77-3nVmlJpycBphh5cAH6N7iVD7qYTePDst95e4gD$>[http://www.ics-il.com/images/twittericon.png]<https://urldefense.com/v3/__https:/twitter.com/mdwestix__;!!PoMpmxQzTok3!ux8PfKjcSqtK4NIlYhAFgw_77-3nVmlJpycBphh5cAH6N7iVD7qYTePDsqpksjXq$>
The Brothers 
WISP<https://urldefense.com/v3/__http:/www.thebrotherswisp.com/__;!!PoMpmxQzTok3!ux8PfKjcSqtK4NIlYhAFgw_77-3nVmlJpycBphh5cAH6N7iVD7qYTePDsuZFFfvT$>
[http://www.ics-il.com/images/fbicon.png]<https://urldefense.com/v3/__https:/www.facebook.com/thebrotherswisp__;!!PoMpmxQzTok3!ux8PfKjcSqtK4NIlYhAFgw_77-3nVmlJpycBphh5cAH6N7iVD7qYTePDsljilqZu$>[http://www.ics-il.com/images/youtubeicon.png]<https://urldefense.com/v3/__https:/www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg__;!!PoMpmxQzTok3!ux8PfKjcSqtK4NIlYhAFgw_77-3nVmlJpycBphh5cAH6N7iVD7qYTePDslRB3F7I$>

From: "Becki Kain (.)" 
To: nanog@nanog.org
Sent: Wednesday, January 6, 2021 3:41:20 PM
Subject: 

Verizon FiOS/Google Peering Issues in Northeast?

[Brian Loveland]

Is this well known?  Getting lots of reports of 50% packet loss to anything
behind AS15169 from FiOS, including 8.8.8.8

Re: Verizon DC/NOVA Issues?

[Brian Henson]

I am here in NOVA (on FIOS) and it's working with higher packet loss than
normal.

On Tue, Jan 26, 2021 at 12:14 PM Robert Webb  wrote:

> Any hearing of Verizon internet issues affecting the DC, Northern
> Virginia, and surrounding areas?
>
> Just got a flood of complaints about work VPN connections keep dropping
> and all users appear to be using Verizon internet and other users on
> Comcast are not having issues.
>
> Started maybe around 11:30AM EST..
>
> Thanks..
>
> Robert Webb
>

Re: Texas ERCOT power shortages (again) April 13

[Brian Johnson]

Tom,

You do realize that ERCOT is a non-profit organization….

> On Apr 14, 2021, at 8:04 AM, Tom Beecher  wrote:
> 
> > Funny how this obsession with a green grid has made the grid
> > unreliable, resulting in sales of gas-burning generators and
> > perishable fuel.  Dare I say it's not been worth it?
> 
> Yes, desire for renewable power sources is totally the reason that power 
> generators neglect proper preventative maintenance and adoption of lessons 
> learned during past problem periods. It absolutely has nothing to do with 
> profit being the most important thing ever. Right? 
> 
> On Wed, Apr 14, 2021 at 8:48 AM Mark Tinka  wrote:
> 
> 
> On 4/14/21 13:35, Billy Croan wrote:
> 
> > Sounds like we all need to start keeping a few days reserve of energy 
> > on hand at home now because the utilities can't be trusted to keep 
> > their system online in 2021.
> 
> It just makes sense to plan along those lines, really. Despite popular 
> belief, power companies are preferring energy conservation from their 
> customers more than they do sales, because they just can't keep throwing 
> up new coal-fired or nuclear power stations a la the days of old (anyone 
> remember the 1973 and 1979 oil crises?)
> 
> Most people would assume that power companies want to sell more 
> electricity so they can make more money, but they dread the days when 
> the network is brought to its knees, even if the revenue will climb. So 
> between asking customers to save more on energy + being able to rely 
> less on fossil fuels for generation, one needs to consider their 
> personal energy security over the long term, fully or partially 
> independent of the traditional grid.
> 
> 
> > Funny how this obsession with a green grid has made the grid 
> > unreliable, resulting in sales of gas-burning generators and 
> > perishable fuel.  Dare I say it's not been worth it?
> 
> I wouldn't say that the obsession is without merit. It's just that 
> regular folk are only seeking the solution from one perspective - that 
> of the power generators. If folk (and that includes the gubbermints) met 
> the power companies half way, renewables would make a lot more sense, 
> more quickly. But as I said before, when we flick the switch, it must 
> turn on. End of. And then we revert to demanding power companies to 
> embrace the additional revenue, or fulfill their mandate to deliver a 
> basic, life-sustaining utility, no matter what.
> 
> Unfortunately, there really hasn't been sufficient education to regular 
> folk about what it takes to generate electricity reliably, no matter the 
> season. And yet, there is far more education out there about the 
> benefits of conserving it, and preserving the earth. So the view is not 
> balanced, and power companies as well as oil producers will knee-jerk to 
> either justify or distance themselves, rather than encourage a fair, 
> practical engagement. In the end, he that feels the most pressure, 
> caves... and this can go either way depending on which side of the 
> economic development curve you are sitting.
> 
> 
> >
> > Nuclear and hydro were the only reasonable obvious choices and 
> > ecological paralysis hamstrings those as well.
> 
> Ultimately, no target toward zero emissions is complete without some 
> kind of nuclear and/or hydro. Especially as a solution for peak demand, 
> (pumped) hydro will continue to be the most efficient option, if folk 
> are interested in keeping the lights on at 7:45PM on a wintery Tuesday 
> night.
> 
> 
> >
> > Now is the time to speak the message.  Write your elected 
> > representatives. Talk to your families and friends about energy.  
> > Change minds.
> 
> There is room for co-existence, I think. But the honest discussions need 
> to be had, and not the glossy wish list that should be fixed by someone 
> else, because we are just citizens minding our own business.
> 
> Mark.

Re: Texas ERCOT power shortages (again) April 13

[Brian Johnson]

There is no profit motive for a non-profit company. It’s completely relevant to 
your response.

For profit companies have similar issues with power generation and maintenance 
as the way power is generated requires maintenance. No power system is 
generating at 100% of capability at any single point. Your assumptions of 
neglect, poor maintenance and failing to learn are subterfuge. Traditional 
methods are more reliable (so far) than the newer “green” methods.

Just pointing out facts.

> On Apr 14, 2021, at 8:26 AM, Tom Beecher  wrote:
> 
> Brian-
> 
> I am aware. That's also not relevant at all to the point. 
> 
> On Wed, Apr 14, 2021 at 9:22 AM Brian Johnson  <mailto:brian.john...@netgeek.us>> wrote:
> Tom,
> 
> You do realize that ERCOT is a non-profit organization….
> 
>> On Apr 14, 2021, at 8:04 AM, Tom Beecher > <mailto:beec...@beecher.cc>> wrote:
>> 
>> > Funny how this obsession with a green grid has made the grid
>> > unreliable, resulting in sales of gas-burning generators and
>> > perishable fuel.  Dare I say it's not been worth it?
>> 
>> Yes, desire for renewable power sources is totally the reason that power 
>> generators neglect proper preventative maintenance and adoption of lessons 
>> learned during past problem periods. It absolutely has nothing to do with 
>> profit being the most important thing ever. Right? 
>> 
>> On Wed, Apr 14, 2021 at 8:48 AM Mark Tinka > <mailto:mark@tinka.africa>> wrote:
>> 
>> 
>> On 4/14/21 13:35, Billy Croan wrote:
>> 
>> > Sounds like we all need to start keeping a few days reserve of energy 
>> > on hand at home now because the utilities can't be trusted to keep 
>> > their system online in 2021.
>> 
>> It just makes sense to plan along those lines, really. Despite popular 
>> belief, power companies are preferring energy conservation from their 
>> customers more than they do sales, because they just can't keep throwing 
>> up new coal-fired or nuclear power stations a la the days of old (anyone 
>> remember the 1973 and 1979 oil crises?)
>> 
>> Most people would assume that power companies want to sell more 
>> electricity so they can make more money, but they dread the days when 
>> the network is brought to its knees, even if the revenue will climb. So 
>> between asking customers to save more on energy + being able to rely 
>> less on fossil fuels for generation, one needs to consider their 
>> personal energy security over the long term, fully or partially 
>> independent of the traditional grid.
>> 
>> 
>> > Funny how this obsession with a green grid has made the grid 
>> > unreliable, resulting in sales of gas-burning generators and 
>> > perishable fuel.  Dare I say it's not been worth it?
>> 
>> I wouldn't say that the obsession is without merit. It's just that 
>> regular folk are only seeking the solution from one perspective - that 
>> of the power generators. If folk (and that includes the gubbermints) met 
>> the power companies half way, renewables would make a lot more sense, 
>> more quickly. But as I said before, when we flick the switch, it must 
>> turn on. End of. And then we revert to demanding power companies to 
>> embrace the additional revenue, or fulfill their mandate to deliver a 
>> basic, life-sustaining utility, no matter what.
>> 
>> Unfortunately, there really hasn't been sufficient education to regular 
>> folk about what it takes to generate electricity reliably, no matter the 
>> season. And yet, there is far more education out there about the 
>> benefits of conserving it, and preserving the earth. So the view is not 
>> balanced, and power companies as well as oil producers will knee-jerk to 
>> either justify or distance themselves, rather than encourage a fair, 
>> practical engagement. In the end, he that feels the most pressure, 
>> caves... and this can go either way depending on which side of the 
>> economic development curve you are sitting.
>> 
>> 
>> >
>> > Nuclear and hydro were the only reasonable obvious choices and 
>> > ecological paralysis hamstrings those as well.
>> 
>> Ultimately, no target toward zero emissions is complete without some 
>> kind of nuclear and/or hydro. Especially as a solution for peak demand, 
>> (pumped) hydro will continue to be the most efficient option, if folk 
>> are interested in keeping the lights on at 7:45PM on a wintery Tuesday 
>> night.
>> 
>> 
>> >
>> > Now is the time to speak the message.  Write your elected 
>> > representatives. Talk to your families and friends about energy.  
>> > Change minds.
>> 
>> There is room for co-existence, I think. But the honest discussions need 
>> to be had, and not the glossy wish list that should be fixed by someone 
>> else, because we are just citizens minding our own business.
>> 
>> Mark.
> 

Re: Texas ERCOT power shortages (again) April 13

[Brian Johnson]

Not what I was saying. The demand for virtue-signaling green energy is not an 
effective strategy to actually having power available.

I appreciate the nuances, but the need to imply that a profit motive was the 
issue is not proven. This issue was NOT foreseeable except with the perfect 
reverse 20/20 vision. It’s like saying that I shouldn’t have built the house 
where the tornado hit.

> On Apr 14, 2021, at 10:12 AM, Patrick W. Gilmore  wrote:
> 
> Brian:
> 
> The idea that because ERCOT is a non-profit somehow means they would never do 
> anything to save money, or management is not granted bonuses or salary 
> increases based on savings, or have no financial incentive is ridiculous. 
> E.g. Salaries for the top ERCOT executives increased 50% from 2012 to 2019. 
> “Just pointing out facts.” 
> 
> Also, green vs. traditional has little to do with why ERCOT had problems. It 
> is undisputed that ERCOT failed in 2011, was handed a report by the feds 
> showing why they failed and how to fix it, yet ERCOT did not require 
> suppliers to enact those fixes. Those actions had a direct, operational 
> effect on the Internet. And as such, seem perfectly on-topic for NANOG.
> 
> Why that happened may still be on topic. For instance, you state correctly 
> that ERCOT is a non-profit (although you and I disagree on precisely how that 
> affects things). But the suppliers are not. Are we 100% certain the CEO’s 
> salary jumping far far far far far faster than inflation had nothing to do 
> with protecting the suppliers’ profits? I am not. However, that question is 
> only tenuously operational.
> 
> Bringing it back to the topic on hand: How do we keep the grid up? Or plan 
> for it not being up? Simply saying “green power is unreliable” is not an 
> answer when many RFPs at least ask what percentage of your power is green, or 
> flat out require at least some of your production be green. Making a blanket 
> statement that “XXX is a non-profit” does not absolve them from poor business 
> practices, which at least saves the non-profit money and frequently results 
> in profits outside that entity. Etc.
> 
> -- 
> TTFN,
> patrick
> 
> 
>> On Apr 14, 2021, at 10:00, Brian Johnson  wrote:
>> 
>> There is no profit motive for a non-profit company. It’s completely 
>> relevant to your response.
>> 
>> For profit companies have similar issues with power generation and 
>> maintenance as the way power is generated requires maintenance. No power 
>> system is generating at 100% of capability at any single point. Your 
>> assumptions of neglect, poor maintenance and failing to learn are 
>> subterfuge. Traditional methods are more reliable (so far) than the newer 
>> “green” methods.
>> 
>> Just pointing out facts.
>> 
>>> On Apr 14, 2021, at 8:26 AM, Tom Beecher >> <mailto:beec...@beecher.cc>> wrote:
>>> 
>>> Brian-
>>> 
>>> I am aware. That's also not relevant at all to the point. 
>>> 
>>> On Wed, Apr 14, 2021 at 9:22 AM Brian Johnson >> <mailto:brian.john...@netgeek.us>> wrote:
>>> Tom,
>>> 
>>> You do realize that ERCOT is a non-profit organization….
>>> 
>>>> On Apr 14, 2021, at 8:04 AM, Tom Beecher >>> <mailto:beec...@beecher.cc>> wrote:
>>>> 
>>>> > Funny how this obsession with a green grid has made the grid
>>>> > unreliable, resulting in sales of gas-burning generators and
>>>> > perishable fuel.  Dare I say it's not been worth it?
>>>> 
>>>> Yes, desire for renewable power sources is totally the reason that power 
>>>> generators neglect proper preventative maintenance and adoption of lessons 
>>>> learned during past problem periods. It absolutely has nothing to do with 
>>>> profit being the most important thing ever. Right? 
>>>> 
>>>> On Wed, Apr 14, 2021 at 8:48 AM Mark Tinka >>> <mailto:mark@tinka.africa>> wrote:
>>>> 
>>>> 
>>>> On 4/14/21 13:35, Billy Croan wrote:
>>>> 
>>>> > Sounds like we all need to start keeping a few days reserve of energy 
>>>> > on hand at home now because the utilities can't be trusted to keep 
>>>> > their system online in 2021.
>>>> 
>>>> It just makes sense to plan along those lines, really. Despite popular 
>>>> belief, power companies are preferring energy conservation from their 
>>>> customers more than they do sales, because they just can't keep throwing 
>>>> up new coal-fired or nuclear power s

Re: Texas ERCOT power shortages (again) April 13

[Brian Johnson]

Patrick - I hope that your determination of failure isn't dictated by the 
federal government telling you so. 😳

Again, green-energy solves none of these issues. In fact, it is likely less 
green, and more expensive than the traditional solutions.

Much resect for you and I really appreciate your views on these topics.

> On Apr 14, 2021, at 10:39 AM, Patrick W. Gilmore  wrote:
> 
> The issue was not only perfectly foreseeable, ERCOT has a ten year old 
> document explaining PRECISELY how to avoid such an occurrence happening.
> 
> Did you miss the second paragraph below?
> 
> -- 
> TTFN,
> patrick
> 
>> On Apr 14, 2021, at 11:35 AM, Brian Johnson > <mailto:brian.john...@netgeek.us>> wrote:
>> 
>> Not what I was saying. The demand for virtue-signaling green energy is not 
>> an effective strategy to actually having power available.
>> 
>> I appreciate the nuances, but the need to imply that a profit motive was the 
>> issue is not proven. This issue was NOT foreseeable except with the perfect 
>> reverse 20/20 vision. It’s like saying that I shouldn’t have built the house 
>> where the tornado hit.
>> 
>>> On Apr 14, 2021, at 10:12 AM, Patrick W. Gilmore >> <mailto:patr...@ianai.net>> wrote:
>>> 
>>> Brian:
>>> 
>>> The idea that because ERCOT is a non-profit somehow means they would never 
>>> do anything to save money, or management is not granted bonuses or salary 
>>> increases based on savings, or have no financial incentive is ridiculous. 
>>> E.g. Salaries for the top ERCOT executives increased 50% from 2012 to 2019. 
>>> “Just pointing out facts.” 
>>> 
>>> Also, green vs. traditional has little to do with why ERCOT had problems. 
>>> It is undisputed that ERCOT failed in 2011, was handed a report by the feds 
>>> showing why they failed and how to fix it, yet ERCOT did not require 
>>> suppliers to enact those fixes. Those actions had a direct, operational 
>>> effect on the Internet. And as such, seem perfectly on-topic for NANOG.
>>> 
>>> Why that happened may still be on topic. For instance, you state correctly 
>>> that ERCOT is a non-profit (although you and I disagree on precisely how 
>>> that affects things). But the suppliers are not. Are we 100% certain 
>>> the CEO’s salary jumping far far far far far faster than inflation had 
>>> nothing to do with protecting the suppliers’ profits? I am not. However, 
>>> that question is only tenuously operational.
>>> 
>>> Bringing it back to the topic on hand: How do we keep the grid up? Or plan 
>>> for it not being up? Simply saying “green power is unreliable” is not an 
>>> answer when many RFPs at least ask what percentage of your power is green, 
>>> or flat out require at least some of your production be green. Making a 
>>> blanket statement that “XXX is a non-profit” does not absolve them from 
>>> poor business practices, which at least saves the non-profit money and 
>>> frequently results in profits outside that entity. Etc.
>>> 
>>> -- 
>>> TTFN,
>>> patrick
>>> 
>>> 
>>>> On Apr 14, 2021, at 10:00, Brian Johnson >>> <mailto:brian.john...@netgeek.us>> wrote:
>>>> 
>>>> There is no profit motive for a non-profit company. It’s completely 
>>>> relevant to your response.
>>>> 
>>>> For profit companies have similar issues with power generation and 
>>>> maintenance as the way power is generated requires maintenance. No power 
>>>> system is generating at 100% of capability at any single point. Your 
>>>> assumptions of neglect, poor maintenance and failing to learn are 
>>>> subterfuge. Traditional methods are more reliable (so far) than the newer 
>>>> “green” methods.
>>>> 
>>>> Just pointing out facts.
>>>> 
>>>>> On Apr 14, 2021, at 8:26 AM, Tom Beecher >>>> <mailto:beec...@beecher.cc>> wrote:
>>>>> 
>>>>> Brian-
>>>>> 
>>>>> I am aware. That's also not relevant at all to the point. 
>>>>> 
>>>>> On Wed, Apr 14, 2021 at 9:22 AM Brian Johnson >>>> <mailto:brian.john...@netgeek.us>> wrote:
>>>>> Tom,
>>>>> 
>>>>> You do realize that ERCOT is a non-profit organization….
>>>>> 
>>>>>> On Apr 14, 2021, at 8:04 AM, Tom Beecher >>>>> <mailto:beec...@beecher.cc>&

Re: Texas ERCOT power shortages (again) April 13

[Brian Johnson]

> On Apr 14, 2021, at 11:07 AM, Niels Bakker  wrote:
> 
> * brian.john...@netgeek.us (Brian Johnson) [Wed 14 Apr 2021, 17:37 CEST]:
>> Not what I was saying. The demand for virtue-signaling green energy is not 
>> an effective strategy to actually having power available.
> 
> The relevant virtue that's signaled with green energy is that its MWh prices 
> are WAY lower than traditional fossil fuel-based generators.

Not going to get into this, but this is simply not true on multiple fronts.

> 
> 
>> I appreciate the nuances, but the need to imply that a profit motive was the 
>> issue is not proven. This issue was NOT foreseeable except with the perfect 
>> reverse 20/20 vision. It’s like saying that I shouldn’t have built the house 
>> where the tornado hit.
> 
> I've not done exhaustive research of the situation in Texas (although I am a 
> stakeholder, being a customer in several datacentres there) but I'd be 
> surprised if https://en.wikipedia.org/wiki/Regulatory_capture had nothing to 
> do with it.

So you want to do what about regulation. Deregulate so this can’t happen (HA), 
or regulate more so that this gets fixed (HA HA... and running away). 

If your point is that the ERCOT is acting in bad faith, I’d suggest you work 
with the Texas PUC to resolve that issue. Everything else is just politics.

RE: [EXTERNAL] Re: PeeringDB Hackathon - looking for feature requests

[Knopps, Brian]

I agree that this would be an interesting feature as it is something we 
commonly do over here using two or more queries. 

-B 

-Original Message-
From: NANOG  On Behalf Of 
Alarig Le Lay
Sent: Thursday, August 12, 2021 3:10 PM
To: nanog@nanog.org
Subject: [EXTERNAL] Re: PeeringDB Hackathon - looking for feature requests

CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.

On Thu 12 Aug 2021 15:27:48 GMT, Steve McManus wrote:
> PeeringDB is looking at participating at an upcoming NANOG Hackathon.
> One of the ideas for a theme is to improve the API. Specifically by 
> adding API calls for common use cases that people need to handle 
> outside of the API. Typically, by dumping the entire database to SQL 
> For example - given two IXes, which networks are present at both? We'd 
> like to make a list of such useful queries such that people don't have 
> to dump the database just to run them. A stretch goal would be to 
> expose into the website instead of requiring API calls.
> 
> This issue has some more detail, including a few existing ideas:
> https://github.com/peeringdb/peeringdb/issues/1020
> 
> Comments there or in email to me would be super helpful. As always, if 
> there are other feature requests for PeeringDB, feel free to create an 
> issue in github ( 
> https://github.com/peeringdb/peeringdb/issues/new/choose ) or in 
> email, even if they're not strictly Hackathon ideas. They are always 
> appreciated!
> 
> Thanks! 
> 
> -Steve
> PeeringDB Product Committee chair

A nice feature could be, while logged in, to highlight the IXPs shared with the 
ASN currently displayed.

--
Alarig
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Re: Backup over 4G/LTE

[Brian Knight]

In the past couple of years, we deployed CradlePoint IBR650's and
IBR600's (with and without wifi respectively).  It's a configurable
mini-router that can also accept wired access.  There is an on-board SIM
slot.  Downside is that the unit is a bit expensive as a CPE. 

Lately we have been deploying Proxicast PocketPort units.  These have an
RJ45 jack at one end, USB port on the other, with no built-in cell
antenna.  So you'll need a USB 4G/LTE dongle in addition.  Those
PocketPorts are a bit more limited in terms of config, but they work for
our use case and are less expensive overall than CradlePoint. 

If you want to stick with a router from big C, I've also worked with the
newer C-8PLTEEA which has an onboard SIM slot.  We tested them but
didn't put them in production due to cost. 

HTH! 

-Brian 

On 2020-01-28 17:30, K MEKKAOUI wrote:

> Dear NANOG Community, 
> 
> Can anyone help with any device information that provides redundancy for 
> business internet access? In other words when the internet provided through 
> the cable modem fails the 4G/LTE takes over automatically to provide internet 
> access to the client. 
> 
> Thank you 
> 
> KARIM M.

Re: Disney+ Geolocation issues

[Brian Ellwood]

John,

Give netad...@disneystreaming.com a shout.

> On Feb 6, 2020, at 10:29, John van Oppen  wrote:
> 
> Did you happen to have this contact?   I have a couple of CIDR blocks still 
> having this problem.
>  
> The blocks involved all seem right on the main geolocation blocks.
>  
> John
>  
> From: NANOG  On Behalf Of Cassidy B. Larson
> Sent: Tuesday, November 12, 2019 3:54 PM
> To: Michael Crapse 
> Cc: nanog@nanog.org
> Subject: Re: Disney+ Geolocation issues
>  
> We're seeing the same thing.  Actually we saw it during pre-signup.  Reached 
> out to Disney+ weeks ago as well, with no response.  Now it's launched, our 
> support lines are flooded with people unable to give Disney all their moneys. 
>We finally got through to Disney+ support after 2.5hrs on hold to supply 
> them the error code, IP address, and zip code.. we'll see if it's passed to 
> the right folks. 
>  
> On Tue, Nov 12, 2019 at 3:30 PM Michael Crapse  wrote:
> Myself and a few other ISPs are having our eyeballs complain about disney+ 
> saying that they're on a VPN. Does anyone have any idea, or who to contact 
> regarding this issue?
> This is most likely improper geolocation databases. Anyone have an idea who 
> they use?
>  
> Mike

Re: IPv6 for Verizon FIOS

[Brian Ellwood]

https://www.dslreports.com/forum/r32136440-Networking-IPv6-working

Enjoy the read

TLDR they are doing some test deployments in:

- Ashburn, VA
- Richmond/Midlothian, VA
- Spotsylvania, VA
- Waltham, MA

“It’s Coming (TM)"

—
Brian Ellwood
Senior Systems Engineer
INOC Data Centers
O: 518-689-4350

> On Feb 26, 2020, at 12:05, j k  wrote:
> 
> Does anyone have a contact at Verizon FIOS?  
> 
> Please respond off list.
> 
> V/R,
> 
> Joe Klein 
> "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
> "I never lose. I either win or learn" - Nelson Mandela
> 

Re: IPv6 for Verizon FIOS

[Brian Ellwood]

> this is from 2yrs ago. there's no evidence this is either progressing or 
> actually working for anything but some test sets.

Correct, hence, “It’s coming (TM)”

However, if you read the thread or even jumped to the end there was a post 
Yesterday 12:48 pm where a residential user in that test footprint confirmed 
IPv6 connectivity on a Ubiquiti edge device.

There are Verizon employees in that 30 page thread discussing it - there’s is 
no official statement or word from Verizon on availability, capability, 
deadline and so forth.

—
Brian Ellwood
Senior Systems Engineer
INOC Data Centers
O: 518-689-4350

> On Feb 26, 2020, at 13:07, Christopher Morrow  wrote:
> 
> On Wed, Feb 26, 2020 at 12:42 PM Brian Ellwood  wrote:
>> 
>> https://www.dslreports.com/forum/r32136440-Networking-IPv6-working
> 
> this is from 2yrs ago.
> there's no evidence this is either progressing or actually working for
> anything but some test sets.
> 
> 
> 
>> Enjoy the read
>> 
>> TLDR they are doing some test deployments in:
>> 
>> - Ashburn, VA
>> - Richmond/Midlothian, VA
>> - Spotsylvania, VA
>> - Waltham, MA
>> 
>> “It’s Coming (TM)"
>> 
>> —
>> Brian Ellwood
>> Senior Systems Engineer
>> INOC Data Centers
>> O: 518-689-4350
>> 
>>> On Feb 26, 2020, at 12:05, j k  wrote:
>>> 
>>> Does anyone have a contact at Verizon FIOS?
>>> 
>>> Please respond off list.
>>> 
>>> V/R,
>>> 
>>> Joe Klein
>>> "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
>>> "I never lose. I either win or learn" - Nelson Mandela
>>> 
>> 

Re: ACX5448

[Brian Johnson]

I’ve seen horror stories for almost every platform from every vendor over my 
time. It usually is caused from using the wrong device for the wrong purpose.

If you know its limitations, and use it with in the bounds of its capabilities, 
you will have very few issues with the ACX5448.

- Brian

> On Jun 5, 2020, at 8:21 AM, JASON BOTHE via NANOG  wrote:
> 
> Hi all
> 
> Just curious if anyone on is using the ACX5448 and what their thoughts are on 
> it. 
> 
> Thanks
> 
> J~
> 

Re: Partial vs Full tables

[Brian Johnson]

Disagree with Bill here. It will depend on the complexity of the network as to 
use of uRPF in any mode (loose or strict). In general, I never use uRPF on 
transit links and use pure filters to ensure accurate filters are in place. 
uRPF may be used internally in either mode to great advantage and I’ve done it 
both ways.

If you are looking for corner cases, avoid networking. I do not know of a 
protocol or a technique that I cannot find a corner case for.

- Brian

> On Jun 10, 2020, at 12:31 PM, William Herrin  wrote:
> 
> On Wed, Jun 10, 2020 at 9:43 AM William Herrin  wrote:
>> The answer is "no," you're not running reverse-path filtering on a BGP
>> speaker, not even in loose mode, because that's STUPID.
> 
> Sorry, it'd be pre-coffee if I drank coffee and I was overly harsh
> here. Let me back up:
> 
> The most basic spoofing protection is: don't accept remote packets
> pretending to be from my IP address.
> 
> Strict mode URPF extends this to networks: don't accept packets on
> interfaces where I know for sure the source host isn't in that
> direction. It works fine in network segments whose structure requires
> routes to be perfectly symmetrical: on every interface, the packet for
> every source can only have been from one particular next hop, the same
> one that advertises acceptance of packets with that destination. The
> use of BGP breaks the symmetry requirement so close to always that you
> may as well think of it as always. Even with a single transit or a
> partial table. Don't use strict mode URPF on BGP speakers.
> 
> Loose mode URPF is... broken. It was a valiant attempt to extend
> reverse path filtering into networks with asymmetry but I've yet to
> discover a use where there wasn't some faulty corner case. If you
> think you want to use loose mode RPF, trust me: you've already passed
> the point where any RPF was going to be helpful to you. Time to set it
> aside and solve the problem a different way.
> 
> Regards,
> Bill Herrin
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: Partial vs Full tables

[Brian Johnson]

> On Jun 10, 2020, at 3:05 PM, William Herrin  wrote:
> 
> On Wed, Jun 10, 2020 at 11:20 AM Brian Johnson  
> wrote:
>> Disagree with Bill here. It will depend on the complexity of the network as 
>> to use of uRPF in any mode (loose or strict). In general, I never use uRPF 
>> on transit links and use pure filters to ensure accurate filters are in 
>> place. uRPF may be used internally in either mode to great advantage and 
>> I’ve done it both ways.
> 
> 
> Hi Brian,
> 
> Do you know and understand what you broke? It's one thing to make a
> judgement call. Quite another to wave your hands and say, "Oh well,
> nobody complained so it must be OK."
> 

Hi Bill,

I fully understand that I have not “broken” anything. If I run uRPF in loose 
mode on my internal links, I will not forward packets from a source that 
doesn’t exist in my routing tables to the rest of the internet. Just say thank 
you and we can stop this silliness.

> 
>> If you are looking for corner cases, avoid networking. I do not know of a 
>> protocol or a technique that I cannot find a corner case for.
> 
> Not sure what you're saying here. Corner cases aren't a bad thing.
> They're just the point where a technology or technique is most likely
> to break. If you want reliability, you're supposed to identify the
> corner cases and then you're supposed to game out what happens in
> those corner cases. A result will be acceptable or unacceptable and if
> it's unacceptable you don't do that. If you haven't identified and
> gamed the corner cases then (A) you can't prove your stuff is reliable
> and (B) it probably isn't.

Actually corner cases are the exception to any rule. You will never solve for 
all of the corner cases unless you have dictatorial control of the entire 
system. I can only control what I send. I can say that sending packets from 
unknown sources from a network I do control is a no-no, ICMP response or not.

> With RPF, the corner cases you're looking for are: what situations
> would cause a packet to come from the wrong interface? For example, if
> you had some sort of routing loop where router A thought it could get
> to a destination via router B but router B thinks that destination
> unreachable so it returns the packet to its default route at router A.
> RPF then drops the packet because router B isn't an acceptable source.
> That's a corner case for RPF but it's an acceptable case because the
> packet would be dropped regardless.

So a non-problem corner-case. Interesting... I never thought of a non-problem 
as a problem.

> Another corner case with strict RPF is that your best route to a
> destination is transit C but a packet with that source arrives from
> transit D. That's broken, it causes significant problems for the
> network and as a result it constrains you to not use strict RPF in
> network scenarios where that's possible.

See my original response where I say not to use it in that scenario.

> Loose mode RPF tries to overcome the limitation by saying: as long as
> there's a route announced from D we'll accept packets from D even if C
> is the best route.

Saying that a route to the source has to be in the routing table on an internal 
network, something I can control, is a valid way to stop spoofing. uRPF cannot, 
and should never be used to, make routing decisions and does not do that anyway.

The rest of your comments are not reasonable since I already said to not use 
uRPF on TRANSIT LINKS. Happy to expand that to PEERING LINKS. For internal 
networking, you CAN use uRPF to great effect, corner case arguments 
notwithstanding.

Not everyone runs a large multi-national tier-1/2 network. Some of us run the 
thousands of eye-ball networks and just say thank you when we don’t allow 
spoofing.

BTW... RPF and uRPF are significantly different things. :)



> 
> Regards,
> Bill Herrin
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: Partial vs Full tables

[Brian Johnson]

You are a dismissive little twit aren’t you. :/

> On Jun 11, 2020, at 9:56 AM, William Herrin  wrote:
> 
> On Thu, Jun 11, 2020 at 6:25 AM Brian Johnson  
> wrote:
>> I fully understand that I have not “broken” anything.
> 
> Handwaving, la la la, only sunshine in the sky. Got it.
> 
> -Bill
> 
> 
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: Partial vs Full tables

[Brian Johnson]

> On Jun 10, 2020, at 6:40 PM, brad dreisbach  wrote:
> 
> On Thu, Jun 11, 2020 at 12:01:38AM +0200, Baldur Norddahl wrote:
>> Am I correct in assuming loose mode RPF only drops packets from unannounced
>> address space in the global routing table? And the downside of doing so is
>> that sometimes we do receive packets from that address space, usually back
>> scatter from traceroute or other ICMP messages.
> 
> uRPF absolutely kills the pps performance or your hardware due to the packet
> having to be recirculated to do the check(at least this is the case on every
> platform that ive ever tested it on). use acl's to protect your edge.
> 
> -b


Completely agree for edge scenario 100%.

And now for Bill to talk down to me…. :/

Re: Partial vs Full tables

[Brian Johnson]

Wow. Full distorted vision of reality mode here…

uRPF doesn’t “break” anything. I stand by that. It’s not a religious position. 
It’s an operational experience. One that I have multitudes of real world 
examples of it working to SOLVE issues.

You seem to be willfully ignorant about how real networks use tools that you 
dislike to solve problems. This is way more of a problem with you disliking 
uRPF than me telling you that I like it for some applications.

Now I remember why I usually never post on this list now. I will just dismiss 
your opinions going forward instead of trying to point out that you aren’t the 
only measure of a network.

Thanks Bill.


> On Jun 11, 2020, at 1:11 PM, William Herrin  wrote:
> 
> On Thu, Jun 11, 2020 at 9:35 AM Brian Johnson  
> wrote:
>> You are a dismissive little twit aren’t you. :/
> 
> Someone stood up and said, "Nope, nothing I did could possibly have
> broken anything." I'm pretty sure that someone was you but feel free
> to call me on it if I'm mistaken.
> 
> Look, at the risk of doing further offense, it's like I said: it's one
> thing to educate yourself about a topic and then make a judgement call
> about what's acceptable. It's quite another to remain willfully
> ignorant in service of your preferred view. I just got through
> describing specific scenarios where loose urpf fails when you
> responded that no, it doesn't break anything. If you'd said, "no, that
> breakage is a small price worth paying," I'd have debated the merits
> with you or simply let it stand as a contrary opinion. Refusing to
> acknowledge the breakage is worth only dismissal.
> 
> Regards,
> Bill
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

MAP-T in production

[Brian Johnson]

Has anyone implemented a MAP-T solution in production? I am looking for 
feedback on this as a deployment strategy for an IPv6 only core design. My 
concern is MAP-T CE stability and overhead on the network. The BR will have to 
do overloaded NAT anyway to access IPv4 only resources. The idea being that 
when IPv4 is no longer needed, this will be a quicker “clean-up” project than a 
dual-stack solution.

I have reviewed Jordan Gotlieb’s presentation from Charter and would love to 
hear if this is still in use at Charter or if was ever fully implemented and 
the experiences)

I’d love any real life examples and success/failure stories.

Thanks.

- Brian

Re: MAP-T in production

[Brian Johnson]

I’ve gotten a lot of great feedback and want to restate some of my thoughts for 
further discussion:

1. It seems like the MAP-T is still in an initial phase of 
development/production. I’ve seen a few other people mentioning it, but it is 
early in deployment today.

2. When working with smaller and regional eye-ball networks throughout the US 
you need to be aware of a couple things. Think no engineering team, just an 
implementation crew and local support people (Small telco mentality). They need 
commercially available and widely supported solutions.

Based on the feedback I’ve seen so far, I would think that positioning a MAP-T 
solution in these scenarios might be more of a hassle and turn into a support 
nightmare. I’m leaning toward DS-lite and NAT444 right now as these are more 
proven and have greater deployed bases.

Thoughts…

- Brian

> On Jul 22, 2020, at 4:15 PM, Brian Johnson  wrote:
> 
> Has anyone implemented a MAP-T solution in production? I am looking for 
> feedback on this as a deployment strategy for an IPv6 only core design. My 
> concern is MAP-T CE stability and overhead on the network. The BR will have 
> to do overloaded NAT anyway to access IPv4 only resources. The idea being 
> that when IPv4 is no longer needed, this will be a quicker “clean-up” project 
> than a dual-stack solution.
> 
> I have reviewed Jordan Gotlieb’s presentation from Charter and would love to 
> hear if this is still in use at Charter or if was ever fully implemented and 
> the experiences)
> 
> I’d love any real life examples and success/failure stories.
> 
> Thanks.
> 
> - Brian

Re: MAP-T in production

[Brian Johnson]

OK Randy. How about a suggestion that is useful.

- Brian

> On Jul 24, 2020, at 8:24 PM, Randy Bush  wrote:
> 
>> I’m leaning toward DS-lite and NAT444
> 
> a great path.  fork lift all cpe and cgn in the core.  the vendors'
> dream
> 
> randy

Re: MAP-T in production

[Brian Johnson]

NAT444 CGN does NOT solve an IPv6 problem at all. It solves an IPv4 shortage 
problem at best and is not designed as a long-term solution. I cannot force 
customers to buy new equipment to make them IPv6 compliant. The best option is 
to support, fully and unabashedly, IPv6 and help with the transition from IPv4 
using techniques to solve for the problems/corner-cases.

All transition technologies are band-aids. We are talking about ways to bridge 
a gap. Anyone looking at any of these techniques as an end design goal has 
missed the IPv6 point all together and is not serving their users/customers 
well. In the end, we will have everyone on IPv6 and this entire conversation is 
mute.


BTW… name a transition technology that is supported by all legacy equipment…. 
I’ll enjoy the silence. ;)

> On Jul 26, 2020, at 7:23 AM, Mark Tinka  wrote:
> 
> 
> 
> On 25/Jul/20 03:24, Randy Bush wrote:
> 
>> a great path.  fork lift all cpe and cgn in the core.  the vendors'
>> dream
> 
> All major vendors are shipping IPv6. Some even 464XLAT. And yet they
> will not put those forward as long term solutions.
> 
> As Randy points out, CG-NAT sells plenty in license fees. And you need
> more and more, every year. Not less.
> 
> So, go ahead and enrich the vendors, at the expense of your business.
> And we shall all wonder why they keep saying "But no one is asking for
> IPv6".
> 
> Mark.
> 

AT&T NOC Contact Info

[Brian Pierce]

Hello Everyone,

Does anyone have any contact info for AT&T's NOC? We've encountered what we 
believe to be a geolocation issue relating to one of our blocks. Any 
information would be greatly appreciated.

Thanks,

Brian Pierce
Network Technician
bpie...@consolidated.coop<mailto:bpie...@consolidated.coop>

Hotstar Geoip Issues / Contact

[Brian Loveland]

Anyone have a contact for fixing Hotstar US geoip issues? We have a newer
block that they seem to be filtering, other blocks are fine. No luck
through their support and they seem to be 100% Akamai so no peeringdb/etc
entries.

Thanks,
Brian Loveland
Starry AS27611 & AS395354

AT&T NOC Contact Info

[Brian Pierce]

Hello Everyone,

Does anyone have reliable contact info for AT&T DirecTV NOC Support? Everything 
I'm finding appears to be out of date.

Thanks,

Brian Pierce
Network Technician
bpie...@consolidated.coop<mailto:bpie...@consolidated.coop>

Consolidated Cooperative
consolidated.coop<http://consolidated.coop/>

Re: Ipv6 help

[Brian Johnson]

I usually solve this problem by designing for NAT444 and dual-stack. This 
solves both problems and allows for users to migrate as they are able/need to. 
If you try and force the change, you will loose users.


> On Aug 25, 2020, at 3:15 PM, Brandon Martin  wrote:
> 
> On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote:
>> This is very common in many countries and not related to IPv6, but because 
>> many operators have special configs or features in the CPEs they provide.
> 
> I really, really hate to force users to use my network edge router (I provide 
> the ONT, though, and I provide an edge router that works and most users do 
> take it), but it can be tough to ensure users have something that supports 
> all the right modern features and can be configured via standard means.
> 
> It would be nice if the consumer router industry could get its collective act 
> together and at least come up with some easy-ish to understand feature 
> support table that customers can match up with their service provider's list 
> of needs.  The status quo of a list of devices that work right (which is of 
> course often staggeringly short if you're doing any of these modern 
> transition mechanisms) that needs constant updating and may not be easily 
> available is not ideal.
> 
> Heck just having a real, complete list of supported features on the model 
> support page on their website would be an improvement...
> -- 
> Brandon Martin

Re: Ipv6 help

[Brian Johnson]

Over sub at around 20-40 to 1 is very easy now. With PBA, DET-NAT and other 
tools, the average customer largely doesn’t know it is happening and it solves 
for many provider side issues as well (logging being the biggest). For those 
customers who have issues, the over-sub ratios leave IPv4 space for those 
corner cases and/or native IPv6 should be made available.

And before anyone yells that this "breaks something,” It was already broken.

> On Aug 25, 2020, at 11:46 PM, Mark Tinka  wrote:
> 
> 
> 
> On 25/Aug/20 22:40, Brian Johnson wrote:
> 
>> I usually solve this problem by designing for NAT444 and dual-stack. This 
>> solves both problems and allows for users to migrate as they are able/need 
>> to. If you try and force the change, you will loose users.
> 
> At some point, you run out of IPv4.
> 
> You could cascade to a high degree of NAT444, but then it gets hairy,
> and costly, at some point.
> 
> Mark.

Re: Ipv6 help

[Brian Johnson]

I’ve not experienced this with PSN and NAT444. I have a LOT of customers doing 
it without issue. Maybee it’s that the customer has native IPv6 and solves for 
the problem that way, but then this just becomes make sure IPv6 is provided and 
it solves for the corner case.

> On Aug 26, 2020, at 2:13 AM, JORDI PALET MARTINEZ via NANOG  
> wrote:
> 
> It was a way to say.
> 
> Because you use IPv4 pools in the CGN. Then when detected by some services 
> such as PSN, they are black-listed. You use other pools, they become black 
> listed again, and so on.
> 
> This is not the case with NAT64/464XLAT.
> 
> So yeah, it works but the cost of purchasing CGN is actually becoming higher 
> and you will need sooner or later, to buy more IPv4 addresses once all them 
> are black-listed.
> 
> I've not heard about anyone that has been able to convince Sony to clean 
> their addresses from the PSN CGN black-list.
> 
> 
> 
> El 26/8/20 9:07, "Mark Andrews"  escribió:
> 
>How doesn’t it work?  As long as IPv6 is *on* NAT444 + dual stack has the 
> same properties (or better, less PMTUD issues) as turning on 464XLAT in the 
> CPE.  Traffic shifts to IPv6 due to hosts preferring IPv6.   You can still 
> disable sending RA’s in either scenario.
> 
>Mark
> 
>> On 26 Aug 2020, at 16:51, JORDI PALET MARTINEZ via NANOG  
>> wrote:
>> 
>> No, this doesn't work
>> 
>> The point your're missing (when I talked before about putting all the costs 
>> to make a good calculation of each case and then replacing CPEs become 
>> actually cheaper) is that you need more IPv4 addresses in CGN than in NAT64 
>> and further to that, in CGN, your IPv4 pools sooner or later become blocked 
>> by PSN (unless you don't have gammers among your customers).
>> 
>> El 25/8/20 22:42, "NANOG en nombre de Brian Johnson" 
>> > brian.john...@netgeek.us> escribió:
>> 
>>   I usually solve this problem by designing for NAT444 and dual-stack. This 
>> solves both problems and allows for users to migrate as they are able/need 
>> to. If you try and force the change, you will loose users.
>> 
>> 
>>> On Aug 25, 2020, at 3:15 PM, Brandon Martin  
>>> wrote:
>>> 
>>> On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote:
>>>> This is very common in many countries and not related to IPv6, but because 
>>>> many operators have special configs or features in the CPEs they provide.
>>> 
>>> I really, really hate to force users to use my network edge router (I 
>>> provide the ONT, though, and I provide an edge router that works and most 
>>> users do take it), but it can be tough to ensure users have something that 
>>> supports all the right modern features and can be configured via standard 
>>> means.
>>> 
>>> It would be nice if the consumer router industry could get its collective 
>>> act together and at least come up with some easy-ish to understand feature 
>>> support table that customers can match up with their service provider's 
>>> list of needs.  The status quo of a list of devices that work right (which 
>>> is of course often staggeringly short if you're doing any of these modern 
>>> transition mechanisms) that needs constant updating and may not be easily 
>>> available is not ideal.
>>> 
>>> Heck just having a real, complete list of supported features on the model 
>>> support page on their website would be an improvement...
>>> -- 
>>> Brandon Martin
>> 
>> 
>> 
>> 
>> **
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>> 
>> This electronic message contains information which may be privileged or 
>> confidential. The information is intended to be for the exclusive use of the 
>> individual(s) named above and further non-explicilty authorized disclosure, 
>> copying, distribution or use of the contents of this information, even if 
>> partially, including attached files, is strictly prohibited and will be 
>> considered a criminal offense. If you are not the intended recipient be 
>> aware that any disclosure, copying, distribution or use of the contents of 
>> this information, even if partially, including attached files, is strictly 
>> prohibited, will be considered a criminal offense, so you must reply to the 
>> original sender to inform about this communication and delete it.
>> 
>> 
>> 
> 
>-- 
&g

Re: Ipv6 help

[Brian Johnson]

This sounds like a Sony problem more than a network problem. They need to get 
on the IPv6 train and play nice with the Internet. X-BOX has had IPv6 support 
since X-BOX One.

> On Aug 26, 2020, at 1:09 PM, Mark Tinka  wrote:
> 
> 
> 
> On 26/Aug/20 18:42, JORDI PALET MARTINEZ via NANOG wrote:
> 
>> The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 
>> ...
> 
> To this day, my PS4, running Sony's latest code, does not support IPv6.
> 
> That might be a good place to start, for them.
> 
> At the rate they are doing, the PS5 might ship with RIPv2.
> 
> Mark.

Re: Ipv6 help

[Brian Johnson]

Either way. Nothing you can do in the network will help Sony enable IPv6 
capability, Or to serve their users even if using a technology that they do not 
like.


> On Aug 26, 2020, at 1:17 PM, Mark Tinka  wrote:
> 
> 
> 
> On 26/Aug/20 20:14, Brian Johnson wrote:
> 
>> This sounds like a Sony problem more than a network problem. They need to 
>> get on the IPv6 train and play nice with the Internet. X-BOX has had IPv6 
>> support since X-BOX One.
> 
> IIRC, someone here said the issue wasn't so much PS4 (which runs
> FreeBSD-9.0), but the PSN back-end.
> 
> I can believe this, as  Sony TV I bought back in 2015 had IPv6 support,
> on their own embedded OS.
> 
> Mark.

Re: Ipv6 help

[Brian Johnson]

I‘m going further... They shouldn’t have to care. Sony should understand what 
they are delivering and the circumstance of that. That they refuse to serve 
some customers due to the technology they use is either a business decision or 
a faulty design. The end-customer (gamer) doesn’t care. They just want to play.


> On Aug 26, 2020, at 1:31 PM, Mark Tinka  wrote:
> 
> 
> 
> On 26/Aug/20 20:20, Brian Johnson wrote:
> 
>> Either way. Nothing you can do in the network will help Sony enable IPv6 
>> capability, Or to serve their users even if using a technology that they do 
>> not like.
> 
> Agreed.
> 
> The problem is gaming customers that neither care for nor know about how
> NAT444 and/or IPv6 play (no pun intended) here.
> 
> Mark.

Re: Ipv6 help

[Brian Johnson]

I can prove, as an ISP, that I am delivering the packets. Many providers will 
have to do this until the content moves to IPv6, so what will their excuse be? 
The provider has no choice when they have more customers than IPv4 address 
space. They will have to do something to provide access to the IPv4 Internet 
for these customers. If the ISP created a service that wasn’t NAT444 for gamers 
and charged accordingly, they would probably get drawn and quartered.

It’s a no win situation and it really is Sony that is causing this issue. PR 
campaigns and educating customers is probably the only way they can win this 
argument, when they already have the technical battle won.

Just checked with 2 of my customers who do NAT444 and no issues with PSN… YMMV.

> On Aug 26, 2020, at 2:00 PM, Mark Tinka  wrote:
> 
> 
> 
> On 26/Aug/20 20:38, Brian Johnson wrote:
> 
>> I‘m going further... They shouldn’t have to care. Sony should understand 
>> what they are delivering and the circumstance of that. That they refuse to 
>> serve some customers due to the technology they use is either a business 
>> decision or a faulty design. The end-customer (gamer) doesn’t care. They 
>> just want to play.
> 
> Sony know that when connectivity breaks because they marked a NAT444'ed
> IP address as a DDoS source, the end-user won't complain to Sony (that's
> a customer service blackhole). The end-user will complain to the ISP.
> 
> Chain of responsibility is in the ISP's disfavour. Sony don't have to do
> anything. It's like sending an e-mail to an abuse@ mail box. You sort of
> know it won't get answered, and are powerless if it isn't answered.
> 
> Mark.

Re: Ipv6 help

[Brian Johnson]

Mark: We are completely in agreement. Great dialog here.

> On Aug 26, 2020, at 2:30 PM, Mark Tinka  wrote:
> 
> 
> 
> On 26/Aug/20 21:14, Brian Johnson wrote:
> 
>> I can prove, as an ISP, that I am delivering the packets. Many providers 
>> will have to do this until the content moves to IPv6, so what will their 
>> excuse be? The provider has no choice when they have more customers than 
>> IPv4 address space. They will have to do something to provide access to the 
>> IPv4 Internet for these customers. If the ISP created a service that wasn’t 
>> NAT444 for gamers and charged accordingly, they would probably get drawn and 
>> quartered.
>> 
>> It’s a no win situation and it really is Sony that is causing this issue. PR 
>> campaigns and educating customers is probably the only way they can win this 
>> argument, when they already have the technical battle won.
> 
> In essence, yes.
> 
> But most gaming customers don't have the time to decipher .pcap files
> proving that you delivered the traffic to Sony.
> 
> And Sony are counting on this.
> 
> We'll have to be creative with how we pressure them into getting serious
> about IPv6.
> 
> Mark.

Re: Ipv6 help

[Brian Johnson]

I have/do. Do you have a point?

> On Aug 26, 2020, at 3:06 PM, surfer  wrote:
> 
> 
> 
> On 8/26/20 9:28 AM, Tony Wicks wrote:
>> They're the worst service company I have ever had the displeasure of dealing 
>> with, the arrogance and attitude of we are big, you are small we don't care 
>> about your customers was infuriating. Never have I seen a single call 
>> related to their opposition where as PSN accounted for about 10-20% of 
>> helpdesk calls. I don't understand why its seemingly impossible for them to 
>> implement ipv6 as almost everything I have deployed with CGN is dual stack 
>> V6.
> 
> On 8/26/20 9:30 AM, Mark Tinka wrote:
>> We'll have to be creative with how we pressure them into getting serious
>> about IPv6.
> 
> 
> Do those guys attend NANOG meetings?   >;-)   (evil smile)
> 
> scott

Re: Ipv6 help

[Brian Johnson]

How does 464XLAT solve the problem if you are out of IPv4 space?

> On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG  
> wrote:
> 
> They know we are there ... so they don't come!
> 
> By the way I missed this in the previous email: I heard (not sure how much 
> true on that) that they are "forced" to avoid CGN because the way games are 
> often programmed in PSP break them. So maybe will not be enough to sort out 
> the problem with an OS and/or PSN change, all the affected games, will need 
> to be adjusted.
> 
> Maybe the only way to force this is to tell our customers (many ISPs in every 
> country) "don't buy Sony PS, they are unable to support new technologies, so 
> you games will be blocked by Sony". Of course, unless we all decide to use 
> 464XLAT instead of CGN ... which resolves the problem.
> 
> A massive campaing could work ...
> 
> 
> El 26/8/20 22:08, "NANOG en nombre de surfer" 
>  sur...@mauigateway.com> escribió:
> 
> 
> 
>On 8/26/20 9:28 AM, Tony Wicks wrote:
>> They're the worst service company I have ever had the displeasure of dealing 
>> with, the arrogance and attitude of we are big, you are small we don't care 
>> about your customers was infuriating. Never have I seen a single call 
>> related to their opposition where as PSN accounted for about 10-20% of 
>> helpdesk calls. I don't understand why its seemingly impossible for them to 
>> implement ipv6 as almost everything I have deployed with CGN is dual stack 
>> V6.
> 
>On 8/26/20 9:30 AM, Mark Tinka wrote:
>> We'll have to be creative with how we pressure them into getting serious
>> about IPv6.
> 
> 
>Do those guys attend NANOG meetings?   >;-)   (evil smile)
> 
>scott
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of the 
> individual(s) named above and further non-explicilty authorized disclosure, 
> copying, distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited and will be 
> considered a criminal offense. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited, will be considered a criminal offense, so you must reply to the 
> original sender to inform about this communication and delete it.
> 
> 
> 

Re: Ipv6 help

[Brian Johnson]

Responses in-line

> On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG  
> wrote:
> 
> Because:
> 
> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of 
> customers.

I cannot see how this is even possible. If I use private space internally to 
the CGN, then the available external space is the same and the internal 
customers are the same and I can do the same over sub ratio under both 
circumstance. Tell me how the math is different.

> 2) It provides the customers as many ports they need (no a limited number of 
> ports per customer).

See response to answer 1

> 3) It is not blocked by PSN (don't know why because don't know how the games 
> have problems with CGN).

Interesting, but I’m not sure how any over-loaded NAT translation would look 
different from the external system. Since you cannot explain it, it’s hard to 
discuss it.

> 
> You could share among an *almost unlimited* number of subscribers an small 
> IPv4 block (even just a /22).

The math would be the same as a CGN, so I do not see how this is any less or 
more useful. It does, however, require CPE capability that appears lacking and 
NAT444 does not. 

> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 26/8/20 22:31, "Brian Johnson"  escribió:
> 
>How does 464XLAT solve the problem if you are out of IPv4 space?
> 
>> On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG 
>>  wrote:
>> 
>> They know we are there ... so they don't come!
>> 
>> By the way I missed this in the previous email: I heard (not sure how much 
>> true on that) that they are "forced" to avoid CGN because the way games are 
>> often programmed in PSP break them. So maybe will not be enough to sort out 
>> the problem with an OS and/or PSN change, all the affected games, will need 
>> to be adjusted.
>> 
>> Maybe the only way to force this is to tell our customers (many ISPs in 
>> every country) "don't buy Sony PS, they are unable to support new 
>> technologies, so you games will be blocked by Sony". Of course, unless we 
>> all decide to use 464XLAT instead of CGN ... which resolves the problem.
>> 
>> A massive campaing could work ...
>> 
>> 
>> El 26/8/20 22:08, "NANOG en nombre de surfer" 
>> > sur...@mauigateway.com> escribió:
>> 
>> 
>> 
>>   On 8/26/20 9:28 AM, Tony Wicks wrote:
>>> They're the worst service company I have ever had the displeasure of 
>>> dealing with, the arrogance and attitude of we are big, you are small we 
>>> don't care about your customers was infuriating. Never have I seen a single 
>>> call related to their opposition where as PSN accounted for about 10-20% of 
>>> helpdesk calls. I don't understand why its seemingly impossible for them to 
>>> implement ipv6 as almost everything I have deployed with CGN is dual stack 
>>> V6.
>> 
>>   On 8/26/20 9:30 AM, Mark Tinka wrote:
>>> We'll have to be creative with how we pressure them into getting serious
>>> about IPv6.
>> 
>> 
>>   Do those guys attend NANOG meetings?   >;-)   (evil smile)
>> 
>>   scott
>> 
>> 
>> 
>> **
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>> 
>> This electronic message contains information which may be privileged or 
>> confidential. The information is intended to be for the exclusive use of the 
>> individual(s) named above and further non-explicilty authorized disclosure, 
>> copying, distribution or use of the contents of this information, even if 
>> partially, including attached files, is strictly prohibited and will be 
>> considered a criminal offense. If you are not the intended recipient be 
>> aware that any disclosure, copying, distribution or use of the contents of 
>> this information, even if partially, including attached files, is strictly 
>> prohibited, will be considered a criminal offense, so you must reply to the 
>> original sender to inform about this communication and delete it.
>> 
>> 
>> 
> 
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of the 
> individual(s) named above and further non-explicilty authorized disclosure, 
> copying, distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited and will be 
> considered a criminal offense. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited, will be considered a criminal offense, so you must reply to the 
> original sender to inform about this communication and delete it.
> 
> 
> 

Re: Ipv6 help

[Brian Johnson]

I do not work at either NANOG or Sony. How would my response imply that? Again, 
what is your point?

I have attended a lot of NANOG meetings and CGM/IPv6 transition was a point of 
discussion many times, but as usual it was always in the ether. Few actually 
deployed examples and always worried about breaking the Internet. We broke it 
decades ago and now we are reaping the rewards.

> On Aug 26, 2020, at 4:22 PM, surfer  wrote:
> 
> On 8/26/20 9:28 AM, Tony Wicks wrote:
>>>> They're the worst service company I have ever had the displeasure of 
>>>> dealing with, the arrogance and attitude of we are big, you are small we 
>>>> don't care about your customers was infuriating. Never have I seen a 
>>>> single call related to their opposition where as PSN accounted for about 
>>>> 10-20% of helpdesk calls. I don't understand why its seemingly impossible 
>>>> for them to implement ipv6 as almost everything I have deployed with CGN 
>>>> is dual stack V6.
>>> On 8/26/20 9:30 AM, Mark Tinka wrote:
>>>> We'll have to be creative with how we pressure them into getting serious
>>>> about IPv6.
>>> On Aug 26, 2020, at 3:06 PM, surfer  wrote:
>>> 
>>> Do those guys attend NANOG meetings?   >;-)   (evil smile)
> 
> On 8/26/20 10:09 AM, Brian Johnson wrote:
>> I have/do. Do you have a point?
> ---
> 
> 
> I guess you're implying you work there.  Maybe someone will bake a cake for 
> your company.
> 
> scott
> 
> 
> 

Re: Ipv6 help

[Brian Johnson]

If an ISP provides dual-stack to the customer, then the customer only uses IPv4 
when required and then will only use NAT444 to compensate for a lack of IPv4 
address space when an IPv4 connection is required. What am I missing?

> On Aug 27, 2020, at 1:20 AM, Mark Andrews  wrote:
> 
> 
> 
>> On 27 Aug 2020, at 15:58, Bjørn Mork  wrote:
>> 
>> Brian Johnson  writes:
>> 
>>>> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number 
>>>> of customers.
>>> 
>>> I cannot see how this is even possible. If I use private space
>>> internally to the CGN, then the available external space is the same
>>> and the internal customers are the same and I can do the same over sub
>>> ratio under both circumstance. Tell me how the math is different.
>> 
>> Because NAT64 implies DNS64, which avoids NATing any dual stack service.
>> This makes a major difference today.
> 
> Only if you don’t have a CLAT installed and for home users that is suicide
> at there is too much IPv4 only equipment.
> 
> What really pushes traffic to IPv6 is that hosts prefer IPv6 by default.  This
> works as long as the clients see a dual stack network.
> 
> And no NAT64 does not imply DNS64.  You can publish a ipv4only.arpa zone with
> the mappings for the NAT64.  There are now also RA options for publishing 
> these
> mappings.  There are also DHCPv6 options.
> 
> Mark
> 
>> Bjørn
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

Re: Ipv6 help

[Brian Johnson]

Responses in-line...

> On Aug 27, 2020, at 2:22 AM, JORDI PALET MARTINEZ via NANOG  
> wrote:
> 
> You need to understand the different way NAT64 works vs CGN (and 464XLAT uses 
> NAT64 for the translation): The ports are allocated "on demand" in NAT64.
> 
> While in CGN you allocate a number of ports per customer, for example, 2.000, 
> 4.000, etc.
> 
> If a customer is not using all the ports, they are just wasted. If a customer 
> needs more ports, will have troubles.

So this is actually necessary to lower log volume. Without that, logging would 
have to be per session and would require  excessive storage and long-term 
storage. With deterministic-NAT, we can all but eliminate logging as the 
external IP and port block is algorithmically reversible to the internal 
address and vice-versa.
 
> 
> This doesn't happen in NAT64.
> 
> Let's assume and operator that can get only a /22.

> 
> Let's make some numbers. If an average user uses 300 ports (from a public 
> IP). When using 464XLAT, the number of users within the network, which in 
> IPv4 is behind NAT46, does not trigger that number of ports. Anyway, let's be 
> pessimistic and assume they are quadruple 1,200 ports.
> 
> Approximately 80% of the traffic (2 years ago it was 75%, in many cases it is 
> reaching 90-95%) is IPv6. After the 1,200 ports we only count 20% for IPv4, 
> which is 240 ports.
> 
> Broadly speaking, if we assign NAT64 1,000 IPv4 addresses (assuming the 
> operator needs 24 public IPv4 addresses for BGP and infrastructure, I have 
> done it with much less - because 99% of the infrastructure can be IPv6-only 
> or use private IPv4 for management), and that we use of each IPv4 address 
> assigned to NAT64 only 64,511 ports (65,536-1,024), even knowing that they 
> can all be used (may be you want to allocate some static IP/ports to some 
> customers, etc.):
> 
> 1,000 x 64,511 / 240 = 268,795 subscribers. This is assuming all the 
> subscribers are using all the ports, which typically is not the case.

So this is the same math for NAT444. The typical regional provider would be 
extremely happy getting this much mileage from a /22 block.

> 
> Now, if you have a NAT64 that tracks connections with a 5-tuple, then the 
> number of external ports per user will be almost unlimited.

So we will have to log all sessions?

> 
> But also, this applies to the CLAT, which typically is doing (in CPEs) a 
> stateful NAT44 (to a single private IPv4 address)+stateless NAT46. The NAT44 
> in iptables uses a 5-tuple for connection tracking, so the same external 
> ports can be reused many times as the source address and destination 
> address/port will be different. So in practical cases, the number of external 
> ports only limits the number of parallel connections that a single host 
> behind the NAT can have to the same destination address and port. 
> 
> 
> 
> El 27/8/20 6:55, "Brian Johnson"  escribió:
> 
>Responses in-line
> 
>> On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG 
>>  wrote:
>> 
>> Because:
>> 
>> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of 
>> customers.
> 
>I cannot see how this is even possible. If I use private space internally 
> to the CGN, then the available external space is the same and the internal 
> customers are the same and I can do the same over sub ratio under both 
> circumstance. Tell me how the math is different.
> 
>> 2) It provides the customers as many ports they need (no a limited number of 
>> ports per customer).
> 
>See response to answer 1
> 
>> 3) It is not blocked by PSN (don't know why because don't know how the games 
>> have problems with CGN).
> 
>Interesting, but I’m not sure how any over-loaded NAT translation would 
> look different from the external system. Since you cannot explain it, it’s 
> hard to discuss it.
> 
>> 
>> You could share among an *almost unlimited* number of subscribers an small 
>> IPv4 block (even just a /22).
> 
>The math would be the same as a CGN, so I do not see how this is any less 
> or more useful. It does, however, require CPE capability that appears lacking 
> and NAT444 does not. 
> 
>> 
>> Regards,
>> Jordi
>> @jordipalet
>> 
>> 
>> 
>> El 26/8/20 22:31, "Brian Johnson"  escribió:
>> 
>>   How does 464XLAT solve the problem if you are out of IPv4 space?
>> 
>>> On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG 
>>>  wrote:
>>> 
>>> They know we are there ... so they don't come!
>>> 
>>> By th

Re: Ipv6 help

[Brian Johnson]

I hope I’m not adding to any confusion. I find this conversation to be 
interesting and want it to be productive. I have not deployed 464XLAT and am 
only aware of android phones having a proper client. I have worked with so many 
CPE devices and know that most have solid deployments of the required CLAT 
client. I also predict this will not change any time soon. I live in “actually 
works and is solid” world. Not in “I wish this would work” world.


> On Aug 27, 2020, at 2:50 AM, Mark Andrews  wrote:
> 
> 
> 
>> On 27 Aug 2020, at 17:33, Brian Johnson  wrote:
>> 
>> If an ISP provides dual-stack to the customer, then the customer only uses 
>> IPv4 when required and then will only use NAT444 to compensate for a lack of 
>> IPv4 address space when an IPv4 connection is required. What am I missing?
> 
> Lots of assumptions people are making about how equipment is configured which 
> is causing people to talk past each other.
> 
>>> On Aug 27, 2020, at 1:20 AM, Mark Andrews  wrote:
>>> 
>>> 
>>> 
>>>> On 27 Aug 2020, at 15:58, Bjørn Mork  wrote:
>>>> 
>>>> Brian Johnson  writes:
>>>> 
>>>>>> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same 
>>>>>> number of customers.
>>>>> 
>>>>> I cannot see how this is even possible. If I use private space
>>>>> internally to the CGN, then the available external space is the same
>>>>> and the internal customers are the same and I can do the same over sub
>>>>> ratio under both circumstance. Tell me how the math is different.
>>>> 
>>>> Because NAT64 implies DNS64, which avoids NATing any dual stack service.
>>>> This makes a major difference today.
>>> 
>>> Only if you don’t have a CLAT installed and for home users that is suicide
>>> at there is too much IPv4 only equipment.
>>> 
>>> What really pushes traffic to IPv6 is that hosts prefer IPv6 by default.  
>>> This
>>> works as long as the clients see a dual stack network.
>>> 
>>> And no NAT64 does not imply DNS64.  You can publish a ipv4only.arpa zone 
>>> with
>>> the mappings for the NAT64.  There are now also RA options for publishing 
>>> these
>>> mappings.  There are also DHCPv6 options.
>>> 
>>> Mark
>>> 
>>>> Bjørn
>>> 
>>> -- 
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>>> 
>> 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

Re: Ipv6 help

[Brian Johnson]

Great Write-up Mark. I have some points in-line...

> On Aug 27, 2020, at 3:12 AM, Mark Tinka  wrote:
> 
> 
> 
> On 27/Aug/20 09:33, Brian Johnson wrote:
> 
>> If an ISP provides dual-stack to the customer, then the customer only uses 
>> IPv4 when required and then will only use NAT444 to compensate for a lack of 
>> IPv4 address space when an IPv4 connection is required. What am I missing?
> 
> While modern OS's prefer IPv6, it doesn't mean the end-service supports
> IPv6 yet. If the end-service only supports IPv4, the OS won't try to
> connect on IPv6.
> 

Agree and understand this.

> More importantly, a customer assigned a public IPv4 address will never
> need to use the ISP's CGN nodes. NAT44(4) will only be required for
> customers that are unfortunate enough to require connectivity at a time
> when the ISP can no longer provide a public IPv4 address to them.
> 

Let’s just say that this is happening now for a large number of regional 
providers.

> You can't dynamically cycle customers between public and private IPv4
> addresses based on demand. It's either they have a public IPv4 address,
> or a private IPv4 address. Not both. Yes, there are way you can do this,
> but it's not worth anyone's time and headache.
> 

Let’s say that we switch to a model of all NAT444 for IPv4, with an exception 
for paid static IPv4 customers and that rate is linked to the current going 
rate for an IP address on the market. :)

This is easily doable with any of the access platforms and routing vendors I 
have worked with.

> 464XLAT means customers can only live on IPv6. The ISP can put aside a
> small amount of IPv4 to bridge connectivity between an IPv6-only
> customer to an IPv4-only service for as long as that end-service is
> IPv4-only. Once that IPv4-only services wakes up, gets some clue and
> turns on IPv6 (Sony and PSN, that means you), that is one online
> resources less that the IPv6-only customers requires the 464XLAT
> translation to reach.
> 
> As more end-services turn on IPv6, there is nothing the ISP needs to do
> on the customer side, as they are already on IPv6, which was the biggest
> advantage of the NAT64/DNS64 transition mechanism, and is the biggest
> advantage of 464XLAT.
> 
> Thus, the ISP's demand for 464XLAT reduces (and eventually goes away),
> as does their need to retain whatever amount of IPv4 space they required
> to support the 464XLAT nodes.
> 

If I do dual-stack, but provide private IPv4 to the customer and NAT444 them, 
isn’t this accomplishing the same thing?

> Transitions mechanisms that seek to maintain IPv4 at the customer side
> expose themselves to additional migration work when the majority of the
> world is on IPv6. This is why I generally recommend ISP's (with the
> exception of my competitors, of course) to focus on 464XLAT, as when we
> get to that point, nothing needs to be done with the customer. There is
> value in that!
> 

So for 464XLAT I will need to install a PLAT capable device(s) as well as 
replace all CPE with CLAT capable devices (). I will also need to deal with 
the infancy period as I will GUARANTEE that the CPE will break badly and will 
create additional cost ().

For NAT444 I just need to install NAT444 router(s) . No additional cost for CPE 
or added troubleshooting as the existing CPE is fully baked. Agreed that 
customers will need help with IPv6, but that will be required either way. Also, 
the customer maintains a native IPv4 service (all be it NATed) until IPv4 does 
the dodo dance. In the end, the provider turns-off the NAT444 and disables IPv4 
on their core, which has already been enabled for IPv6 when deploying 
dual-stack.

> Mark.
> 

Re: Ipv6 help

[Brian Johnson]

I'm glad we don’t have the logging requirement in the US where I operate. Is it 
required in other NANOG locations? Canada? Mexico?

Given that there is always the ability to assign additional port blocks as 
needed if a customer exceeds their allotment (requires logging but is still 
minimized due to the block assignment), I have had no issues as we are very 
conservative with the space we had. Most providers are just dealing with growth 
and not a full greenfield, so their existing space gets re-used in their NAT 
deployment and they cut more people over to it as needed.

I was initially skeptical because I thought more things would break, but after 
some initial tweaking, monitoring and long-term grooming, the gremlins are at 
bay and the system runs well and without extra effort.

> On Aug 27, 2020, at 3:30 AM, JORDI PALET MARTINEZ via NANOG  
> wrote:
> 
> In many jurisdictions you need to log every connection even if all the ports 
> belong to each customer. In others not. I've seen jurisdictions where you 
> don't need to log anything and some others, like India, where MAP was 
> discarded by the regulator, because MAP doesn't provide the 5-tuple log, so 
> the deployment was stopped.
> 
> So, in some places, where you will prefer a lower log volume, you can't do 
> it. Or if you do it, it means you need more IPv4 addresses. Where is the 
> balance? Up to each case.
> 
> Is not the same as NAT444, because in NAT444 you need to predefine the number 
> of ports per customer. So there is an under-utilization of IPv4 addresses, or 
> you are exposed to calls to the helpdesk to resolve problems due to the too 
> low number of ports.
> 
> I've done some 464XLAT deplopyments, so I've "some" idea about what I'm 
> talking about. Most of them small "pilots" (3.000 to 12.000 subscribers), 
> right now doing one for 25.000.000 subscribers. Working without issues, just 
> slowed down because the Covid-19 situation. I will prepare some slides about 
> this project once allowed by my customer.
> 
> 
> El 27/8/20 9:50, "Brian Johnson"  escribió:
> 
>Responses in-line...
> 
>> On Aug 27, 2020, at 2:22 AM, JORDI PALET MARTINEZ via NANOG 
>>  wrote:
>> 
>> You need to understand the different way NAT64 works vs CGN (and 464XLAT 
>> uses NAT64 for the translation): The ports are allocated "on demand" in 
>> NAT64.
>> 
>> While in CGN you allocate a number of ports per customer, for example, 
>> 2.000, 4.000, etc.
>> 
>> If a customer is not using all the ports, they are just wasted. If a 
>> customer needs more ports, will have troubles.
> 
>So this is actually necessary to lower log volume. Without that, logging 
> would have to be per session and would require  excessive storage and 
> long-term storage. With deterministic-NAT, we can all but eliminate logging 
> as the external IP and port block is algorithmically reversible to the 
> internal address and vice-versa.
> 
>> 
>> This doesn't happen in NAT64.
>> 
>> Let's assume and operator that can get only a /22.
> 
>> 
>> Let's make some numbers. If an average user uses 300 ports (from a public 
>> IP). When using 464XLAT, the number of users within the network, which in 
>> IPv4 is behind NAT46, does not trigger that number of ports. Anyway, let's 
>> be pessimistic and assume they are quadruple 1,200 ports.
>> 
>> Approximately 80% of the traffic (2 years ago it was 75%, in many cases it 
>> is reaching 90-95%) is IPv6. After the 1,200 ports we only count 20% for 
>> IPv4, which is 240 ports.
>> 
>> Broadly speaking, if we assign NAT64 1,000 IPv4 addresses (assuming the 
>> operator needs 24 public IPv4 addresses for BGP and infrastructure, I have 
>> done it with much less - because 99% of the infrastructure can be IPv6-only 
>> or use private IPv4 for management), and that we use of each IPv4 address 
>> assigned to NAT64 only 64,511 ports (65,536-1,024), even knowing that they 
>> can all be used (may be you want to allocate some static IP/ports to some 
>> customers, etc.):
>> 
>> 1,000 x 64,511 / 240 = 268,795 subscribers. This is assuming all the 
>> subscribers are using all the ports, which typically is not the case.
> 
>So this is the same math for NAT444. The typical regional provider would 
> be extremely happy getting this much mileage from a /22 block.
> 
>> 
>> Now, if you have a NAT64 that tracks connections with a 5-tuple, then the 
>> number of external ports per user will be almost unlimited.
> 
>So we will have to log all sessions?
> 
>> 
>> But also, this

Re: Ipv6 help

[Brian Johnson]

I must have been tired. I read it as do I go to NANOG meetings. Sorry for the 
confusion.

> On Aug 27, 2020, at 12:59 PM, surfer  wrote:
> 
> 
> On Aug 26, 2020, at 4:22 PM, surfer  wrote:
> On 8/26/20 9:28 AM, Tony Wicks wrote:
>>>>>> They're the worst service company I have ever had the displeasure of 
>>>>>> dealing with, the arrogance and attitude of we are big, you are small we 
>>>>>> don't care about your customers was infuriating. Never have I seen a 
>>>>>> single call related to their opposition where as PSN accounted for about 
>>>>>> 10-20% of helpdesk calls. I don't understand why its seemingly 
>>>>>> impossible for them to implement ipv6 as almost everything I have 
>>>>>> deployed with CGN is dual stack V6.
>>>>> On 8/26/20 9:30 AM, Mark Tinka wrote:
>>>>>> We'll have to be creative with how we pressure them into getting serious
>>>>>> about IPv6.
>>>>> On Aug 26, 2020, at 3:06 PM, surfer  wrote:
>>>>> 
>>>>> Do those guys attend NANOG meetings?   >;-)   (evil smile)
>>> On 8/26/20 10:09 AM, Brian Johnson wrote:
>>>> I have/do. Do you have a point?
>>>> ---
>>>> 
>>>> 
>>>> I guess you're implying you work there.  Maybe someone will bake a cake 
>>>> for your company.
> On 8/26/20 6:59 PM, Brian Johnson wrote:
>> I do not work at either NANOG or Sony. How would my response imply that? 
>> Again, what is your point?
>> 
>> I have attended a lot of NANOG meetings and CGM/IPv6 transition was a point 
>> of discussion many times, but as usual it was always in the ether. Few 
>> actually deployed examples and always worried about breaking the Internet. 
>> We broke it decades ago and now we are reaping the rewards.
>> -
> 
> :: I do not work at either NANOG or Sony. How would my response imply that? 
> Again, what is your point?
> 
> Because I said "Do those guys attend NANOG meetings?" and you said "I 
> have/do."  Seems pretty clear to me.
> 
> My point is other NANOG folks could speak to the Sony network engineers 
> directly and find out what Sony's plan is.
> 
> scott
> 

Re: [outages] Major Level3 (CenturyLink) Issues

[Dantzig, Brian]

Cisco had a bug a few years back that affected metro switches such that they 
would not withdraw routes upstream. We had an internal outage and one of my 
carriers kept advertising our prefixes even though we withdrew the routes. We 
tried downing the neighbor and even shutting down the physical interface to no 
avail. The carrier kept blackholing us until they shut down on their metro 
switch.

Re: IPv6 woes - RFC

[Brian Johnson]

> On Sep 11, 2021, at 9:04 PM, Fred Baker  wrote:
> 
> 
> Sent using a machine that autocorrects in interesting ways...
> 
>> On Sep 8, 2021, at 1:31 AM, Saku Ytti  wrote:
>> 
>> If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years
>> whichever it is, then they'd of course have to start moving too,
>> because no upstream.
> 
> And they would fight it tooth and nail, just like they do now, and if they 
> found an address they could NAT to, they would argue that that one address 
> gave them the ability to avoid the transition -just like they do now.

Speaking for the smaller providers, there is enough of the Internet that is 
only accessible via IPv4 out there that CGN solutions are a reasonable way to 
manage the situation. There is also enough legacy equipment out there that 
doesn’t accommodate IPv6 that this process will still take several decades.

Edicts never work. More carrot, less stick.

Re: IPv6 woes - RFC

[Brian Johnson]

Side question on this thread…

Is it everyones current expectation that if a provider were to switch to IPv6 
and drop IPv4 that the customers would all be just fine with that? I believe 
that there are several applications used by some of the the loudest customers 
(typically gamers and network gurus), not to mention some business applications 
that would break or be sub-optimal at best. I see CGN as the band aid to this 
issue, not the cure to the problem.

Discuss…?

 - Brian

> On Sep 23, 2021, at 10:46 AM, Owen DeLong via NANOG  wrote:
> 
>> There are real issues with dual-stack, as this thread started out with.
>> I don't think there is a need neither to invent IPv6 problems, nor to
>> promote IPv6 advantages.  What we need is a way out of dual-stack-hell.
> 
> I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
> 
> I think the only way out is through. Unfortunately, the IPv6 resistant forces
> are making that hard for everyone else.
> 
> Owen
> 

Re: IPv6 woes - RFC

[Brian Johnson]

> On Sep 23, 2021, at 6:49 PM, Owen DeLong  wrote:
> 
> 
> 
>> On Sep 23, 2021, at 12:50 , Brian Johnson  wrote:
>> 
>> Side question on this thread…
>> 
>> Is it everyones current expectation that if a provider were to switch to 
>> IPv6 and drop IPv4 that the customers would all be just fine with that? I 
>> believe that there are several applications used by some of the the loudest 
>> customers (typically gamers and network gurus), not to mention some business 
>> applications that would break or be sub-optimal at best. I see CGN as the 
>> band aid to this issue, not the cure to the problem.
> 
> Today? no.
> 
> At some point when a relatively small number of remaining laggards among 
> major content providers move forward? Yes.

So do we just bleed out in the mean time?

> 
> Do you really think that those applications/vendors wouldn’t move quickly if 
> a couple of major eyeball providers announced “Effective X date”, we’re going 
> to start offering a $X/month discount to any customer(s) who are willing to 
> stop using IPv4.

I’d be happy to suggest this to my clients, but it’s not a real thing yet. 
Plus, the average human (even the average CSR at a small regional provider 
network) has no idea what this means.

> 
> You an only cover an arterial bleed with a band-aid for so long before it 
> becomes silly, septic even. If you’re wondering how quick that point is 
> coming up, I suggest you check your mirrors.

Triage suggests that you assist in succession of the current bleeding before 
being concerned about the next time you are cut. I have BGN deployments that 
have been in place for 4+ years with little customer knowledge. It has allowed 
clients to avoid the IPv4 market issues, and in some instances, become a source 
for others to help compensate for the initial CGN expense.

I totally agree with you in spirit, but I am working on the problem of now, not 
the problem of some point in the future. The cost of CGN is becoming less 
expensive than IPv4 space acquisition. I wish this weren’t true.

> 
> Owen
> 
>> 
>> Discuss…?
>> 
>> - Brian
>> 
>>> On Sep 23, 2021, at 10:46 AM, Owen DeLong via NANOG  wrote:
>>> 
>>>> There are real issues with dual-stack, as this thread started out with.
>>>> I don't think there is a need neither to invent IPv6 problems, nor to
>>>> promote IPv6 advantages.  What we need is a way out of dual-stack-hell.
>>> 
>>> I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
>>> 
>>> I think the only way out is through. Unfortunately, the IPv6 resistant 
>>> forces
>>> are making that hard for everyone else.
>>> 
>>> Owen
>>> 
>> 
> 

Re: uPRF strict more

[Brian Johnson]

For strict-mode... Completely agree.

As has been previously said, this is a tool that all players involved need to 
understand. This is no different than everyone correctly using BGP in their 
application for their outcomes.

> On Sep 29, 2021, at 12:07 PM, Adam Thompson  wrote:
> 
> We just ran into a typical case where uRPF caused a partial outage for one of 
> my customers: the customer is multi-homed, with another provider that I'm 
> also​ connected to.  Customer advertised a longer-prefix to the other guy, so 
> I started sending traffic destined for Customer to the Other Provider... who 
> then promptly dropped it because they had uRPF enabled on the peering link, 
> and they were seeing random source IPs that weren't mine.  Well... yeah, that 
> can happen (semi-legitimately) anytime you have a topological triangle in 
> peering.
> 
> I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
> pointing directly at non-multi-homed customers, and actively dangerous 
> anywhere else.
> 
> -Adam
> 
> Adam Thompson
> Consultant, Infrastructure Services
> 
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca 
> www.merlin.mb.ca 
> From: NANOG  on behalf of 
> Amir Herzberg 
> Sent: September 28, 2021 20:06
> To: Randy Bush 
> Cc: North American Network Operators' Group 
> Subject: Re: uPRF strict more
>  
> Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
> to high potential for benign loss); it's always great to be either confirmed 
> or corrected... 
> 
> So if anyone replies just to Randy - pls cc me too (or, Randy, if you could 
> sum up and send to list or me - thanks!)
> 
> Amir
> -- 
> Amir Herzberg
> 
> Comcast professor of Security Innovations, Computer Science and Engineering, 
> University of Connecticut
> Homepage: https://sites.google.com/site/amirherzberg/home 
> 
> `Applied Introduction to Cryptography' textbook and lectures: 
> https://sites.google.com/site/amirherzberg/applied-crypto-textbook 
> 
> 
> 
> 
> 
> On Tue, Sep 28, 2021 at 8:50 PM Randy Bush  > wrote:
> do folk use uPRF strict mode?  i always worried about the multi-homed
> customer sending packets out the other way which loop back to me;  see
> RFC 8704 §2.2
> 
> do vendors implement the complexity of 8704; and, if so, do operators
> use it?
> 
> clue bat please
> 
> randy

Re: Network visibility

[Brian Johnson]

+1 on -48VDC.

> On Oct 20, 2021, at 1:38 PM, Lady Benjamin Cannon of Glencoe, ASCE 
>  wrote:
> 
>> On Oct 20, 2021, at 8:04 AM, Mark Tinka > > wrote:
>> 
>> 
>> At any rate, you may very well need more than one system to monitor your 
>> entire network.
>> 
>> Mark.
> 
> Not the least of reasons for this: Redundancy.  We have more than 1 tool 
> doing every job, incase there’s a bug with something someday, or some 
> platform reboots during a hurricane, etc.  2 is 1 and 1 is none and -48VDC 
> power is still the best. 
> 
> Happy Birthday Internet <3 
> 
> —L.B.
> 
> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
> 6x7 Networks & 6x7 Telecom, LLC 
> CEO 
> l...@6by7.net 
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
> FCC License KJ6FJJ
> 
> 
> 
> 

Re: Network visibility

[Brian Johnson]

There is still zoning on some platforms, but there are now redundancies for the 
zones.

> On Oct 21, 2021, at 12:22 AM, Mark Tinka  wrote:
> 
> 
> 
> On 10/21/21 03:19, Brian Johnson wrote:
> 
>> +1 on -48VDC.
> 
> Wasn't much fun when half the router would shutdown because power supplies 
> failed, due to what was known as "power zoning" those days.
> 
> I haven't deployed a larger router on DC in over 13 years. I'm not sure if 
> this is still a thing, even.
> 
> Mark.

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: Can it really be this quiet?

[Brian Reichert]

On Mon, Jan 03, 2022 at 02:46:59PM -0500, Allen McKinley Kitchen (gmail) wrote:
> Or has NANOG also succumbed to a signed-integer date problem?
> 
> Waiting to see what I get back..

Don't jinx it...

> ..Allen

-- 
Brian Reichert  
BSD admin/developer at large

Midcontinent Communications

[Brian Johnson]

I am looking for someone in network engineering/design at Midcontinent 
Communications (AS11232) who can explain why the IPv6 PD is set to 64 bits. I 
believe that this is a poor design decision and would like to understand how 
this decision was made.

Thanks.

- Brian

Re: New minimum speed for US broadband connections

[Brian Johnson]

Given this premise (that it is too expensive to provide access to rural areas), 
can you explain why nearly 100% of North Dakota is serviced by FTTH solutions. 
The exceptions being the areas still run by the traditional LECs?

I’m not to sure this should be an urban/rural debate. 

> On Feb 28, 2022, at 2:53 PM, Josh Luthman  wrote:
> 
> Ryan,
> 
> This discussion was in regards to urban areas.
> 
> Regarding your example, though, I expect you're in a hard to reach rural area 
> based on your description.  It looks like there are absolutely a massive 
> amount of trees, making it hard for fixed wireless.  Since it sounds like 
> your only option, which is better than no option at all, that's probably why 
> no wired solution has decided to build service there.  At $50k/mile being a 
> pretty modest cost, at $200/mo does that seem like a viable business plan to 
> you?
> 
> On Fri, Feb 25, 2022 at 11:25 PM Ryan Rawdon  > wrote:
> 
>> On Feb 16, 2022, at 4:46 PM, Michael Thomas > > wrote:
>> 
>> 
>> 
>> On 2/16/22 1:36 PM, Josh Luthman wrote:
>>> What is the embarrassment?
>> That in the tech center of the world that we're so embarrassingly behind the 
>> times with broadband. I'm going to get fiber in the rural Sierra Nevada 
>> before Silicon Valley. In fact, I already have it, they just haven't 
>> installed the NID. 
>> 
>> Mike
>> 
>> 
>> 
> I will provide another specific example albeit not San Jose but similar 
> enough.  I am in  Loudoun County less than 25 minutes from Ashburn, VA.My 
> best option is fixed wireless from All Points Broadband (hi Tim) which is 
> 15/3mbit/s costing $199/mo (they have cheaper, slower tiers available).  
> 
> Verizon FiOS serves a dense developer-built community less than 1 mile down 
> the street from me, but everyone else outside of the towns and 
> developer-built communities have almost zero options.
> 
> Similar to the San Jose examples, we are near some of the most dense 
> connectivity in the world.  Travel 20-30 minutes in certain directions from 
> Ashburn and you’re quickly seeing farms and limited connectivity.
> 
> Ryan
>> 
>>> 
>>> On Wed, Feb 16, 2022 at 4:28 PM Michael Thomas >> > wrote:
>>> 
>>> 
>>> On 2/16/22 1:13 PM, Josh Luthman wrote:
 I'll once again please ask for specific examples as I continue to see the 
 generic "it isn't in some parts of San Jose".
 
 On the note of the generic area of San Jose, I'm all but certain this has 
 a lot to do with California and its extraordinarily complicated and near 
 impossible accessibility to obtain CLEC status.  This makes competition 
 pretty much impossible and makes the costs of operating one 
 extraordinarily high.  I'm obviously not going to be one that claims that 
 government is good or bad, just pointing out a certain correlation which 
 could potentially be causation.
>>> Sonic has been installing fiber in San Francisco and other areas, but they 
>>> are really small. Comcast can't be bothered that I've ever heard. The only 
>>> other real alternative is things like Monkeybrains which is a WISP. It's 
>>> really an embarrassment. 
>>> 
>>> Mike
>>> 
 
 On Wed, Feb 16, 2022 at 12:52 PM Owen DeLong >>> > wrote:
 
 
> On Feb 11, 2022, at 13:14 , Josh Luthman  > wrote:
> 
> Because literally every case I've seen along these lines is someone 
> complaining about the coax connection is "only 100 meg when I pay for 200 
> meg".  Comcast was the most hated company and yet they factually had 
> better speeds (possibly in part to their subjectively terrible customer 
> service) for years.
> 
> >An apartment building could have cheap 1G fiber and the houses across 
> >the street have no option but slow DSL.
> 
> Where is this example?  Or is this strictly hypothetical?
 
 There are literally dozens (if not thousands) of such examples in silicon 
 valley alone.
 
> I am not seeing any examples, anywhere, with accurate data, where it's 
> what most consider to be in town/urban and poor speeds.  The only one 
> that was close was Jared and I'm pretty sure when I saw the map I 
> wouldn't consider that in town (could be wrong) but again, there's gig 
> fiber there now.  I don't remember if he actually got his CLEC, or why 
> that matters, but there's fiber there now.
 
 Pretty sure you would have a hard time calling San Jose “not in town”. 
 It’s literally #11 in the largest 200 cities in the US with a population 
 of 1,003,120 (954,940 in the 2010 census) and a population density of 
 5,642 people/sq. mile (compare to #4 Houston, TX at 3,632/Sq. Mi.).
 
 Similar conditions exist in parts of Los Angeles, #2 on the same list at 
 3,985,516 (3,795,512 in 2010 census) and 8,499/Sq. Mi.
 
 I speak of Cal

Re: New minimum speed for US broadband connections

[Brian Johnson]

I said North Dakota, not population centers (they are where the legacy LECs 
operate). I have lived and worked there for telecommunications Coops which 
device the land mass of the state. They had no issues providing the most 
cutting edge service to extremely rural areas. What is the excuse of the larger 
LECs? There are many regional Coops and CLECs starting to build out these 
population centers now. These numbers are crap and nobody should believe them.

I realize there are differences between rural and urban deployments, but this 
is a problem that is more political than technical. In rural areas we are more 
interested in getting things done, while in urban areas we appear to be more 
interested in political wins.


> On Feb 28, 2022, at 3:29 PM, Josh Luthman  wrote:
> 
> According to the 477 data it's less than 50% (updated 11/1/2021 and I think 
> the public 477 is 2 years? behind)  What makes you believe it's nearly 100%?
> 
> https://broadbandnow.com/North-Dakota <https://broadbandnow.com/North-Dakota>
> On Mon, Feb 28, 2022 at 4:22 PM Brian Johnson  <mailto:brian.john...@netgeek.us>> wrote:
> Given this premise (that it is too expensive to provide access to rural 
> areas), can you explain why nearly 100% of North Dakota is serviced by FTTH 
> solutions. The exceptions being the areas still run by the traditional LECs?
> 
> I’m not to sure this should be an urban/rural debate. 
> 
>> On Feb 28, 2022, at 2:53 PM, Josh Luthman > <mailto:j...@imaginenetworksllc.com>> wrote:
>> 
>> Ryan,
>> 
>> This discussion was in regards to urban areas.
>> 
>> Regarding your example, though, I expect you're in a hard to reach rural 
>> area based on your description.  It looks like there are absolutely a 
>> massive amount of trees, making it hard for fixed wireless.  Since it sounds 
>> like your only option, which is better than no option at all, that's 
>> probably why no wired solution has decided to build service there.  At 
>> $50k/mile being a pretty modest cost, at $200/mo does that seem like a 
>> viable business plan to you?
>> 
>> On Fri, Feb 25, 2022 at 11:25 PM Ryan Rawdon > <mailto:r...@u13.net>> wrote:
>> 
>>> On Feb 16, 2022, at 4:46 PM, Michael Thomas >> <mailto:m...@mtcc.com>> wrote:
>>> 
>>> 
>>> 
>>> On 2/16/22 1:36 PM, Josh Luthman wrote:
>>>> What is the embarrassment?
>>> That in the tech center of the world that we're so embarrassingly behind 
>>> the times with broadband. I'm going to get fiber in the rural Sierra Nevada 
>>> before Silicon Valley. In fact, I already have it, they just haven't 
>>> installed the NID. 
>>> 
>>> Mike
>>> 
>>> 
>>> 
>> I will provide another specific example albeit not San Jose but similar 
>> enough.  I am in  Loudoun County less than 25 minutes from Ashburn, VA.
>> My best option is fixed wireless from All Points Broadband (hi Tim) which is 
>> 15/3mbit/s costing $199/mo (they have cheaper, slower tiers available).  
>> 
>> Verizon FiOS serves a dense developer-built community less than 1 mile down 
>> the street from me, but everyone else outside of the towns and 
>> developer-built communities have almost zero options.
>> 
>> Similar to the San Jose examples, we are near some of the most dense 
>> connectivity in the world.  Travel 20-30 minutes in certain directions from 
>> Ashburn and you’re quickly seeing farms and limited connectivity.
>> 
>> Ryan
>>> 
>>>> 
>>>> On Wed, Feb 16, 2022 at 4:28 PM Michael Thomas >>> <mailto:m...@mtcc.com>> wrote:
>>>> 
>>>> 
>>>> On 2/16/22 1:13 PM, Josh Luthman wrote:
>>>>> I'll once again please ask for specific examples as I continue to see the 
>>>>> generic "it isn't in some parts of San Jose".
>>>>> 
>>>>> On the note of the generic area of San Jose, I'm all but certain this has 
>>>>> a lot to do with California and its extraordinarily complicated and near 
>>>>> impossible accessibility to obtain CLEC status.  This makes competition 
>>>>> pretty much impossible and makes the costs of operating one 
>>>>> extraordinarily high.  I'm obviously not going to be one that claims that 
>>>>> government is good or bad, just pointing out a certain correlation which 
>>>>> could potentially be causation.
>>>> Sonic has been installing fiber in San Francisco and other areas, but they 
>>>> a

Re: New minimum speed for US broadband connections

[Brian Johnson]

> On Feb 28, 2022, at 4:44 PM, Josh Luthman  wrote:
> 
> That is North Dakota, not population centers.  Click the link.

> 
> You're basing fiber availability everywhere on living?  That's a poor excuse 
> for data.

I did. The numbers are related to population, not area. If you move outside of 
the major population centers, you get exponentially better service. I also 
checked several of the area codes I am very familiar with and they list 
wireless carriers over regional/local providers who provide a better and more 
robust service. Several of the details about the providers services are also 
flawed.

It looks more like a marketing site than a truth source.

> 
> >These numbers are crap and nobody should believe them.
> 
> Lol ok but we should believe nearly 100% from you because you lived in a 
> couple places?

I lived there and worked with nearly every regional provider in the state for 
oner a decade. I know their networks and the statewide coop that they own’s 
network. 

> 
> >but this is a problem that is more political than technical.
> 
> Strong disagreement here.  What makes you say this?

I’ve been doing SP network design for more than 20 years. If the LECs wanted to 
provide the service in these areas, they could have. They decided it was better 
to just milk the system, then prepare for the future.

> 
> On Mon, Feb 28, 2022, 5:04 PM Brian Johnson  <mailto:brian.john...@netgeek.us>> wrote:
> I said North Dakota, not population centers (they are where the legacy LECs 
> operate). I have lived and worked there for telecommunications Coops which 
> device the land mass of the state. They had no issues providing the most 
> cutting edge service to extremely rural areas. What is the excuse of the 
> larger LECs? There are many regional Coops and CLECs starting to build out 
> these population centers now. These numbers are crap and nobody should 
> believe them.
> 
> I realize there are differences between rural and urban deployments, but this 
> is a problem that is more political than technical. In rural areas we are 
> more interested in getting things done, while in urban areas we appear to be 
> more interested in political wins.
> 
> 
>> On Feb 28, 2022, at 3:29 PM, Josh Luthman > <mailto:j...@imaginenetworksllc.com>> wrote:
>> 
>> According to the 477 data it's less than 50% (updated 11/1/2021 and I think 
>> the public 477 is 2 years? behind)  What makes you believe it's nearly 100%?
>> 
>> https://broadbandnow.com/North-Dakota <https://broadbandnow.com/North-Dakota>
>> On Mon, Feb 28, 2022 at 4:22 PM Brian Johnson > <mailto:brian.john...@netgeek.us>> wrote:
>> Given this premise (that it is too expensive to provide access to rural 
>> areas), can you explain why nearly 100% of North Dakota is serviced by FTTH 
>> solutions. The exceptions being the areas still run by the traditional LECs?
>> 
>> I’m not to sure this should be an urban/rural debate. 
>> 
>>> On Feb 28, 2022, at 2:53 PM, Josh Luthman >> <mailto:j...@imaginenetworksllc.com>> wrote:
>>> 
>>> Ryan,
>>> 
>>> This discussion was in regards to urban areas.
>>> 
>>> Regarding your example, though, I expect you're in a hard to reach rural 
>>> area based on your description.  It looks like there are absolutely a 
>>> massive amount of trees, making it hard for fixed wireless.  Since it 
>>> sounds like your only option, which is better than no option at all, that's 
>>> probably why no wired solution has decided to build service there.  At 
>>> $50k/mile being a pretty modest cost, at $200/mo does that seem like a 
>>> viable business plan to you?
>>> 
>>> On Fri, Feb 25, 2022 at 11:25 PM Ryan Rawdon >> <mailto:r...@u13.net>> wrote:
>>> 
>>>> On Feb 16, 2022, at 4:46 PM, Michael Thomas >>> <mailto:m...@mtcc.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 2/16/22 1:36 PM, Josh Luthman wrote:
>>>>> What is the embarrassment?
>>>> That in the tech center of the world that we're so embarrassingly behind 
>>>> the times with broadband. I'm going to get fiber in the rural Sierra 
>>>> Nevada before Silicon Valley. In fact, I already have it, they just 
>>>> haven't installed the NID. 
>>>> 
>>>> Mike
>>>> 
>>>> 
>>>> 
>>> I will provide another specific example albeit not San Jose but similar 
>>> enough.  I am in  Loudoun County less than 25 minutes from Ashburn, VA.
>>> My best option

Re: Ukraine request yikes

[Brian R]

The problem with all this talk, especially with trusted international neutral 
organizations, is that once they bend they will never be trusted again.  
Shutting off the routes, removing TLDs (or keeping them because of politics), 
etc will cause irreparable damage to these organizations.  Bowing to 
governments, politics, etc does not have a path back from future control.
This is a recommendation that will only hurt people (China, North Korea, [even 
the USA], etc all do this to control their people).  Governments will get 
around whatever the limitations are, it may take them time and resources but 
they will get around it.  Freedom of information is the only way to help people 
understand the reality of what is going on in the world (galaxy, universe, etc).

Brian
Technological solutions for Sociological problems


From: NANOG  on behalf of 
Bryan Fields 
Sent: Tuesday, March 1, 2022 1:23 PM
To: nanog@nanog.org 
Subject: Re: Ukraine request yikes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 3/1/22 4:08 PM, David Conrad wrote:
> See .SU.
>
> (SU was moved from allocated to "transitionally reserved” back when the
> USSR broke up. My recollection is that an agreement was reached by which
> .SU users would be migrated out to appropriate new ccTLDs, that is, the
> ccTLDs based on ISO codes created for former Soviet republics, and no new
> entries would be added to .SU. However, when ICANN tried to propose a plan
> to finalize removing .SU from the root (around 2006 or so), the operators
> of .SU reopened registrations and complained to the US Dept. of Commerce,
> who were overseeing ICANN performance of the IANA Functions contract.
> Eventually, the Russian government was able to convince ISO-3166/MA to move
> SU to “exceptionally reserved” (like UK, EU, and a number of others) and
> forward motion on removing .SU from the root essentially ceased.)

I know someone (non-Russian) using .su for a funny name ending in .su.  This
is non-political and caters only to an English speaking audience.  These were
registered in the last few years, so they are still open and taking the
registrations.

I would ask what of .ly used for various URL shorteners, and .kp or .cn?  All
these are representing evil countries too, why do they get a pass.  I'm
certain they would argue .us should be revoked for the same.

This would break connectivity, and that's a bad thing.
- --
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAmIejrUACgkQYTmgYVLG
kUA+QQ//Z9ovTSFqVEunql2guHAN3xWaNpCpuNJCGM68dJTBSWrPEY0zFXlmZG1k
0TWrSrRSoWogiJmRvaOuFx6KxkaADqZaZq6OFaCw3jvyFGULw+auyuATGlhnUL8p
CV0AbovPUnoAef1qJdglFkqnfrGBxeBGsgRIM8tx2l/G+zq5MdMnCx9cM+JmmN1y
b+jrV4oekgXRZLAMI/sA9clMAXUmlgReRvit8YBccunkmMP8naQ92vj9dvVGZld0
hGguK2a7vFXpDiW5o0nFe5GRdGIqM0aWUz6p0qkB9JudkZkAyEqSpCePZky4LdAt
ebh9544PZu/vllQjv3L6vENlCURcifTIRSevcwfKZtos7UG4mJI1UQ51OLTRjB7a
nqYkVNJSQJ+dXZFLPoRHNUOu4+1MAyozpDeMJzMsr4a7Ru2lh0AOTiXxDaSRhOd+
2s3rQigh/l6cP/x9iM7+f+rInHzPihHfjbwcxhyqd12EFxgTe3hvi9JlRSe18RYw
bnDKQg3xKp1eIk0sZMeLyIWDERjsMxIuEP9MuKHp+oTCrLq6MFSgUiFan7M5Pk2t
mwB3sbFuwkVzfmDbbnbelll30ukXQM3d7KVp2AHbsvI6hNs6zHZgRb7ZgGrR9Ep5
6UlYqVqQOWtYNujNxYRgzemFI6lgJj8GHyDeh0wLRCP0aw/ATPg=
=KK8e
-END PGP SIGNATURE-

Re: ICANN Response (Re: Ukraine request yikes)

[Brian R]

John,

Thank you for these.  I'm glad to hear the stance on both of these.

Brian

From: NANOG  on behalf of 
John Curran 
Sent: Thursday, March 3, 2022 5:04 AM
To: Nanog 
Subject: ICANN Response (Re: Ukraine request yikes)

ICANN response request from the Ukraine regarding various DNS interventions – 
https://www.icann.org/en/system/files/correspondence/marby-to-fedorov-02mar22-en.pdf

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers


On 2 Mar 2022, at 1:01 AM, John Curran 
mailto:jcur...@arin.net>> wrote:

Regarding the portion of the request to the RIPE NCC to withdraw the relevant 
Russia registered IP address blocks, it appears that the RIPE NCC has 
reiterated their position on such disputes -
https://www.ripe.net/publications/news/announcements/ripe-ncc-executive-board-resolution-on-provision-of-critical-services

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers

On 1 Mar 2022, at 3:25 AM, Ryan Hamel 
mailto:administra...@rkhtech.org>> wrote:

It’s already spread to the news - 
https://www.rollingstone.com/politics/politics-news/ukraine-icann-russia-internet-runet-disconnection-1314278/

Ryan

From: NANOG 
mailto:nanog-bounces+ryan=rkhtech@nanog.org>>
 On Behalf Of George Herbert
Sent: Tuesday, March 1, 2022 12:17 AM
To: Nanog mailto:nanog@nanog.org>>
Subject: Ukraine request yikes

Posted by Bill Woodcock on Twitter… 
https://twitter.com/woodyatpch/status/1498472865301098500?s=21

https://pastebin.com/DLbmYahS

Ukraine (I think I read as) want ICANN to turn root nameservers off, revoke 
address delegations, and turn off TLDs for Russia.

Seems… instability creating…


-george

Sent from my iPhone

Re: Upwork Suspending Operations in Russia and Belarus

[brian . johnson]

Upwork != NANOG

- Brian

> On Mar 8, 2022, at 3:22 PM, Callan Banner  wrote:
> 
> Nanog to suspend work in Belarus and Russia. How do you all feel about this? 
> Senseless antagonization or correctly applied pressure? 
> 
> -- Forwarded message -
> From: Hayden Brown, Upwork President & CEO  <mailto:upw...@t.upwork.com>>
> Date: Tue, Mar 8, 2022 at 12:51 PM
> Subject: Upwork Suspending Operations in Russia and Belarus
> To: mailto:m...@callan.im>>
> 
> 
>  
> <https://link.t.upwork.com/ls/click?upn=VqS90m2f8fx8n-2F1K6AZcGXfLgLUteWUSWnuuKn7bbJPL-2FO8m3inY1PqJ73crxew80PjlJt5qPr02gFiHjxdyKkobhczHrZAVPZ3HNowrdPq9BbUqlesjV-2FOGhzE3Y6SKIaCDAKek2t8U70UR7LtRaodY7O1sxKbbtg-2FlKBjlzjsxJ4JMLo7uEJiO6agMn3cJtn_t_GSDjQUoJprWZFQuNBCzFKCSgRNuZk8x9-2Fwc0CoB0e3zqXa-2BLRGEslcb5uWvcPHQA8e-2Bn2N-2BDnNBtnZT-2BpOr4mpK4gRe6NwBOPp-2Bl-2FgGjrc0nncNDF6LagA0bcRq8YwYCLLmdrZX-2FqEC33hqEQPFF-2Bs77c-2BTuNA9tkJ647vWaf2d1FgyRo7rzt0ImvjhMfo4Czw0chMfnHsKzwaCfxEy6-2BoKeq80fiKJZgSu-2BJR5fiqpNN29WT9FBLXfH2dGEVnQV59vB80VXjQQ26j4sMTlusXjCZ88Ia3Ijv-2FujlzmlxfRGGX-2B14U-2F9MRHrHNRbIRysgkaRLR4Rs49xeNEDBmvDhna3DR9WUrPL3Vnc9-2B1JxEOEDqYVGrTpCn1l7Th9154oJBvSivKIa7M1sn18zPSqlHaEcPhUMMZgNoaz01kOE5jS2Fl-2BYwnmuLSZADD7LvyjDE-2B4BoGZ10FMXQDQPU-2BgZHvN89nw6tGobZliMgZ-2BccrK1EsYotRloGBNwtP4Ly8-2FVUyFSzavjl6VDv8BOXXXFra9kLl5vTdRfTxIGaII-2B6WrP6eNqGgHSQ2i6t7TUsjsflLbZpyGre-2BmzX7AZ0GRMspvVGCaANVkRvS41HkdRHLbJA4GPOe0JfMHbdGsnmphYNzfz81HGk1ktASLI4OU7Q-3D-3D>
> Dear Callan,
> As the world’s work marketplace, Upwork’s mission is to create economic 
> opportunities so people have better lives. In our more than 20 years of doing 
> business, we have worked hard to bring our marketplace to more people, with 
> the belief that when people have the ability to innovate their careers and 
> work, they can reach their full potential.
> 
> Russian President Vladimir Putin’s war against Ukraine has challenged our 
> mission, values, and our operational ability to bring economic empowerment to 
> those who seek it. Upwork has begun suspending operations in Russia and 
> Belarus and will take full effect by May 1, 2022.
> 
> The first step will be shutting down Upwork’s support for new business 
> generation in Russia and Belarus. Over the next few days, freelancers and 
> clients in Russia and Belarus will no longer be able to sign up for new 
> accounts, initiate new contracts, and be visible in search.
> 
> We honor the relationships that exist between our customers and recognize the 
> swift adjustments that they will need to make as they process this 
> announcement. As such, existing contracts with talent and clients in the 
> region will remain open, with final billing due by May 1, 2022.
> 
> We made this decision with the utmost consideration. From the beginning of 
> the war, Upwork has been fervently working to support the safety, security, 
> and well-being of our many team members in the region, as well as the 
> business needs of our customers. We fully understand the significant impact 
> this decision has on our Upwork community in Russia and Belarus, and we want 
> these customers to know that if and when they are able to relocate to regions 
> where we operate, we will be eager to support them in continuing their work 
> on our platform. Additionally, should the geopolitical situation in Russia 
> and Belarus change, we hope to be able to resume operations.
>  
> We are heartbroken and horrified by the invasion of Ukraine. Upwork is 
> concurrently working on measures – both immediate and rolling out soon – to 
> further support Ukrainian freelancers and the Ukrainian community, including:
> • A $1 million donation to Direct Relief International 
> <https://link.t.upwork.com/ls/click?upn=VqS90m2f8fx8n-2F1K6AZcGWG3CACp-2BoZjl-2B8R42pvhxEXa-2BGYyykVWjPqlOaTMooNU2Gba6t-2FwKuYzgXMGSEIhA-3D-3DLFDx_GSDjQUoJprWZFQuNBCzFKCSgRNuZk8x9-2Fwc0CoB0e3zqXa-2BLRGEslcb5uWvcPHQA8e-2Bn2N-2BDnNBtnZT-2BpOr4mpK4gRe6NwBOPp-2Bl-2FgGjrc0nncNDF6LagA0bcRq8YwYCLLmdrZX-2FqEC33hqEQPFF-2Bs77c-2BTuNA9tkJ647vWaf2d1FgyRo7rzt0ImvjhMfo4Czw0chMfnHsKzwaCfxEy6-2BoKeq80fiKJZgSu-2BJR5fiqpNN29WT9FBLXfH2dGEVnQV59vB80VXjQQ26j4sMTlusXjCZ88Ia3Ijv-2FujlzmlxfRGGX-2B14U-2F9MRHrHNRbIRysgkaRLR4Rs49xeNEDBmvDhna3DR9WUrPL3Vnc9-2B1JxEOEDqYVGrTpCn1l7Th9154oJBvSivKIa7M1sn18zPSqlHaEcPhUMMZgNoaz01kOE5jS2Fl-2BYwnmuLSZADD7LvyjDE-2B4BoGZ10FMXQDQPU-2BgZHvN89nw6tGobZliMgZ-2BccrK1EsYotRloGBNwtP4Ly8-2FgBrVSEe6mrSMiRnNYMTCA98f5FW-2B5-2B5-2B5Waqt-2BkCDdkvMR07zzbX1YSzFuCToQ2o49VObqBiPMBT0jzAcme5R7IKtUu5lqi4EiBM2V0QU07BLt1Op-2F9fwmyaK4FK3W5T5F3ZoRZ70OjTYHifazL2xw-3D-3D>
>  in support of the Ukrainian population.
> • Product enhancements to make it easier for Ukrainian freelancers to 
> preserve the careers they have worked so hard to establish, whether or not 
> they are currently able to work.
> • Pr

Re: Dropping support for the .ru top level domain

[Brian R]

I can understand governments wanting this to be an option but I would let them 
do blocking within their countries to their own people if that is their desire. 
 This is another pandoras box.  Its bad enough that some countries control this 
already to block free flow of information.
If global DNS is no longer trusted then many actors will start maintaining 
their own broken lists (intentionally or unintentionally).

  *   This will not stop Russia, they will just run their own state sponsored 
DNS servers.  We can imagine what else might be implemented on that concept...
  *   Countries or users that still want access will do the same with custom 
DNS servers.
  *   This will take us down another path of no return as a global standard 
that is not political or politically controlled.
  *   The belief that the internet is open and free (as much as possible) will 
be broken in one more way.
  *   This will also accelerate the advancement of crypto DNS like NameCoin 
(Years ago I liked the idea but I don't know how it is being run anymore.) or 
UnstoppableDomains for example.   Similar to what is starting to happen to 
central banking as countries start shutting down bank accounts for political 
reasons.

I am glad to see soo many people on here and many of the organizations running 
these services state as much.

Brian



From: NANOG  on behalf of 
Patrick Bryant 
Sent: Saturday, March 12, 2022 2:47 AM
To: nanog@nanog.org 
Subject: Dropping support for the .ru top level domain

I don't like the idea of disrupting any Internet service. But the current 
situation is unprecedented.

The Achilles Heel of general public use of Internet services has always been 
the functionality of DNS.

Unlike Layer 3 disruptions, dropping or disrupting support for the .ru TLD can 
be accomplished without disrupting the Russian population's ability to access 
information and services in the West.

The only countermeasure would be the distribution of Russian national DNS zones 
to a multiplicity of individual DNS resolvers within Russia. Russian operators 
are in fact implementing this countermeasure, but it is a slow and arduous 
process, and it will entail many of the operational difficulties that existed 
with distributing Host files, which DNS was implemented to overcome.

The .ru TLD could be globally disrupted by dropping the .ru zone from the 13 
DNS root servers. This would be the most effective action, but would require an 
authoritative consensus. One level down in DNS delegation are the 5 
authoritative servers. I will leave it to the imagination of others to envision 
what action that could be taken there...

ru  nameserver = a.dns.ripn.net<http://a.dns.ripn.net>
ru  nameserver = b.dns.ripn.net<http://b.dns.ripn.net>
ru  nameserver = d.dns.ripn.net<http://d.dns.ripn.net>
ru  nameserver = e.dns.ripn.net<http://e.dns.ripn.net>
ru  nameserver = f.dns.ripn.net<http://f.dns.ripn.net>

The impact of any action would take time (days) to propagate.

Re: Dropping support for the .ru top level domain

[Brian R]

Agreed

Brian

From: Mel Beckman 
Sent: Monday, March 14, 2022 7:07 PM
To: Fred Baker 
Cc: Brian R ; nanog@nanog.org 
Subject: Re: Dropping support for the .ru top level domain

+1

 -mel beckman

On Mar 14, 2022, at 9:29 PM, Fred Baker  wrote:

 My viewpoint, and the reason I recommended against it, is that it gives Putin 
something he has wanted for a while, which is a Russia in which he is in 
control of information flows. We do for him what he has wanted for perhaps 20 
years, and come out the bad guys - “the terrible west gut us off!”.  I would 
rather have people in Russia have information flows that have a second 
viewpoint other than the Kremlin’s. I have no expectation that it will get 
through uncensored, but I would rather it was not in any sense “our fault” and 
therefore usable by Putin’s propaganda machine.

Sent from my iPad

On Mar 14, 2022, at 2:14 PM, Brian R  wrote:


I can understand governments wanting this to be an option but I would let them 
do blocking within their countries to their own people if that is their desire. 
 This is another pandoras box.  Its bad enough that some countries control this 
already to block free flow of information.
If global DNS is no longer trusted then many actors will start maintaining 
their own broken lists (intentionally or unintentionally).

  *   This will not stop Russia, they will just run their own state sponsored 
DNS servers.  We can imagine what else might be implemented on that concept...
  *   Countries or users that still want access will do the same with custom 
DNS servers.
  *   This will take us down another path of no return as a global standard 
that is not political or politically controlled.
  *   The belief that the internet is open and free (as much as possible) will 
be broken in one more way.
  *   This will also accelerate the advancement of crypto DNS like NameCoin 
(Years ago I liked the idea but I don't know how it is being run anymore.) or 
UnstoppableDomains for example.   Similar to what is starting to happen to 
central banking as countries start shutting down bank accounts for political 
reasons.

I am glad to see soo many people on here and many of the organizations running 
these services state as much.

Brian



From: NANOG  on behalf of 
Patrick Bryant 
Sent: Saturday, March 12, 2022 2:47 AM
To: nanog@nanog.org 
Subject: Dropping support for the .ru top level domain

I don't like the idea of disrupting any Internet service. But the current 
situation is unprecedented.

The Achilles Heel of general public use of Internet services has always been 
the functionality of DNS.

Unlike Layer 3 disruptions, dropping or disrupting support for the .ru TLD can 
be accomplished without disrupting the Russian population's ability to access 
information and services in the West.

The only countermeasure would be the distribution of Russian national DNS zones 
to a multiplicity of individual DNS resolvers within Russia. Russian operators 
are in fact implementing this countermeasure, but it is a slow and arduous 
process, and it will entail many of the operational difficulties that existed 
with distributing Host files, which DNS was implemented to overcome.

The .ru TLD could be globally disrupted by dropping the .ru zone from the 13 
DNS root servers. This would be the most effective action, but would require an 
authoritative consensus. One level down in DNS delegation are the 5 
authoritative servers. I will leave it to the imagination of others to envision 
what action that could be taken there...

ru  nameserver = a.dns.ripn.net<http://a.dns.ripn.net>
ru  nameserver = b.dns.ripn.net<http://b.dns.ripn.net>
ru  nameserver = d.dns.ripn.net<http://d.dns.ripn.net>
ru  nameserver = e.dns.ripn.net<http://e.dns.ripn.net>
ru  nameserver = f.dns.ripn.net<http://f.dns.ripn.net>

The impact of any action would take time (days) to propagate.

Re: Dropping support for the .ru top level domain

[brian . johnson]

I think you need to understand that these actions will only prolong the 
situation and likely make things worse. Less info is always worse than more.

- Brian

> On Mar 15, 2022, at 4:07 AM, Patrick Bryant  wrote:
> 
> I propose dropping support of the .ru domains as an alternative to the other 
> measures discussed here, such as dropping Russian ASNs -- which would have 
> the counterproductive effect of isolating the Russian public from western 
> news sources. Blocking those ASNs would also be futile as a network defense, 
> if not implemented universally, since the bad actors in Russia usually 
> exploit proxies in other countries as pivot points for their attacks. 
> 
> Preventing the resolution of the .ru TLD would not impact the Russian 
> public's ability to resolve and access all other TLDs. As I noted, there are 
> countermeasures, including Russia standing up its own root servers, but there 
> are two challenges to countermeasure: 1) it would require modifying evey 
> hints file on every resolver within Russia and, 2) "other measures" could be 
> taken against whatever servers Russia implemented as substitutes. Dropping 
> support for the .ru TLD action may incentivize the Russian State to bifurcate 
> its national network, making it another North Korea, but that action is 
> already underway. 
> 
> Other arguments are political, and I do not presume to set international 
> political policy. I only offer a technical opinion, not a political one. The 
> legalistic arguments of maintaining treaties is negated by the current state 
> of war.
> 
> On Tue, Mar 15, 2022 at 2:29 AM Fred Baker  <mailto:fredbaker.i...@gmail.com>> wrote:
> My viewpoint, and the reason I recommended against it, is that it gives Putin 
> something he has wanted for a while, which is a Russia in which he is in 
> control of information flows. We do for him what he has wanted for perhaps 20 
> years, and come out the bad guys - “the terrible west gut us off!”.  I would 
> rather have people in Russia have information flows that have a second 
> viewpoint other than the Kremlin’s. I have no expectation that it will get 
> through uncensored, but I would rather it was not in any sense “our fault” 
> and therefore usable by Putin’s propaganda machine.
> 
> Sent from my iPad
> 
>> On Mar 14, 2022, at 2:14 PM, Brian R > <mailto:briansupp...@hotmail.com>> wrote:
>> 
>> 
>> I can understand governments wanting this to be an option but I would let 
>> them do blocking within their countries to their own people if that is their 
>> desire.  This is another pandoras box.  Its bad enough that some countries 
>> control this already to block free flow of information.
>> If global DNS is no longer trusted then many actors will start maintaining 
>> their own broken lists (intentionally or unintentionally).
>> This will not stop Russia, they will just run their own state sponsored DNS 
>> servers.  We can imagine what else might be implemented on that concept...
>> Countries or users that still want access will do the same with custom DNS 
>> servers.
>> This will take us down another path of no return as a global standard that 
>> is not political or politically controlled.
>> The belief that the internet is open and free (as much as possible) will be 
>> broken in one more way.
>> This will also accelerate the advancement of crypto DNS like NameCoin (Years 
>> ago I liked the idea but I don't know how it is being run anymore.) or 
>> UnstoppableDomains for example.   Similar to what is starting to happen to 
>> central banking as countries start shutting down bank accounts for political 
>> reasons.
>> I am glad to see soo many people on here and many of the organizations 
>> running these services state as much.
>> 
>> Brian
>> 
>> 
>> From: NANOG > <mailto:hotmail@nanog.org>> on behalf of Patrick Bryant 
>> mailto:patr...@pbryant.com>>
>> Sent: Saturday, March 12, 2022 2:47 AM
>> To: nanog@nanog.org <mailto:nanog@nanog.org> > <mailto:nanog@nanog.org>>
>> Subject: Dropping support for the .ru top level domain
>>  
>> I don't like the idea of disrupting any Internet service. But the current 
>> situation is unprecedented.
>> 
>> The Achilles Heel of general public use of Internet services has always been 
>> the functionality of DNS. 
>> 
>> Unlike Layer 3 disruptions, dropping or disrupting support for the .ru TLD 
>> can be accomplished without disrupting the Russian population's ability to 
>> access information and services in the West.
>> 
>> The only countermeasure woul

Re: "Permanent" DST

[Brian R]

Thanks for finding the clarification on this Ray.

I'm with the OP Jay that this will cause long term problems.  The 15 degrees is 
not mentioned in the document just the change from "Standard Time" to "Daylight 
Time" permanently (they probably don't even understand it is in 15 degree 
increments).  This will cause problems in systems across many sectors.  The 
entire world works on UTC + or - on a 15 degree scale.  Except now the US which 
will be 15 degree scale -15 degrees.  I doubt Canada, Central, or South 
Americas are going to follow this so the United States will always be 15 
degrees off of what is considered "Standard Time" by the world.
The better solution would be to remove DST all together and tell everyone in 
the US to start work at 07:00 and get off work at 16:00 every day.

Brian

From: NANOG  on behalf of Ray 
Van Dolson via NANOG 
Sent: Tuesday, March 15, 2022 12:26 PM
To: Mel Beckman ; Jay R. Ashworth 
Cc: nanog@nanog.org list 
Subject: RE: "Permanent" DST

I think this is essentially the bill:

https://www.congress.gov/bill/117th-congress/house-bill/69/text

Not finding anything about 15 degrees.

Ray

-Original Message-
From: NANOG  On Behalf Of Mel 
Beckman
Sent: Tuesday, March 15, 2022 12:19 PM
To: Jay R. Ashworth 
Cc: nanog@nanog.org list 
Subject: Re: "Permanent" DST

I don’t follow why cancelling DST has the effect of moving the US fifteen 
degrees to the east. Also, your subject line reads “permanent DST”, but from 
your language the bill will be permanent standard time.

I haven’t read the bill, but I’m hoping you can explain your position more 
clearly.

-mel via cell

> On Mar 15, 2022, at 3:13 PM, Jay R. Ashworth  wrote:
>
> In a unanimous vote today, the US Senate approved a bill which would
>
> 1) Cancel DST permanently, and
> 2) Move every square inch of US territory 15 degrees to the east.
>
> My opinion of this ought to be obvious from my rhetoric.  Hopefully,
> it will fail, because it's likely to be the end of rational time
> worldwide, and even if you do log in UTC, it will still make your life 
> difficult.
>
> I'm poleaxed; I can't even decide which grounds to scream about this on...
>
> Hopefully, the House or the White House will be more coherent in their
> decision on this engineering construct.
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates   
> https://urldefense.com/v3/__http://www.bcp38.info__;!!CKZwjTOV!jlq104a9OT4LH-Gk4LCElbaWSsLXzHYDHHpxEqU0OZW56655xb8Df0mA4p1wvA$
>  [bcp38[.]info]  2000 Land Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: "Permanent" DST

[brian . johnson]

So to clarify/muddy the situation further... Time zones do not fall purely on 
the 15 degree lines on a globe. As such, the location of the sun overhead is 
locality specific within a timezone.

Don’t let the enemy of done win here. ;)


> On Mar 15, 2022, at 2:44 PM, Brian R  wrote:
> 
> Thanks for finding the clarification on this Ray.
> 
> I'm with the OP Jay that this will cause long term problems.  The 15 degrees 
> is not mentioned in the document just the change from "Standard Time" to 
> "Daylight Time" permanently (they probably don't even understand it is in 15 
> degree increments).  This will cause problems in systems across many sectors. 
>  The entire world works on UTC + or - on a 15 degree scale.  Except now the 
> US which will be 15 degree scale -15 degrees.  I doubt Canada, Central, or 
> South Americas are going to follow this so the United States will always be 
> 15 degrees off of what is considered "Standard Time" by the world.
> The better solution would be to remove DST all together and tell everyone in 
> the US to start work at 07:00 and get off work at 16:00 every day.
> 
> Brian
> From: NANOG  <mailto:nanog-bounces+briansupport=hotmail@nanog.org>> on behalf of Ray 
> Van Dolson via NANOG mailto:nanog@nanog.org>>
> Sent: Tuesday, March 15, 2022 12:26 PM
> To: Mel Beckman mailto:m...@beckman.org>>; Jay R. Ashworth 
> mailto:j...@baylink.com>>
> Cc: nanog@nanog.org <mailto:nanog@nanog.org> list  <mailto:nanog@nanog.org>>
> Subject: RE: "Permanent" DST
>  
> I think this is essentially the bill:
> 
> https://www.congress.gov/bill/117th-congress/house-bill/69/text 
> <https://www.congress.gov/bill/117th-congress/house-bill/69/text>
> 
> Not finding anything about 15 degrees.
> 
> Ray
> 
> -Original Message-
> From: NANOG  <mailto:nanog-bounces+rvandolson=esri@nanog.org>> On Behalf Of Mel Beckman
> Sent: Tuesday, March 15, 2022 12:19 PM
> To: Jay R. Ashworth mailto:j...@baylink.com>>
> Cc: nanog@nanog.org <mailto:nanog@nanog.org> list  <mailto:nanog@nanog.org>>
> Subject: Re: "Permanent" DST
> 
> I don’t follow why cancelling DST has the effect of moving the US fifteen 
> degrees to the east. Also, your subject line reads “permanent DST”, but from 
> your language the bill will be permanent standard time. 
> 
> I haven’t read the bill, but I’m hoping you can explain your position more 
> clearly. 
> 
> -mel via cell
> 
> > On Mar 15, 2022, at 3:13 PM, Jay R. Ashworth  > <mailto:j...@baylink.com>> wrote:
> > 
> > In a unanimous vote today, the US Senate approved a bill which would
> > 
> > 1) Cancel DST permanently, and
> > 2) Move every square inch of US territory 15 degrees to the east.
> > 
> > My opinion of this ought to be obvious from my rhetoric.  Hopefully, 
> > it will fail, because it's likely to be the end of rational time 
> > worldwide, and even if you do log in UTC, it will still make your life 
> > difficult.
> > 
> > I'm poleaxed; I can't even decide which grounds to scream about this on...
> > 
> > Hopefully, the House or the White House will be more coherent in their 
> > decision on this engineering construct.
> > 
> > Cheers,
> > -- jra
> > 
> > -- 
> > Jay R. Ashworth  Baylink   
> > j...@baylink.com <mailto:j...@baylink.com>
> > Designer The Things I Think   RFC 
> > 2100
> > Ashworth & Associates   
> > https://urldefense.com/v3/__http://www.bcp38.info__;!!CKZwjTOV!jlq104a9OT4LH-Gk4LCElbaWSsLXzHYDHHpxEqU0OZW56655xb8Df0mA4p1wvA$
> >  
> > <https://urldefense.com/v3/__http://www.bcp38.info__;!!CKZwjTOV!jlq104a9OT4LH-Gk4LCElbaWSsLXzHYDHHpxEqU0OZW56655xb8Df0mA4p1wvA$>
> >  [bcp38[.]info]  2000 Land Rover DII
> > St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 
> > 1274

Re: Historic/Retired Routing Registry

[Brian R]

Dan,

Have you tried sending an email to Merit Network?  
r...@merit.edu<mailto:r...@merit.edu>
https://www.irr.net/docs/list.html
It seems like the kind of thing they might have legacy info on.

I did a little bit of searching and didn't come up with anything about retired 
IRRs either.

Brian


From: NANOG  on behalf of Dan 
Mahoney 
Sent: Wednesday, March 23, 2022 7:14 PM
To: nanog@nanog.org 
Subject: Historic/Retired Routing Registry

Hey there all,

I have vague memories of some group running a routing registry that was shut 
down in the late 90s/early 2000s and I could’ve sworn it was ARIN.  It might’ve 
been Internic or something like that as well.  Does anyone have any 
recollection of this?

My Google searching for “retired routing registries” or “ historic routing 
registries“ seems to fail, But the list of which were in existence at one point 
or another seems like the kind of thing I’d expect somebody to keep on a 
webpage somewhere.

Ideas?

-Dance

BGP Javascript Map/Visualization

[Brian Johnson]

Hey all,

Sorry for the noise.  Years ago someone here built and shared a javascript 
visualization of what their routers saw for the state of BGP and paths to get 
to various ASs. One could use WSAD and other keys to fly around and examine 
various other ASs.  I thought it was as2814.net, but that seems to not be a 
thing anymore.  Can someone refresh my memory where that might be?  Or did it 
get taken down?

Thanks in advance,
- brian

Re: CUPS in a BNG?

[brian . johnson]

The CUPS makes a lot of sense for this application. Latency is dependent on the 
design, and equipment used. I’ve seen/done several designs for this using two 
different vendors equipment and two different BNG software stacks.

When I do a design for BNG from scratch, this is how I do it now. :)

As always… YMMV.

- Brian

> On Mar 22, 2023, at 4:02 PM, Tom Mitchell  wrote:
> 
> Anyone have any thoughts on this CUPS thing?  I have a customer asking, but 
> it seems the lack of CP resiliency and additional latency between the DP and 
> CP make this a really dumb idea.  Has anyone tried it?  Does it make any 
> sense?
> 
> Thanks!

Re: Searchable archives of the list?

[brian . johnson]

https://www.mail-archive.com/nanog@nanog.org/

> On Mar 23, 2023, at 9:44 AM, Josh Luthman  wrote:
> 
> Google?
> 
> geolocation site:https://mailman.nanog.org/pipermail/nanog/
> 
> On Thu, Mar 23, 2023 at 10:30 AM Chris Adams  > wrote:
>> Once upon a time, Josh Luthman > > said:
>> > Why wouldn't one use the link that's provided in the message?
>> 
>> The request is right there in the Subject... "Searchable".  Traditional
>> pipermail archives have no search function, and being subdivided into
>> months makes manual searching tedious to impractical.
>> 
>> -- 
>> Chris Adams mailto:c...@cmadams.net>>

RE: Amazon Prime video NOC contact

[Brian Pierce]

Bradley & Davide,

I work for an ISP located in central Ohio and we’re experiencing the a similar 
issue with a newly acquired IP Block, it’s flagged as a VPN/Proxy.
I’ve not had any success trying their forums or trying to climb through their 
customer service ladder to hope someone knowledgeable receives my ticket.
Bradley, if you have any contact info I would greatly appreciate a message off 
list.
Davide, if you are able to resolve this issue, please advise how you were able 
to do so.

From: NANOG  On Behalf Of Bradley Burch
Sent: Wednesday, March 20, 2019 2:28 PM
To: William Herrin 
Cc: nanog@nanog.org; davide.gela...@wt-tech.it
Subject: Re: Amazon Prime video NOC contact

ATTENTION: This email came from an external source. Do not open attachments or 
click on links from unknown senders or unexpected emails.

I have had no luck from that forum.
Davide, I will contact you off list.



On Mar 20, 2019, at 2:16 PM, William Herrin 
mailto:b...@herrin.us>> wrote:
On Wed, Mar 20, 2019 at 11:03 AM Davide Gelardi 
mailto:ml-assoprovi...@wt-tech.it>> wrote:
we are an italian ISP/WISP and we are experiecing trouble with Amazon
Prime Video. They blocked our customers that cannot view the video. The
error says that our IP class is located ouside italy. But this is wrong.

Have you a contact we can get in touch with?

Hi Davide,

You may have some luck here: 
https://www.amazonforum.com/forums/digital-content/prime-video

Amazon staff working on Prime Video monitor and respond on that forum. The 
individuals reading may not be the right people, but they'll likely be on a 
first name basis with someone who is.

Regards,
Bill Herrin


--
William Herrin  her...@dirtside.com 
 b...@herrin.us
Dirtside Systems . Web: 

Re: softlayer.com

[Brian Rak]

I've been trying to reach them regarding an abuse issue, and have 
similarly had no actual luck in reaching their abuse/noc contacts.


On 3/21/2019 9:07 PM, and...@paolucci.ca wrote:
SoftLayer was aquirred by IBM, maybe reaching out to their NOC or 
support would be fruitful. IBM's DNS team is indeed mentioned in 
SoftLayers WHOIS info.


Have you attempted email the addresses listed in the WHOIS for their ASN?

network:Tech-Contact;I:sysadm...@softlayer.com  
network:Abuse-Contact;I:ab...@softlayer.com  
network:Updated-By:ipad...@softlayer.com  

*Registrant Contact*
Registrant Name
Domain Administrator
Registrant Organization
Softlayer Technologies, Inc.
Registrant Street
4849 Alpha Road
Registrant City
Dallas
Registrant State/Province
TX
Registrant Postal Code
75244
Registrant Country
USUnited States
Registrant Phone
+1.2144420600
Registrant Email
bjohn...@softlayer.com 

*Administrative Contact*
Admin Name
Grace Micewicz
Admin Organization
International Business Machines Corporation
Admin Street
New Orchard Road
Admin City
Armonk
Admin State/Province
NY
Admin Postal Code
10504
Admin Country
USUnited States
Admin Phone
+1.9147654227
Admin Fax
+1.9147654370
Admin Email
dns...@us.ibm.com 


Regards.
Andrew Paolucci



‐‐‐ Original Message ‐‐‐
On Thursday, March 21, 2019 3:39 PM, John Alcock  wrote:


Still looking for anyone from softlayer.com 

It has been a challenge.  Anything hosted by softlayer.com 
 is being blocked.


Here is a small list so far

windowbook.tpondemand.com 
ahainstructornetwork.americanheart.org 


clover.com 
Cebroker.com
Softlayer.com
indeed.com  & Enforce Staffing

It is growing every day.

John


On Wed, Mar 20, 2019 at 12:35 PM John Alcock > wrote:


Afternoon,

Thought I would start a new thread.  After researching,
traceroutes, etc, I think I found my problem.

9 out of the 10 sites that subscribers on my new block is being
hosted by softlayer.

Anyone on the list have contacts with softlayer. Right now I have
an email to abuse.  The support line will not help me out.

John

Re: NTP for ASBRs?

[Brian Kantor]

On Wed, May 08, 2019 at 07:47:56PM -0500, Bryan Holloway wrote:
> 100% true. But there is also a practical side to this ...
> 
> When a NOC-ling, in their own local timezone, says, "hey, what happened 
> two hours ago?", they have to make a calculation. And that calculation 
> annoyingly depends on the time of year in many if not most locales 
> worldwide. And to make matters worse, some folks change at different 
> times of the year, so, if you're a global network 
> 
> Hawai'i and Arizona can add/subtract without looking at the damn 
> calendar. I'm just sayin' I'd like to see more of that.

Clocks are cheap. I have two on the wall; one is local time and
the other is marked GMT.
- Brian

Re: Spamming of NANOG list members

[Brian Kantor]

Anne, the way that such addresses are often harvested is that one of
the spammers (or his agent) becomes a member of the list and simply
records the addresses of persons posting to the list.  They then
get spammed.
- Brian


On Fri, May 24, 2019 at 09:07:28AM -0600, Anne P. Mitchell, Esq. wrote:
> Question:  Is the member list with email addresses public??  Otherwise, one 
> has to wonder how they got these addresses?
> 
> Anne

Re: Spamming of NANOG list members

[Brian Kantor]

An interesting development: my posting to this list a few minutes
ago seems to have triggered an autoresponder asking me to confirm
the issuance of a support ticket by Liquid Web, whoever they are.
- Brian


> > On Fri, May 24, 2019 at 08:17:31AM -0700, Brian Kantor wrote:
> > > Anne, the way that such addresses are often harvested is that one of
> > > the spammers (or his agent) becomes a member of the list and simply
> > > records the addresses of persons posting to the list.  They then
> > > get spammed.

Re: Power cut if temps are too high

[Brian Kantor]

A simple air conditioner thermostat wired to the EPO switch.
For safety, wire two thermostats in series so BOTH have to trip
before power is shut off.

Note that the EPO rarely does an orderly shutdown, but then this
is a sort of an emergency.
- Brian


On Mon, May 27, 2019 at 02:00:39PM -0400, Dovid Bender wrote:
> Hi,
> 
> Is anyone aware of a device that will cut the power if the room goes above X
> degrees? I am looking for something as a just in case. 
> 
> 
> Regards,
> 
> Dovid
> 

Re: Power cut if temps are too high

[Brian Kantor]

I was assuming the EPO trigger is a circuit that is normally OPEN
and is closed when the button is pushed.

If instead, it is a normally-CLOSED circuit, then you are correct,
you would want two thermostats that both OPENED when the temperature
rose, which would typically be HEATING thermostats, not AIR CONDITIONING
thermostats.

Either method could have been installed; in the computer room I
worked in, the EPO was a normally-open circuit that closed when you
hit any one of the buttons placed around the room and at the exits.

Or indeed, if the fire suppression system triggered.
- Brian

On Mon, May 27, 2019 at 06:10:49PM -0400, Brandon Ross wrote:
> On Mon, 27 May 2019, Brian Kantor wrote:
> 
> > A simple air conditioner thermostat wired to the EPO switch.
> > For safety, wire two thermostats in series so BOTH have to trip
> > before power is shut off.
> 
> Admittedly it's been a long time since I worked with basic circuitry, but 
> wouldn't wiring them in series cause the circuit to be interrupted if 
> EITHER thermostat tripped?
> 
> -- 
> Brandon RossYahoo:  BrandonNRoss
> Voice:  +1-404-635-6667ICQ:  2269442
> Signal Secure SMS, Viber, Whatsapp:  +1-404-644-9628 Skype:  brandonross
> Schedule a meeting:  http://www.doodle.com/bross

Re: Bgpmon alternatives?

[Brian Kantor]

On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote:
> As a beta service you can try out rt-bgp.he.net.  This is a real time
> bgp monitoring service we are developing.

It's interesting, but I don't see any way to do what I primarily
use the existing BGPMon for: watch for hijacks.

That is, set up one or more prefixes to be continuously monitored
and have the monitor send me an email alert when that prefix or a
subnet of it begins to be announced by someone new.

For example, if I have told it to monitor 44.0.0.0/8 and someone
somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very
much like to know about that, along with details of who and where.

Then if that announcement is authorized, I can tell the monitoring
service that this new entry is NOT a hijack, and it won't bug me
about it again.

Can it be persuaded to do this?
- Brian

Re: Bgpmon alternatives?

[Brian Kantor]

That would be wonderful.  Thank you!
- Brian


On Sun, Jun 16, 2019 at 03:59:29AM -0700, Mike Leber wrote:
> I'm sure if it doesn't do exactly that already, we can add it shortly.
> 
> Some of planned functionality for hijack detection is already live. 
> That's one of the main reasons for creating this service.
> 
> Mike.
> 
> On 6/16/19 2:48 AM, Brian Kantor wrote:
> > On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote:
> >> As a beta service you can try out rt-bgp.he.net.  This is a real time
> >> bgp monitoring service we are developing.
> > It's interesting, but I don't see any way to do what I primarily
> > use the existing BGPMon for: watch for hijacks.
> >
> > That is, set up one or more prefixes to be continuously monitored
> > and have the monitor send me an email alert when that prefix or a
> > subnet of it begins to be announced by someone new.
> >
> > For example, if I have told it to monitor 44.0.0.0/8 and someone
> > somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very
> > much like to know about that, along with details of who and where.
> >
> > Then if that announcement is authorized, I can tell the monitoring
> > service that this new entry is NOT a hijack, and it won't bug me
> > about it again.
> >
> > Can it be persuaded to do this?
> > - Brian

RE: Traffic ratio of an ISP

[Knopps, Brian]

[cid:image001.png@01D526B7.B99D6BB0]

From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Josh Luthman
Sent: Wednesday, June 19, 2019 3:24 PM
To: Prasun Dey
Cc: nanog@nanog.org
Subject: Re: Traffic ratio of an ISP

>my question was more like to understand when an ISP decides to claim itself as 
>any of these (Heavy Outbound/ Inbound or Balanced)

Maybe I'm missing something but it's as simple as looking at the interface 
graphs.  We see a whole lot of green for inbound and a little little blue line 
for outbound.  We are an ISP with residential and commercial customers.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey 
mailto:pra...@nevada.unr.edu>> wrote:
Hi Martijn and Josh,
Thank you for your detailed explanation. Let me explain my requirement so that 
you may help me better.
According to PeeringDB, Charter (Access), Sprint (Transit), Amazon (Content) 
all three of them are ‘Balanced’. While, Cable One, an Access ISP says it is 
Heavy Inbound, while Akamai, Netflix (Content) are Heavy Outbound. On the other 
hand, Cox, another access ISP, it says that it is Mostly Inbound.
So, my question was more like to understand when an ISP decides to claim itself 
as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point 
of view, at what point, it says, my outbound:inbound is something, so I’m Heavy 
Outbound.
Please ignore my lack of knowledge in this area. I’m sorry I should’ve done a 
better job in formulating my question earlier.
Thank you.

-
Prasun

Regards,
Prasun Kanti Dey
Ph.D. Candidate,
Dept of Electrical and Computer Engineering,
University of Central Florida
web: https://prasunkantidey.github.io/portfolio/






On Jun 19, 2019, at 2:13 PM, i3D.net - Martijn Schmidt 
mailto:martijnschm...@i3d.net>> wrote:

It kinda depends on the application that's being used. For example, videogaming 
has a ratio somewhere around 1:2.5 since you're only transmitting metadata 
about the players environment across the wire. The actual video is typically 
rendered at the end user's side. So it's not very bandwidth heavy.

Compare that with a videostream (watching a movie or TV series) and you're 
pumping the rendered video across the wire, so there's a very different ratio. 
Your return path traffic would pretty much consist of control stuff only (like 
pushing the pause button).

Some networks are dedicated to serving one type of content, whereas others 
might have a blend of different kinds of content. Same story for an access 
network geared to business users which want to use emails and such, vs 
residential end users looking for the evening's entertainment.

Best regards,
Martijn
On 19 June 2019 19:54:45 CEST, Josh Luthman 
mailto:j...@imaginenetworksllc.com>> wrote:
If you're asking an ISP, consumers will always be inbound.  It's the end user.  
The outbound would be where the information is coming from, like data centers.

I'm not sure you're going to get any better answer without a more specific 
question.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey 
mailto:pra...@nevada.unr.edu>> wrote:
Hello,
Good morning.
I’m a Ph.D. candidate from University of Central Florida. I have a query, I 
hope you can help me with it or at least point me to the right direction.
I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ 
Mostly Inbound or Balanced or Heavy/ Mostly Outbound.
I’m wondering if there is any specific ratio numbers for them. In Norton’s 
Internet Peering Playbook or some other literary work, they mention the 
outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I 
couldn’t find the other values.
I’d really appreciate your help if you can please mention what Outbound:Inbound 
ratios that network admins use frequently to represent their traffic ratios for
1. Heavy Inbound:
2. Mostly Inbound:
3. Mostly Outbound:
4. Heavy Outbound:

Thank you.
-
Prasun
--
Sincerely,
Prasun Kanti Dey,
Ph.D. candidate,
Dept. of Electrical and Computer Engineering,
University of Central Florida.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Microsoft SNDS contact

[Brian Rak]

We've been trying to get SNDS access for our IP space, and we keep 
running into issues where the SNDS site is unable to determine what 
emails it should use to authorize access.  SNDS support has so far been 
very unhelpful, they keep trying to tell us to submit the space as 
individual /24's, which is less then helpful when we have multiple /18s 
we're trying to set up.


Does anyone have a contact at Microsoft that can help?

Re: [EXTERNAL] Re: Microsoft SNDS contact

[Brian Rak]

On 7/3/2019 10:09 AM, Hansen, Christoffer wrote:

On 03/07/2019 15:50, Hansen, Christoffer wrote:

https://sendersupport.olc.protection.outlook.com/snds/addnetwork.aspx

E.g. with asn 20473. Key that in. I can select the address fetched from
a background WHOIS lookup by MS Smart Network Data Service. For the
confirmation email to be sent to.



We've tried this approach in the past, but it ends up dragging in a lot 
of IP space that we're announcing on behalf of customers. This is less 
then ideal, as then we either have to go back and manually remove all 
the customer owned IP space, or deal with a bunch of noise from it.  
We'd be willing to accept that as a solution if it were a one-off thing, 
but it's a lot of extra work to do every time we acquire more IP space.

Re: [EXTERNAL] Re: Microsoft SNDS contact

[Brian Rak]

Yea, that's the email we've been using (that's trying to tell us to just 
split it into /24s)


On 7/3/2019 10:27 AM, Udeme Ukutt wrote:
Hey Brian - try msn-s...@microsoft.com 
<mailto:msn-s...@microsoft.com>. IIRC that's more geared towards JMRP, 
but I think there's a chance.


Udeme
Postmaster at Wish

On Wed, Jul 3, 2019 at 10:14 AM Brian Rak <mailto:b...@gameservers.com>> wrote:



On 7/3/2019 10:09 AM, Hansen, Christoffer wrote:
> On 03/07/2019 15:50, Hansen, Christoffer wrote:
>>
https://sendersupport.olc.protection.outlook.com/snds/addnetwork.aspx
> E.g. with asn 20473. Key that in. I can select the address
fetched from
> a background WHOIS lookup by MS Smart Network Data Service. For the
> confirmation email to be sent to.
>

We've tried this approach in the past, but it ends up dragging in
a lot
of IP space that we're announcing on behalf of customers. This is
less
then ideal, as then we either have to go back and manually remove all
the customer owned IP space, or deal with a bunch of noise from it.
We'd be willing to accept that as a solution if it were a one-off
thing,
but it's a lot of extra work to do every time we acquire more IP
space.

Re: QoS for Office365

[Brian Knight]

> On Jul 9, 2019, at 9:19 AM, Mark Tinka  wrote:
> 
> 
> 
>> On 9/Jul/19 16:18, Ross Tajvar wrote:
>> I think the difficulty lies in appropriately marking the traffic. Like
>> Joe said, the IPs are always changing.
> 
> Does anyone know if they are reasonably static in an Express Route scenario?
> 
> Mark.

Yes, the IPs used on the ExpressRoute connection are whatever is chosen for the 
internal IP scheme of the VPC. ExpressRoute is a VPN connection into that 
internal side of a VPC.  On our carrier (MegaPort), ExpressRoute looks similar 
to an Option A NNI connection. BGP is used for routing.

The source IPs on packets crossing out of the VPC onto the Azure-provided 
Internet may or may not be static, but internally they are usually static RFC 
1918 addresses.

We’ve been using ExpressRoute for our own office systems and a small handful of 
customers for about two years now. However, we don’t use diffserv on 
ExpressRoute, so can’t comment on that.

-Brian

Re: 44.192.0.0/10 sale

[Brian Kantor]

Because questions have arisen here that are well answered by
a short series of postings from the 44net mailing list, at the
request of the author [Phil Karn] and others, I am reposting
them here.
- Brian


From: Phil Karn 
Subject: [44net] 44.192.0.0/10 sale

Hello all,

I've not been active here, but some of you may remember me as the guy
who first got TCP/IP going on amateur packet radio way back in 1986. At
one time, my name was registered as the owner of the block. This makes
me one of a VERY small group of people with any arguable personal
property interest in network 44. And yes, 25% of this space, which is
VERY unlikely to ever be used by hams, has been sold to Amazon.

Rather than try to personally profit from this, we all readily agreed to
place the *entire* proceeds of this sale into a 501(c)(3) charity
chartered to support amateur digital radio and related developments. No
one is buying a yacht or a mansion. As a tax-exempt charity, our tax
returns and related documents will be publicly available so you can see
what is being done. Like the rest of the amateur community, all of you
will have the opportunity to apply for grants and do good things for
amateur radio with them.

73, Phil

_


On 7/18/19 21:25, Gavin Rogers wrote:
> On 19/07/2019 12:19 pm, Phil Karn wrote:
>> Like the rest of the amateur community, all of you
>> will have the opportunity to apply for grants and do good things for
>> amateur radio with them.
> I don't know much about US-registered charities and tax law, but will
> this include amateurs and clubs located outside of the US? 

Sure. We'd like to cast the net as widely as possible for worthy grant
recipients. Doesn't matter where they are in the world, as long as the
purpose is consistent with our charter, which is to benefit amateur
digital radio and related development. That's a worldwide activity.

I suppose US legal restrictions on dealing with certain "pariah"
countries might come into play (e.g., North Korea) but that's a very
short list and there isn't much ham radio in them anyway.

We're already thinking about things like:

Educational grants to students who are hams;

Existing amateur radio 501(c)(3) organizations;

Development of *freely available* technology: hardware, software,
protocols, etc

Field trials, demonstrations, pilot projects, educational outreach, etc;

This list is NOT exhaustive by any means, and in fact we'll be looking
for good ideas from anyone who has them. We want to be as transparent
about this as possible.

Again, though we might have been able to establish a *personal* property
claim over network 44, we all quickly decided to not open that can of
worms and instead sign everything over to the ARDC. Face it, given who
we are we'd probably just spend the money on ham radio development
ourselves. This is a much better way to do it.

73, Phil

_

On 7/18/19 21:38, David Ranch wrote:
>
> Wow!  This is rather big news but has also been VERY opaque to the
> AMPR community.  I'm also surprised that the sale has already occurred
> and not auctioned off to say the highest bidder?  Since ARDC is a
> corporation, when will we learn about the sale price and how this
> money will be *really* spent?
>
> The bottom of https://www.ampr.org/amprnet/ does cover a little of
> this but it's all too vague for my tastes. 


I didn't like the secrecy either, but it was necessary given the nature
of the process. We are precluded by the terms of the sale from giving
precise figures at this time, but suffice it to say that we (Brian,
actually) worked *very* hard to get the best possible price. I am fully
satisfied that he did. Everyone with any arguable legal property
interest in 44/8 was fully informed and consented to give up that
interest and have it benefit ham radio instead. I didn't even think
twice about it.

Remember, this is an IRS 501(c)(3) charity, which means there are strict
rules on transparency, how money can be spent and how it must be
accounted for. Tax returns and other documents are public information.

One of the most important rules for a non-profit, which the IRS takes
pretty seriously, is a prohibition on "self dealing". This is how Donald
Trump's personal charity got shut down.

73, Phil

_

On 7/18/19 22:08, David Ranch wrote:
>
>> I have so many words for the conspiracy theorists and negative
>> naysayers,
>> but Ill hold that back and not contribute to the shitstorm.
>
> My main concern is what will stop the ARDC board from selling the next
> 25% or 50% of 44 space?

The fact that, unlike 44.192.0.0/10, it's being used by hams?

I personally approved the sale on two conditions:

1) The block wasn't being used by hams and had 

Re: OT: Tech bag

[Brian Knight]

About a year ago, I switched from a Swissgear to a High Sierra Endeavor wheeled 
backpack and been very happy with it. Most of the time I carry < 15 lbs of gear 
when I commute to the office on the train, so I’ll have it on my back. But when 
I head to the colo with a heavy load, it’s handy (and a real relief to my neck 
and shoulders) to be able to switch to wheeled mode. It’s held an ASR920 + 
laptop + hardware + usual load with a bit of room to spare.

HTH,

-Brian

> On Aug 2, 2019, at 11:14 AM, Dovid Bender  wrote:
> 
> Hi,
> 
> Sorry for the OT email. I travel extensively to DC's and my computer bag 
> seems to keep collecting more tools which includes your usual console cables, 
> spare everything, two laptops etc. My Swissgear has been taking a beating and 
> I was wondering what others who have to lug around 30-35 pounds use.
> 
> TIA.
> 
>  

Re: Best ways to ensure redundancy with no terrestrial ISPs

[Brian Henson]

If we had a location (or at least a part of the world) we might be able to
recommend a little better.

On Sat, Aug 3, 2019 at 3:32 PM Ross Tajvar  wrote:

> Hi all,
>
> A friend of mine is trying to set up a network in a location where there
> is no fiber (or copper) for many miles. As bandwidth requirements are low
> (<1M for the foreseeable future) but uptime is important, he was looking at
> using multiple cell modems from separate carriers as redundant uplinks. I
> am concerned that different cell carriers might be using the same transport
> providers to a given tower, so that wouldn't be truly redundant. Another
> option would be using a satellite provider as a backup for cellular. (The
> high latency that comes with satellite is not an issue.)
>
> A fixed-radio solution would likely be too expensive upfront as it would
> require building towers.
>
> Am I missing any other options or considerations?
>
> Thanks,
> Ross
>

Salliemae.com

[Brian Ellwood]

Any domain/DNS administrators for Salliemae on the list that could contact me 
directly or perhaps take a look at the DNSSEC implementation on the domain?

Resolvers validating DNSSEC are unable to resolve the domain:

http://dnsviz.net/d/salliemae.com/dnssec/

—
Brian Ellwood
Senior Systems Engineer
INOC Data Centers
O: 518-689-4350


smime.p7s
Description: S/MIME cryptographic signature