Re: Help with removing DNS shinkhole FP from Charter/Spectrum

[Christopher Morrow]

“We checked the website you are trying to access for malicious and
spear-phishing content and found it likely to be unsafe.”

perhaps charter thinks there's a reason to not permit folks to access
a possibly dangerous site?
(it's also possible it just got cough up amongst some other stuff in
the hosting provider's space, nothing jumps out in passive-dns
lokoups.)

On Mon, Apr 22, 2024 at 7:39 PM William Herrin  wrote:
>
> On Mon, Apr 22, 2024 at 4:00 PM John Levine  wrote:
> > It appears that William Herrin  said:
> > >If you can't reach a technical POC, use the legal one. Your lawyer can
>
> > The only response to a letter like that is "we run our network to
> > serve our customers and manage it the way we think is best" and you
> > know what, they're right.
>
> Hi John,
>
> Respectfully, you're mistaken. Look up "tortious interference."
>
> Operators have considerable legal leeway to block traffic for cause,
> or even by mistake if corrected upon notification, but a lawyer who
> blows off a cease-and-desist letter without investigating it with the
> tech staff has committed malpractice. The lawyer doesn't want to
> commit malpractice. You write the lawyer via certified mail, he's
> going to talk to the tech staff and you're going to get a response. At
> that point, you have an open communication pathway to get things
> fixed. Which was the problem to be solved.
>
>
> > Having said that, I suspect the least bad alternative if you can't
> > find an out of band contact is to get some of the Spectrum customers
> > who can't reach you to complain. They're customers, you aren't.
>
> My results going through the support front-door at large companies for
> oddball problems have been less than stellar. Has your experience
> truly been different?
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: IPv6 connectivity to mx[1-4].smtp.goog.

[Christopher Morrow]

On Tue, Feb 27, 2024 at 12:03 PM 푀풶퓇풸표 풟풶퓋풾풹퓈 via NANOG
 wrote:
>
> Op 27-02-24 om 16:22 schreef Brotman, Alex:
>
> > We are seeing the same,
>
> Thanks.
>
> > You may also want to ask the mailop list.
>
>
> I was about to do that, when I noticed that the problem seems solved.

sorry about the noise.

Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers

[Christopher Morrow]

On Mon, Jan 22, 2024 at 1:27 PM Owen DeLong  wrote:
>
>
>
> On Jan 21, 2024, at 16:10, Christopher Morrow  wrote:
>
> 
>
>
> On Sun, Jan 21, 2024, 5:39 PM Owen DeLong  wrote:
>>
>>
>>
>> On Jan 21, 2024, at 12:07, Christopher Morrow  
>> wrote:
>>
>> 
>>
>>
>> On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG  wrote:
>>>
>>> Sounds like you’ve got a weird mix of route origination. Why wouldn’t you 
>>> advertise to Google via BGP and have your prefix originate from your own 
>>> ASN?
>>
>>
>>
>> I think in this case the customer has their own disconnected deployment, and 
>> they are asking 396982 to announce some subset of their prefixes such that 
>> gcp gets that traffic.
>>
>>
>> If that’s the case, IMHO, the better solution is to obtain a second ASN and 
>> announce that to GCP. Create ROAs (if you want to use RPKI) accordingly.
>
>
> That's not the product today, and really this is all accomplished with cloud 
> goop inside gcp. (aws and azure have similar offerings, I believe)
>
>
> Interesting. It’s what several of my consulting clients are doing. They 
> simply treat the cloud provider as an upstream peer on their cloud virtual 
> router and bgp as normal (ish, those cloud virtual routers are pretty 
> strange).
>

yes the 'cloud router' things are strange, and odd and 'not the same'
across various product/providers.
I know that some offerings permit a more 'direct control' of the bgp
conversation betewen customer and cloud provider and internet,
but that's not a universal thing :( Sometimes because 'bgp is hard', I
imagine the product thought process went.

Re: Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers

[Christopher Morrow]

On Mon, Jan 22, 2024 at 7:39 AM kubanowy  wrote:
> On Jan 19, 2024, at 02:39, kubanowy  wrote:
>
> Hi,
> We have our own prefix assignment from ARIN. We have our infrastructure in 
> GCP (Google Cloud Platform) where we started using BYOIP functionality 
> (Google advertises our IPs). We followed their recommendation with ROA 
> configuration in ARIN 
> https://cloud.google.com/vpc/docs/bring-your-own-ip#live-migration-recommendations
>  but they don't mention if IRR (whois database) should be updated as
>
>
> The roa is really for two reasons:
>
>   1) tell Google you actually control that asset.
>   2) tell the world that 396982 is permitted to originate that prefix.
>
> Use of irr data is nice, but not required here...
>
>
> This is understood, however due to missing entries in IRR those tools flag 
> those prefixes as suspicious to mismatch between what's advertised and what's 
> in ARIN database. My goal is to avoid it.
>
> I'm looking for information on what's community approach for this. How this 
> should be handled?
>
> well. I've checked with their support and they said no additional changes 
> need to be done there.
> But currently we are in situation where ARIN's whois contains entry for our 
> prefix with our own ASN and Google advertised to RADb entry for our prefixes 
> with their own ASN.
>
>
> I don't believe to robots at google are supposed to register irr data for 
> byoip customers... Can you mail me off list and I can go do a.little digging? 
> ;)
>

correction: yes the robot will make IRR entries on behalf of the byoip
custromer... I should have remembered this, but oops :)

>
> I haven't seen info on that in their documentation, but we did notice a new 
> entry in RADb for prefix that we added in GCP that had MAINT set to Google.
>

I believe(based on the source code) google will add this shortly after
the customer processes start, and remove it automatically when the
customer goes away.

>
> When we use online tools like https://irrexplorer.nlnog.net/ or Cisco's 
> CrossWork Cloud (former BGPmon), they mark our prefixes due to mismatch of 
> ASN in those 2 databases.

do you have an example you can share?

> We haven't observed any routing issues so far (i.e. ISP not importing our 
> prefixes), but we aim to sort this out for better credibility. I'm wondering 
> what's community approach for updating whois databases when using BYOIP 
> functionality with Cloud providers and if there is a risk of any potential 
> impact if we were to change information in ARIN.
> Thanks
>
>

Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers

[Christopher Morrow]

On Sun, Jan 21, 2024, 5:39 PM Owen DeLong  wrote:

>
>
> On Jan 21, 2024, at 12:07, Christopher Morrow 
> wrote:
>
> 
>
>
> On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG 
> wrote:
>
>> Sounds like you’ve got a weird mix of route origination. Why wouldn’t you
>> advertise to Google via BGP and have your prefix originate from your own
>> ASN?
>>
>
>
> I think in this case the customer has their own disconnected deployment,
> and they are asking 396982 to announce some subset of their prefixes such
> that gcp gets that traffic.
>
>
> If that’s the case, IMHO, the better solution is to obtain a second ASN
> and announce that to GCP. Create ROAs (if you want to use RPKI)
> accordingly.
>

That's not the product today, and really this is all accomplished with
cloud goop inside gcp. (aws and azure have similar offerings, I believe)


> Having Google originate prefixes on your behalf that are a subset of what
> you are announcing is just asking for difficulties you don’t need.
>

There's a set of reasons folks choose the byoip path, I don't claim to
understand them, but in the end if they want to move ipx from asn-y to
asn-z  some form of this operation happens.

The docs and such for the cloud providers should be clear on steps, goals,
problems, etc.



> Owen
>
>

Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers

[Christopher Morrow]

On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG  wrote:

> Sounds like you’ve got a weird mix of route origination. Why wouldn’t you
> advertise to Google via BGP and have your prefix originate from your own
> ASN?
>


I think in this case the customer has their own disconnected deployment,
and they are asking 396982 to announce some subset of their prefixes such
that gcp gets that traffic.



> Owen
>
>
> On Jan 19, 2024, at 02:39, kubanowy  wrote:
>
> Hi,
> We have our own prefix assignment from ARIN. We have our infrastructure in
> GCP (Google Cloud Platform) where we started using BYOIP functionality
> (Google advertises our IPs). We followed their recommendation with ROA
> configuration in ARIN
> https://cloud.google.com/vpc/docs/bring-your-own-ip#live-migration-recommendations
>  but they don't mention if IRR (whois database) should be updated as
>
>
The roa is really for two reasons:

  1) tell Google you actually control that asset.
  2) tell the world that 396982 is permitted to originate that prefix.

Use of irr data is nice, but not required here...

well. I've checked with their support and they said no additional changes
> need to be done there.
> But currently we are in situation where ARIN's whois contains entry for
> our prefix with our own ASN and Google advertised to RADb entry for our
> prefixes with their own ASN.
>
>
I don't believe to robots at google are supposed to register irr data for
byoip customers... Can you mail me off list and I can go do a.little
digging? ;)


When we use online tools like https://irrexplorer.nlnog.net/ or Cisco's
> CrossWork Cloud (former BGPmon), they mark our prefixes due to mismatch of
> ASN in those 2 databases.
> We haven't observed any routing issues so far (i.e. ISP not importing our
> prefixes), but we aim to sort this out for better credibility. I'm
> wondering what's community approach for updating whois databases when using
> BYOIP functionality with Cloud providers and if there is a risk of any
> potential impact if we were to change information in ARIN.
> Thanks
>
>
>

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Christopher Morrow]

Why is this conversation even still going on?
It's been established ~100 messages ago that the plan here is nonsense.
it's been established ~80 messages ago that the 'lemme swap subjects to
confuse the issue' is nonsense.

stop feeding the troll.

On Thu, Jan 18, 2024 at 11:20 PM Christopher Hawker 
wrote:

> According to the diagram on page 8 of the presentation on your website at
> https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf, it simply
> identifies 240/4 as CGNAT space. Routing between regional access networks
> typically doesn't take place when using such space on an ISP network, and
> most ISPs (that I know of) will offer public addressing when it is
> required. Further, if you think the need for DHCP will be eliminated
> through the use of your solution, I hate to say it, but ISPs will not
> statically configure WAN addressing on CPE for residential services. It
> would simply increase the workload of their support and provisioning teams.
> Right now, in cases where ISPs use DHCP, they can simply ship a router to
> an end-user, the user plugs it in, turns it on, and away they go.
> Connectivity to the internet.
>
> If an end-user has a router that does not support OpenWRT, it will require
> the end-user to replace their router with one that does in order to connect
> to an EzIP-enabled network. This is not reasonably practical. This would
> also require router vendors to support connectivity to a proprietary
> "semi-public router".
>
> Again, for the sake of completeness, this solution is a waste of time and
> resources. A carrier would not have a need for more than ~4.1m devices on a
> single regional access network and some may run more than one in a single
> region, so as not to put all of their proverbial eggs into the same basket.
>
> Regards,
> Christopher Hawker
>
> On Fri, 19 Jan 2024 at 14:49, Abraham Y. Chen  wrote:
>
>> Hi, Christopher:
>>
>> 1)" If "EzIP" is about using 240/4 as CGNAT space, ...   ":
>>
>> This correlation is just the starting point for EzIP deployment, so
>> that it would not be regarded as a base-less crazy dream. Once a 240/4
>> enabled RAN is established as a new network overlaying on the CG-NAT
>> infrastructure, the benefits of making use of the 240/4 resources can begin
>> to be considered. For example, with sufficient addresses, static address
>> administration can be practiced within a RAN which will remove the need for
>> DHCP service. From this, related consequences may be discussed.
>>
>> 2)" I don't think you quite grasp the concept that OpenWRT is not
>> compatible with devices that do not support it.  it would not be
>> appropriate to expect every device vendor to support it.  ...   ":
>>
>> Perhaps we have some offset about the terminology of "who supports
>> whom?" My understanding of the OpenWrt project is that it is an open-source
>> program code that supports a long list (but not all) of primarily
>> commercial RGs (Residential/Routing Gateways) and WiFi routers that serve /
>> support CPE devices (on-premises IoTs). Its basic purpose is to let private
>> network owners to replace the firmware code in the RGs with the OpenWrt
>> equivalent so that they will have full control of their RGs and then modify
>> them if desired. Thus, the basic release of each OpenWrt code maintains
>> most of the original functionalities in the OEM device. So, neither the
>> original RG nor any IoT manufacturers need be involved with the OpenWrt,
>> let alone supporting it. My reference to its V19.07.3 was the version that
>> expanded its usable address pool to include 240/4. That was all.
>>
>> For sure, OpenWrt does not run on all RGs in the field. But, this
>> does not restrict an overlay network like RAN from starting to network only
>> those premises with RGs that run on OpenWrt (plus those RGs compatible with
>> 240/4 from the factories). Since the existing CG-NAT is not disturbed and
>> daily Internet services are going normally, RAN growth can take its time.
>> 3)" You've provided a link to a D-Link managed switch, not a router.
>> Just because it can support L2 routing, doesn't make it a router.   ":
>>
>> Correct, this is just a basic example for networking the RGs to
>> experiment the RAN configuration. It is not intended to be a full-fledged
>> router which will have other considerations that are way beyond what EzIP
>> should be involved with.
>>
>>
>> Regards,
>>
>>
>> Abe (2024-01-18 22:48)
>>
>>
>> On 2024-01-15 18:33, Christopher Hawker wrote:
>>
>> If "EzIP" is about using 240/4 as CGNAT space, let's call it what it is,
>> not rename something that already exists and attempt to claim it as a new
>> idea.
>>
>> It is completely unnecessary to use 240/4 as CGNAT space. Here are a few
>> reasons why:
>>
>>1. There are 4,194,304 IPv4 addresses in a /10 prefix. Allowing for a
>>/24 from this to be used for CGNAT gateways, load balancing, etc. this
>>still allows for 4,194,048 usable addresses for 

Re: Any comprehensive listing of where Google's IPs originate from?

[Christopher Morrow]

On Tue, Dec 5, 2023 at 5:09 PM Tom Beecher  wrote:
>>
>> i would expect that google announces the /16 at least from 'everywhere', yes.
>
>
> I see the specific /18s Drew asked about initially. Didn't check for the 
> covering /16.
>

sure, good enough :) (I have not looked at our config in a bit to be sure)

> On Tue, Dec 5, 2023 at 1:29 PM Christopher Morrow  
> wrote:
>>
>> On Tue, Dec 5, 2023 at 11:06 AM Tom Beecher  wrote:
>> >
>> > From my observations, all us-east-5 IPs are announced via transit and 
>> > peering at all of my locations Chicago and east.
>> >
>>
>> i would expect that google announces the /16 at least from 'everywhere', yes.
>>
>> > On Mon, Dec 4, 2023 at 9:11 AM Drew Weaver  wrote:
>> >>
>> >> Hello,
>> >>
>> >>
>> >>
>> >> We are trying to reduce latency to a region in Google Cloud which we are 
>> >> in the same city of. Latency is currently about 22ms rt for the traffic 
>> >> to go 9 miles.
>> >>
>> >>
>> >>
>> >> I am having the hardest time finding any comprehensive list of what 
>> >> exchanges, transit, etc their IP addresses are being announced over.
>> >>
>>
>> 100% chance the best option is peeringdb (I'm betting closest to
>> drew is chicago-land-ix-ville)
>>
>> >>
>> >>
>> >> Specifically trying to get closer to addresses in these prefixes:
>> >>
>> >>
>> >>
>> >> 34.162.192.0/18
>> >>
>> >> 34.162.64.0/18
>> >>
>> >>
>> >>
>> >> Any info is greatly appreciated.
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> -Drew
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>

Re: What are these Google IPs hammering on my DNS server?

[Christopher Morrow]

On Tue, Dec 5, 2023 at 10:17 AM Ray Bellis  wrote:
>
>
>
> On 05/12/2023 12:29, Michael Hare via NANOG wrote:
>
> > At quick glance following the ISC link I didn’t see the compute
> > infrastructure [core count] needed to get 1Mpps.  There is an obvious
> > difference between 99% load of ~500rps and 1M, so we can maybe advise to
> > not undersize ADNS if that's an issue.
>
> The system under test in ISC's perflab is a 12-core Dell R430 of 2016
> vintage.

is the test framework documented where others could setup/run the
test(s)? :) (perhaps for mr hare I mean, or me! :) )
Are the tests for authoritative or cache resolvers?

-chris

Re: Any comprehensive listing of where Google's IPs originate from?

[Christopher Morrow]

On Tue, Dec 5, 2023 at 11:06 AM Tom Beecher  wrote:
>
> From my observations, all us-east-5 IPs are announced via transit and peering 
> at all of my locations Chicago and east.
>

i would expect that google announces the /16 at least from 'everywhere', yes.

> On Mon, Dec 4, 2023 at 9:11 AM Drew Weaver  wrote:
>>
>> Hello,
>>
>>
>>
>> We are trying to reduce latency to a region in Google Cloud which we are in 
>> the same city of. Latency is currently about 22ms rt for the traffic to go 9 
>> miles.
>>
>>
>>
>> I am having the hardest time finding any comprehensive list of what 
>> exchanges, transit, etc their IP addresses are being announced over.
>>

100% chance the best option is peeringdb (I'm betting closest to
drew is chicago-land-ix-ville)

>>
>>
>> Specifically trying to get closer to addresses in these prefixes:
>>
>>
>>
>> 34.162.192.0/18
>>
>> 34.162.64.0/18
>>
>>
>>
>> Any info is greatly appreciated.
>>
>>
>>
>> Thanks,
>>
>> -Drew
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

Re: Any comprehensive listing of where Google's IPs originate from?

[Christopher Morrow]

note an entirely helpful answer, but google does publish:
  https://www.gstatic.com/ipranges/cloud.json - where isp live in
'google cloud' (mostly where they live)
  https://www.gstatic.com/ipranges/goog.json - prefixes announced

maybe 'where' was not 'location' but 'origination by as15169 and it's
client networks' though?

On Mon, Dec 4, 2023 at 9:33 PM Crist Clark  wrote:
>
> https://www.peeringdb.com/asn/15169
>
> https://bgp.he.net/AS15169
>
> Your providers,’ peers,’ or other upstreams’ looking glass services.
>
>
> On Mon, Dec 4, 2023 at 12:08 PM Hank Nussbacher  wrote:
>>
>> On 04/12/2023 16:09, Drew Weaver wrote:
>>
>> Although not an answer to your specific question, when I need to reduce
>> latency to a Google cloud region I use:
>> https://gcping.com/
>>
>> Regards,
>> Hank
>>
>> > Hello,
>> >
>> > We are trying to reduce latency to a region in Google Cloud which we
>> > are in the same city of. Latency is currently about 22ms rt for the
>> > traffic to go 9 miles.
>> >
>> > I am having the hardest time finding any comprehensive list of what
>> > exchanges, transit, etc their IP addresses are being announced over.
>> >
>> > Specifically trying to get closer to addresses in these prefixes:
>> >
>> > 34.162.192.0/18
>> >
>> > 34.162.64.0/18
>> >
>> > Any info is greatly appreciated.
>> >
>> > Thanks,
>> >
>> > -Drew
>> >
>>

Re: Generally accepted BGP acceptance criteria?

[Christopher Morrow]

> On Thu, Nov 16, 2023 at 9:31 PM Tom Samplonius  wrote:

>>   The most surprising thing in the DE-DIX flow chart, was that they check 
>> that the origin AS exists in the IRR as-set, before doing RPKI, and if the 
>> set existence fails, they reject the route.  I don’t see a problem with 
>> this, as maintaining as-sets is easy, but it does prevent an eventual 100% 
>> RPKI future with no IRR at all.

I don't think the future is ever really 'no irr'.
  * RPKI provides: "a cryptographically verifiable method to determine
authority to use ip number resources"
  * OriginValidation provides: "A route origin authorization
'database' for use eventually on BGP speakers"

IRR filters provide control over whom is provided reachability through
a particular peering/path.
(dale points this out as well, particularly the part about paths he points out)

Re: Your Input Needed: Can ROA Replace LOA? – Short Survey (7 mins)

[Christopher Morrow]

On Thu, Nov 16, 2023 at 10:22 AM Tom Beecher  wrote:
>>
>> In the service provider industry, its primary use is for advertising address 
>> resources (IPv4/v6 and ASN)
>
>
> Not really.



I would think there are a few uses of LOA in the telco/SP world, at least:

  1) 'can I make this cross-connect happen?'
  2) 'can I do some work on this link/path/fiber/conduit on behalf of
 where the entity to be worked on is 
infrastructure'
  3) 'Please accept this internet number resource from 
when the number resource is authorized for use by '

I would love to see ROA take over the 3rd of those, since it's a clear
indicator that:
  "RIR authorizes LIR to use , LIR authorizes
AS-OWNER to originate "

and by 'clear indicator' I mean: "has some cryptographic/PKI backing
you can follow to the RIR in an automated fashion"
Where 'LOA' generally is a xerox of a photocopy of a fax of a
dot-matrix printed MS-Word templated document which perhaps has an X
on the 'signature' line...

-chris

Re: AS8003 mysteries

[Christopher Morrow]

On Wed, Nov 8, 2023 at 4:51 PM Dave Taht  wrote:
>
> Anyone have an update as to where this effort, announcing qute a bit
> of usa government space, stands?
>

they stopped their internet telescope project?

> https://www.kentik.com/blog/the-mystery-of-as8003/
> --
> Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
> Dave Täht CSO, LibreQos

Re: BGP hijack?

[Christopher Morrow]

Hank, all exact match for prefix length? Or longer subnets covering the
whole?
(Is this leakage of a optimizer or possibly censorship leakage?)

On Sun, Oct 22, 2023, 1:03 PM Olivier Benghozi 
wrote:

> Same stuff (with our ASN and our prefixes) detected here, coming
> from AS2027 (Milkywan), for a short time...
>
> Le dim. 22 oct. 2023 à 17:18, Hank Nussbacher  a
> écrit :
>
>> We just had every single prefix in AS378 start being announced by AS2027.
>>
>> Every announcement by AS2027 is failing RPKI yet being propagated a bit.
>> Is this yet another misbehaving device or an actual attack?
>>
>
> *Ce message et toutes les pièces jointes (ci-après le "message") sont
> établis à l’intention exclusive des destinataires désignés. Il contient des
> informations confidentielles et pouvant être protégé par le secret
> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
> immédiatement l'expéditeur et de détruire le message. Toute utilisation de
> ce message non conforme à sa destination, toute diffusion ou toute
> publication, totale ou partielle, est interdite, sauf autorisation expresse
> de l'émetteur*
>

Re: ARIN email address (was cogent spamming directly from ARIN records?)

[Christopher Morrow]

On Tue, Oct 3, 2023 at 12:54 PM  wrote:
>
> * morrowc.li...@gmail.com (Christopher Morrow) [Tue 03 Oct 2023, 18:29 CEST]:
> >this sort of thing (provider X scrapes Y and mails Z for sales leads)
> >every ~18 months.
> >the same outrage and conversation happens every time.
> >the same protection mechanisms are noted every time.
> >
> >Is there a reason that: "killfileand move on" is not the answer
> >everytime for this?
> >(why do we need to keep rediscussing it)
>
> It's a vicious circle: provider scrapes operational addresses and
> spams them, providers stop putting useful addresses in public
> databases to avoid spam, everybody who needs to find operational
> contacts in a variety of situations loses in the end.

i agree this is a sad outcome of the internet ecosystem.

> We keep discussing it because we care about keeping the internet
> running. It's similar to why we keep looking for new security holes in
> existing software: we don't stop because inevitably we'll find more so
> it's a lost cause, we keep looking because inevitably we'll find more
> so the product becomes more secure.

those are a bit of a false equivalence... but... ok.
I think: "Oh look, more spam, delete"
is basically how this sort of problem (email from randos trying to
sell me ED pills or 10Gs) should be treated.
I don't know that it's helpful to keep re-litigating that end state :(

I'm sure telling dave shaeffer: "Hey, your sales droids are being
rude" is going to end as well as sending him ED pill emails.

Re: ARIN email address (was cogent spamming directly from ARIN records?)

[Christopher Morrow]

this sort of thing (provider X scrapes Y and mails Z for sales leads)
every ~18 months.
the same outrage and conversation happens every time.
the same protection mechanisms are noted every time.

Is there a reason that: "killfileand move on" is not the answer
everytime for this?
(why do we need to keep rediscussing it)

On Tue, Oct 3, 2023 at 11:54 AM Bryan Fields  wrote:
>
> On 10/2/23 11:28 AM, Mel Beckman wrote:
> > I believe they got the contact information from ARIN
>
> I'd suggest everyone use an alias unique to ARIN for your POC and/or public
> email.  Makes it super simple to verify where it was sourced from.
>
> (and yes I've got the same spam)
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>

Re: TACACS+ server recommendations?

[Christopher Morrow]

On Thu, Sep 21, 2023 at 6:56 AM Jim  wrote:
...
> My understanding is a good number of password manager products exists which 
> will handle that,
> and then the only AAA  which  network devices need to be concerned about for 
> Authentication and
> Authorization is  Basic password auth,  which all equipment supports.   And 
> the security problems
> don't arise so much for using the TACACS+ / Tac_plus service Solely for 
> Accounting
> (in addition to basic remote syslog).

it's important to recognize that there's not really any protection
(practical protection) from MITM if
you use a passwd with your ssh connection.

A key'd authentication has these protections, as a quirk of the ssh
protocol... (or a design feature if you wish)
A certificate authenticated session has these same protections.

Re: TACACS+ server recommendations?

[Christopher Morrow]

On Thu, Sep 21, 2023 at 5:40 AM Simon Leinen  wrote:
>
> Christopher Morrow writes:
> > On Wed, Sep 20, 2023 at 1:22 PM Jim  wrote:
> >>
> >> Router operating systems still typically use only passwords with
> >> SSH, then those devices send the passwords over that insecure channel.  I 
> >> have yet to
> >> see much in terms of routers capable to Tacacs+ Authorize  users based on  
> >> users'
> >> openSSH certificate, Public key id,  or  ed2559-sk security key id, etc.
>
> > There is active work with vendors (3 or 4 of the folk you may even
> > use?) to support
> > ssh with ssh-certificates, I believe this mostly works today, though
> > configuring it and
> > distributing your ssh-ca-cert may be fun...
>
> Ahem... Cisco supports SSH authentication using *X.509* certificates.

correct, we pointed this out a few times and ... they now also support
ssh-certs.
They also support HIBA extensions (https://github.com/google/hiba) and the
stock hiba-chk which means you could potentially mint a certificate for your
ops user that says: "Simon is authorized to login to DEVICEX only"
(and or others, or not have this check... this is optional, but handy for me)

> Unfortunately this is not compatible with OpenSSH (the dominant SSH
> client implementation we use), which only supports *OpenSSH*
> certificates.

yup, that's what we pointed out to them.. I think their answer was
something like:
  "mumble, we implemented this for a single requesting organization...
we THINK they use it?"

unsure hwo they use it, but.. ok, sure.
now there's openssh cert capability though.
(I admit I can't make search on cisco's site work for me to find what
version introduced this though, sorry)

> Not sure about other vendors, but when we found this out we decided that
> this wasn't a workable solution for us.

it sure wasn't for a long time :(
3 of 4 vendors we deal with support openssh-certificates and hiba...
almost all to the point were
we could actually use it, which is nice. we have some  pains on our
side, they on theirs, but it's
getting almost deployable.

Re: TACACS+ server recommendations?

[Christopher Morrow]

On Wed, Sep 20, 2023 at 1:22 PM Jim  wrote:
>
> Router operating systems still typically use only passwords with
> SSH, then those devices send the passwords over that insecure channel.  I 
> have yet to
> see much in terms of routers capable to Tacacs+ Authorize  users based on  
> users'
> openSSH certificate, Public key id,  or  ed2559-sk security key id, etc.

There is active work with vendors (3 or 4 of the folk you may even
use?) to support
ssh with ssh-certificates, I believe this mostly works today, though
configuring it and
distributing your ssh-ca-cert may be fun...

There are also fairly clear paths to get ssh-keys (rsa, ecdsa) working
for user-auth on those
same 4 vendors.

you will, of course, want some method to manage user-owned-key-material and
distribution/rotation of that material to the network. You CAN enable
'key authentication' and
have tac+ authorization/accounting still on the numbered vendors from
above as well.

-chris

Re: JunOS config yacc grammar?

[Christopher Morrow]

On Thu, Aug 24, 2023 at 11:45 AM Warren Kumari  wrote:
>> from: me
>> this is a common problem (or is common when I look at things, perhaps I'm 
>> looking wrongly, but...)
>> I'd love to have something that parsed all of my device type configs and 
>> output the results into a
>> 'database' that i could then ask questions of like:
>> "Hey, what NTP servers are configured on all devices?"
>> "Hey, which devices have this  configured on 
>> them?"
>>
>>
>
> Isn't this YANG/NETCONF, and squish it all into DB/directory full of files?
>

yup, sort of... I think the yang parts are still not 100% there, and
also then I'd need to do the
1 thing I've been avoiding (aside from printing from a unix machine)
so far: "learn yang things" :)

> Basically a more standardized format for representing device configurations / 
> states?

yup! really any way that would be relatively steady over time to go from:
  "router config on router over there ->"
to:
  "now in some useful way stored in a 'database'"

was/is my goal... or one goal of the many goals I attempt to get to a
solution for every once in a while :)

Re: JunOS config yacc grammar?

[Christopher Morrow]

On Thu, Aug 24, 2023 at 11:10 AM Justin H.  wrote:
>
> Christopher Morrow wrote:
> >
> > In looking around there are examples of some of this, in a way, the
> > most common thing
> > I end up looking at, and getting sad about, is some java monstrosity
> > (who's name escapes me)

> You're probably thinking of Batfish.

yes! I kept wanting to say Bee... something :) thanks!

Re: JunOS config yacc grammar?

[Christopher Morrow]

On Tue, Aug 22, 2023 at 11:39 PM Grant Taylor via NANOG  wrote:
>
> On 8/21/23 7:09 PM, Diogo Montagner wrote:
> > I would first try to understand what you are trying to achieve. JUNOS is
> > very flexible on this front and I am wondering why you think yacc is the
> > right way to achieve what you are trying to do.
>
> Drive by comment:
>
> Perhaps the OP is trying to parse a (pile of) config file(s) downstream
> of the generation thereof and has no ability to alter their generation.

this is a common problem (or is common when I look at things, perhaps
I'm looking wrongly, but...)
I'd love to have something that parsed all of my device type configs
and output the results into a
'database' that i could then ask questions of like:
  "Hey, what NTP servers are configured on all devices?"
  "Hey, which devices have this  configured on them?"

There are a host of other things I could ask those are but 2 simple
examples, and YES I can
grep/sed/awk|sort|uniq|sort-rn my way to success for the 2 examples I
provided... but really
that's NOT the way I want to do this, and I do really have a bunch of
other questions I'd
like to ask, regularly, to solve rollout-of-new-feature / compliance /
legal / troubleshooting / etc
questions.

In looking around there are examples of some of this, in a way, the
most common thing
I end up looking at, and getting sad about, is some java monstrosity
(who's name escapes me)
but has shown up in a few nanog presentations over the years... it
makes me sad because it's
not super useful  in my world :( 'hard to use' is probably the best
way to describe it.

One note about XML and Juniper, the schema changes by OS version, it
changes quite a bit :(
You CAN parse through it reasonably well with python lxml.Etree,
because (I think) python's parse
is VERY forgiving. If you attempt this path with golang :( you will be
sad, very sad :( because
the go->xml world is very 'build a struct of structs that mirrors the
xml tree' and 'changes at every
OS version' means now you have a LOT of versions of that :(
maintenance gets back to saku's
comment about feature velocity :(

I do see:
   https://pypi.org/project/juniper-nxpy/

which may be useful to you as well Lyndon.
(I'd also point to tftp as not being the super best option from a
security and reliability perspective,
but if that's what you've got that's what you've got... you COULD have
the switch cronjobs curl/post
to an https destination with little hard work, and a gain in
reliabilty/security)

-chris

Re: Northern Virginia has had enough with data centers

[Christopher Morrow]

On Fri, Jun 23, 2023 at 5:36 PM Delong.com  wrote:
>
>
>
> On Jun 23, 2023, at 12:19, Christopher Morrow  wrote:
>
> On Fri, Jun 23, 2023 at 9:16 AM Mike Hammett  wrote:
>
>
> I view throwing everything into NOVA as being lazy. Throwing so many at one 
> place isn't good for resiliency.
>
>
> there's nyc and chicago and california :) (and dallas)
> but.. :)
>
> The discussions in local news (in nova) seem to center around:
>  "but the noise!"
>
>
> This is relatively silly unless the local grid is extraordinarily unreliable. 
> Unless the generators are running,
> you can rarely hear a datacenter beyond the bounds of its parking lot.

yes.

>  "but the beautiful scenery!"
>
>
> This one might be somewhat valid if it wasn’t likely to become some other 
> form of warehouse anyway.
>

it's their 'heritage' that they are worried about.

>  "but the water poisoning!!"
>
>
> ??? I find it hard to believe that data centers are big emitters of water 
> pollution. Someone’s going to have
> to explain this one to me.
>

there's plenty of, already available, discussion about how this is
just a trope being used instead of 'but our heritage'.
yea, it's just not at all an actual problem.

> there were, apparently, some actual problems with how
> prince-william-county did their re-zoning work...
> like, I think, one of the administration folks 'had a ton of money
> tied up in DC company stock...' (that person may have recused
> themselves, but)
>
> If you peel back the layers a bunch of it actually looks pretty
> horrible for the people protesting:
>  "NIMBY problems"
>  "Our 'heritage'"
>
> i'm sure it'll work out in the end, but ... gonna be fun to watch.
>
>
> I’ll bring marshmallows, who wants to bring the chocolate and the graham 
> crackers to this dumpster fire?

I have 1 lawn chair, you'll need to bring your own.

> Owen
>

Re: Northern Virginia has had enough with data centers

[Christopher Morrow]

On Fri, Jun 23, 2023 at 3:57 PM William Herrin  wrote:
>
> On Fri, Jun 23, 2023 at 12:19 PM Christopher Morrow
>  wrote:
> > The discussions in local news (in nova) seem to center around:
> >   "but the noise!"
> >
> > i'm sure it'll work out in the end, but ... gonna be fun to watch.
>
> There is apparently a problem in nearby West Virginia where someone
> built a cryptomining facility using free air cooling and it disturbs
> the neighbors. 
> https://www.washingtonpost.com/business/2022/03/18/bitcoin-mining-noise-pollution-appalachia/

arguably, people buying into the idea that blatantly flim-flamming
folks aren't going to flim-flamming them is.. not related here, at
all.
(that article is about limestone, TN, not west virginia - west nor
virginia appear in the article)

> Even traditional data centers have not been known to be especially
> considerate about scheduling their -loud- genset tests. Doesn't matter
> so much in the middle of an industrial zone but when you do it near
> where people live you're going to make them angry.

sure, I believe the various nova parts have reasonable agreements
about how/when to do these
sorts of tests though.

Re: Northern Virginia has had enough with data centers

[Christopher Morrow]

On Fri, Jun 23, 2023 at 9:16 AM Mike Hammett  wrote:
>
> I view throwing everything into NOVA as being lazy. Throwing so many at one 
> place isn't good for resiliency.

there's nyc and chicago and california :) (and dallas)
but.. :)

The discussions in local news (in nova) seem to center around:
  "but the noise!"
  "but the beautiful scenery!"
  "but the water poisoning!!"

there were, apparently, some actual problems with how
prince-william-county did their re-zoning work...
like, I think, one of the administration folks 'had a ton of money
tied up in DC company stock...' (that person may have recused
themselves, but)

If you peel back the layers a bunch of it actually looks pretty
horrible for the people protesting:
  "NIMBY problems"
  "Our 'heritage'"

i'm sure it'll work out in the end, but ... gonna be fun to watch.

>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> 
> From: "Sean Donelan" 
> To: nanog@nanog.org
> Sent: Thursday, June 22, 2023 3:02:20 PM
> Subject: Northern Virginia has had enough with data centers
>
>
> Backlash to data centers prompts political upset in northern Virginia
> By MATTHEW BARAKAT
> https://apnews.com/article/virginia-election-data-centers-prince-william-229cb44d34ccf4bd1cc4e9f0d0131649
>
> FALLS CHURCH, Va. (AP) — The tech industry’s drive to dot the Virginia
> landscape with data centers may have hit a glitch this week in Prince
> William County.
>
> [...]
> The plan, called the Prince William Digital Gateway, prompted one of the
> region’s biggest land-use disputes in decades. It was approved despite
> vocal opposition from residents concerned that the data centers are noisy,
> ugly, and consume massive amounts of electricity that require the addition
> of high-voltage transmission lines.
>
> [...]
> Josh Levi, president of the Data Center Coalition, an industry trade
> group, said that data centers can make a compelling argument to local
> officials about the tax benefits that accrue from hosting data centers.
>
> “The industry prioritizes maintaining an open, active, and collaborative
> dialogue with elected officials and candidates for office, their
> constituents, and other community stakeholders,” he said in a statement.
>
> [...]
>

Re: G root servers unreachable via ICMP(v6)

[Christopher Morrow]

On Tue, May 16, 2023 at 4:59 PM William Herrin  wrote:
>
> On Tue, May 16, 2023 at 1:38 PM Christopher Morrow
>  wrote:
> > On Tue, May 16, 2023 at 2:35 PM William Herrin  wrote:
> > > Ping is used by some versions of traceroute which can help the
> >
> > I think you mean 'icmp' here. yes. I contend that traceroute (udp or
> > icmp or tcp)
> > TOWARDS a destination can be sometimes useful, sure.
>
> I mean ICMP echo-request, colloquially "ping." Traceroute using ICMP

I find you are being oddly imprecise today! :)
"ping" is an application.
icmp type 0 code 0 is 'echo-reply'
icmp type 8 code 0 is 'echo' (request)

The traceroute application on some platforms defaults to UDP and
offers ICMP as a transport.
On some platforms it defaults to ICMP and (may) offer UDP as a transport.

I was simply trying to be clear about 'ping' being an application and
the underlying protocol (icmp)
being what traceroute be using.

> needs the echo-reply from the destination to know that the trace
> reached the destination, just like it needs port unreachable for UDP
> and RST/SNYACK for TCP.
>
>
> > > When working, it also lets the diagnostician know that the site's
> > > firewall administrator didn't ignorantly decide to block all ICMP.
> > > Which so very many ignorant firewall administrators do.
> >
> > sure, but... 'ignorantly' seems to imply that their ideas of their best
> > practice(s) are different from yours. They may have a valid reason
> > to block icmp, even all icmp.
>
> Since that breaks PMTUD on a public-facing service, I'm entirely

blocking inbound (to your site) some/all ICMP is a decision that some
folk may choose
for a host of reasons. Since the tooling discussed so far isn't
sending icmp-unreachable types
at the g-root server we can't really know if they block 'all icmp', as much as:
  "well it sure seems like they drop icmp-echo!"

It seems like all we know so far is that G-root and/or its network
provider(s) don't like seeing
packets destined to their service which are not service bearing
packets, I don't think we have
evidence that they don't accept icmp unreachables though, I'd imagine
that as a root op they know
better than to drop unreachables since the may serve (probably have to
serve) edsn0 type replies at times.

The lion's share of traffic (actual dns traffic) to an authoritative
server is small inbound udp/53 (or tcp/53
for which I think OARC has numbers on ratios actually?) packets. Their
replies MAY be large(r) packets
which may be subject to pmtud problems, of which they'll be super
familiar with handling.

Re: G root servers unreachable via ICMP(v6)

[Christopher Morrow]

On Tue, May 16, 2023 at 2:35 PM William Herrin  wrote:
>
> On Tue, May 16, 2023 at 11:00 AM Christopher Morrow
>  wrote:
> > On Tue, May 16, 2023 at 4:37 AM  wrote:
> > > Cutting PING means you are hurting your basic troubleshooting.
> > > Is that thing even plugged in? Maybe Firewall misconfiguration?
> >
> > it means you need to use the tool (dig, host, nslookup) that talks to
> > the service being offered.
> > ping is basically meaningless as a test for 'is the service working'
> > on a dns server.
>
> Ping is used by some versions of traceroute which can help the

I think you mean 'icmp' here. yes. I contend that traceroute (udp or
icmp or tcp)
TOWARDS a destination can be sometimes useful, sure.

This is different from: "i can ping g.root-servers.net so internet is up!"
if you care about how / when g.root-servers.net is working, dns packet
sending is the answer (and ideally listening to the replies!)

> When working, it also lets the diagnostician know that the site's
> firewall administrator didn't ignorantly decide to block all ICMP.
> Which so very many ignorant firewall administrators do.

sure, but... 'ignorantly' seems to imply that their ideas of their best
practice(s) are different from yours. They may have a valid reason
to block icmp, even all icmp.

Re: G root servers unreachable via ICMP(v6)

[Christopher Morrow]

On Tue, May 16, 2023 at 4:37 AM  wrote:
>
> So, DoD does NOT have capacity to answer those little ICMP echo
> request packets? Heh.. Anyway, this is IMO terrible practice.

why?

> Cutting PING means you are hurting your basic troubleshooting.
> Is that thing even plugged in? Maybe Firewall misconfiguration?

it means you need to use the tool (dig, host, nslookup) that talks to
the service being offered.
ping is basically meaningless as a test for 'is the service working'
on a dns server.

Re: Aptum refuses to SWIP

[Christopher Morrow]

On Fri, May 5, 2023 at 8:48 AM richey goldberg
 wrote:

> In 25 years of working for ISPs I don’t think I’ve ever worked for one that 
> SWIPed IP space of any size to an end user and I don’t think I’ve ever seen a 
> request.  Mostly because no one wants to put a list of customers out in the 
> public domain.

There are ISPs that swip, all allocations except those which are
'residential' (see arin / ripe rules about this, privacy related)...
My home internet connection when I worked for uunet had swip data the
company automatically added, as it did with all customers. (in fact
that swip still exists, for )

Re: RPKI Mgmt Changes at ARIN (was: Fwd: [arin-announce] Upcoming Changes to ARIN’s Resource Public Key Infrastructure (RPKI))

[Christopher Morrow]

On Fri, Apr 14, 2023 at 5:41 PM Ca By  wrote:
>
>
>
>>
>> **ROA Auto-renewal**
>>
>> After the May software release, any ROA created via ARIN Online or the new 
>> RESTful provisioning endpoint will be automatically renewed, meaning all 
>> newly created ROAs will persist indefinitely until they are manually 
>> deleted. ARIN will also apply the auto-renew feature to any existing ROAs 
>> when we deploy this new functionality.
>>
>> Please note: Any new ROAs created with the legacy RESTful endpoint will not 
>> be auto-renewed. If you would like your ROAs to be auto-renewed, you will 
>> need to use ARIN Online or the new RESTful provisioning endpoint. ARIN will 
>> be contacting customers who have created ROAs in both ARIN Online and REST 
>> to determine how they prefer to manage their existing ROAs
>
> Thanks John and ARIN team, this auto-renew is a big deal and helps take a lot 
> of stress off our plates

oh! there's a bunch of pretty good improvements here, thanks! (john
and cameron for raising this mail up in the my stack)

-chris

Re: Spamhaus flags any IP announced by our ASN as a criminal network

[Christopher Morrow]

On Mon, Mar 20, 2023 at 7:08 PM Brandon Zhi  wrote:
>
> Our person in charge has consulted with their previous person in charge, and 
> their response is this.



you are talking up the discussion with the wrong folks, really.
Please go see the spamhaus folk directly.

Re: Spamhaus flags any IP announced by our ASN as a criminal network

[Christopher Morrow]

On Mon, Mar 20, 2023 at 9:51 AM Brandon Zhi  wrote:

> I don't think any ISP would reject an IP that is on the Spamhaus list.

you, clearly, have been living under several rocks for a very long time.

Re: Is malicious asymmetrical routing still a thing?

[Christopher Morrow]

On Thu, Mar 9, 2023 at 4:19 PM Christopher Munz-Michielin
 wrote:
>
> Not this exact scenario, but what we see a lot of in my VPS company is
> people sending spam by using our VPS' source addresses, but routing
> outbound via some kind of tunnel to a VPN provider or similar in order
> to bypass our port 25 blocks.
>
> We've had to start blocking source port 25 to catch the replies from the
> recipient mail servers in order to prevent this kind of abuse.

commodity 'ip access' really is all the same (dial, dsl, cable, vpc) to folk
that do this sort of thing :(

Re: Scheduled outage -- Nationwide no driver license updates this weekend

[Christopher Morrow]

On Sat, Feb 25, 2023 at 6:12 PM Sean Donelan  wrote:
>
> Verizon network maintenance will impact access to the “National Driver
> Register,” a system that motor vehicle offices around the country need to
> check before handing out a license.

Wait, what year is it?
how is a network maintenance on what seems like a fairly critical system going
to cause a total outage of said system?

I think we time traveled back to 1990 here...

>
> All 50 states and D.C. participate in the National Driver Register, a
> database maintained by the National Highway Traffic Safety Administration.
> The register contains information about drivers who have had their driving
> privileges revoked, suspended or denied due to serious traffic violations,
> such as driving under the influence of alcohol or drugs, reckless driving
> or excessive speeding.
>
>
> The scheduled maintenance should be finished by Monday, in case you needed
> to update your driver's license or planned to do some reckless driving
> this weekend.

Re: Reverse Traceroute

[Christopher Morrow]

Didn't ethan's project:
  https://www.measurementlab.net/publications/reverse-traceroute.pdf

end with usable code/etc?

On Wed, Feb 22, 2023 at 8:09 AM Rolf Winter  wrote:
>
> Dear NANOG folks,
>
> As you know, traceroute is unable to enumerate routers on the reverse
> path. Given that paths through the public internet are usually
> asymmetric, knowing the reverse path would be beneficial e.g. for
> troubleshooting purposes (https://youtu.be/L0RUI5kHzEQ?t=2312).
>
> We have implemented a reverse traceroute tool
> (https://github.com/hsanet/reverse-traceroute), both client and server
> for both IPv4 and IPv6. We are also in the process of specifying the
> protocol at the IETF
> (https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute).
>
>
> We also gave a talk on reverse traceroute at DENOG14
> (https://youtu.be/Y7NtqLEtgjU).
>
> If you would like to play with reverse traceroute, the easiest option is
> to work with the client and use one of the public server instances
> (https://github.com/HSAnet/reverse-traceroute/blob/main/ENDPOINTS). If
> you would be willing to host a public server instance yourself, please
> reach out to us. Also, if you find this work useful, please start
> discussing the work at the IntArea WG at the IETF.
>
> If you have any questions or comments, just drop us a line, file an
> issue on github and/or use the IntArea mailing list.
>
> Thanks a bunch,
>
> Rolf

Re: SDN Internet Router (sir)

[Christopher Morrow]

On Thu, Jan 5, 2023 at 11:18 AM Mike Hammett  wrote:

> Initially, my thought was to use community filtering to push just IXes,
> customers, and defaults throughout the network, but that's obviously still
> sub-optimal.
>
> I'd be surprised if a last mile network had a ton of traffic going to any
> more than a few hundred prefixes.
>

I think in a low-fib box at the edge of your network your choices are:
  "the easy choice, get default, follow that"

  "send some limited set of prefixes to the device, and default, so you MAY
choose better for the initial hop away"

you certainly can do the second with communities, or route-filters
(prefix-list) on the senders, or
you can choose what prefixes make the cut (get the community(ies)) based on
traffic volumes or expected destination locality:
   "do not go east to go west!"

these things will introduce toil and SOME suboptimal routing in some
instances... perhaps it's better than per flow choosing left/right though
and the support calls related to that choice.

In your NOLA / DFW / ATL example it's totally possible that the networks in
question do something like:
  "low fib box in tier-2 city (NOLA), dfz capable/core devices in tier-1
city (DFW/ATL), and send default from left/right to NOLA"

Could they send more prefixes than default? sure... do they want to deal
with the toil that induces? (probably not says your example).

SDN isn't really an answer to this, though.. I don't think. Unless you
envision that to lower the toil ?

Re: SDN Internet Router (sir)

[Christopher Morrow]

On Wed, Jan 4, 2023 at 8:37 AM Tom Beecher  wrote:

> Disagree that it’s a line in the sand. It’s use the right tool for the
> job.
>
> If a device is low FIB, it’s that way for a reason. There are plenty of
> ways to massage that with policy and software, depending on capabilities ,
> but at the end of the day, trying to sort 10 pounds of shit to store in a 5
> pound bag is eventually going to end up the same way.
>

Some of the reasoning behind 'i need/want to do SDN things' is 'low fib
device' sort of reasonings. Some is: "I just want a forwarding decision
that's not entirely LPM oriented"
(or to be fair: "My LPM is not JUST longest prefix, but also some other
data")

For folk that are looking for software alternatives you might look at
faucet:
  https://github.com/faucetsdn/faucet

which still seems to be actively developed.

Re: ROAs Expire

[Christopher Morrow]

On Tue, Jan 3, 2023 at 11:07 AM John Curran  wrote:

> Thank you Chris!
>
> (I scribed a quick reply where a lengthier one might have been best - I
> usually have the opposite problem… ;-)
>
>
hehe :) thanks for the update on the ARIN systems!


> Best wishes and Happy Holidays!
>

you as well!


> /John
>
> On Jan 3, 2023, at 11:01 AM, Christopher Morrow 
> wrote:
>
>
>
> On Tue, Jan 3, 2023 at 10:53 AM John Curran  wrote:
>
>> Mike -
>>
>> A friendlier RPKI system would allow you to delegate/authorize the
>> automatic action of refreshing your RPKI ROA’s when they are close to
>> expiration.
>>
>> ARIN’s current RPKI system does not provide this (we literally cannot
>> under the present schema as we never possess the private key that’s
>> necessary for our HSM to perform a ROA generation on your behalf) – but
>> other RIRs RPKI systems are built differently and have this functionality
>> today in their hosted RPKI systems.
>>
>> After frequent user requests in this area – along with some requests that
>> are related regarding user-interface improvements – we will be moving to a
>> hosted RPKI environment that supports automatic ROA rollovers later this
>> year.  (Note - as a result of this change, folks who want strong assurance
>> of non-repudiation of ROA generation should consider delegated or hybrid
>> RPKI setups.)
>>
>>
>>
> To clarify, your last paragraph:
>   today ARIN has an HSM, for parts of the work, but requires that the user
> (me, mike, jared) hold our
>   private key(s) used to sign objects locally. this means that ARIN never
> sees the private key material.
>   a private key would be required to be visible/accessible to ARIN's
> system(s) in order to auto-update
>   a ROA(s) in such a new system.
>
>   Further, the future system (that will enable auto-update of ROA) will
> need access to the private key
>   material. This means that POSSIBLY ARIN or a bad-actor may be able to
> use that private key material
>   for bad deeds. (note I'm not saying ARIN is a bad actor, nor that they
> want to do bad things)
>   So folks that need/want to be more assured that their private key
> material is 'safe' will need to move
>   off the ARIN Hosted deployment prior to the new system coming alive.
>
> Maybe that's all super clear to everyone else, but :) sometimes more words
> are more better/clear.
>
>
>> Thanks (and Happy Holidays!)
>> /John
>>
>> John Curran
>> President and CEO
>> American Registry for Internet Numbers
>>
>> On Jan 3, 2023, at 10:42 AM, Mike Hammett  wrote:
>>
>> Nothing went south for me, just got an email from ARIN reminding me that
>> they were about to expire.
>>
>> The reasons you stated all make sense. We'll just have to make sure it's
>> easy enough for the less skilled or more busy operators to comply with
>> current best practices, lest they not do it at all to avoid the hassle.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions <http://www.ics-il.com/>
>> <https://www.facebook.com/ICSIL>
>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
>> <https://www.linkedin.com/company/intelligent-computing-solutions>
>> <https://twitter.com/ICSIL>
>> Midwest Internet Exchange <http://www.midwest-ix.com/>
>> <https://www.facebook.com/mdwestix>
>> <https://www.linkedin.com/company/midwest-internet-exchange>
>> <https://twitter.com/mdwestix>
>> The Brothers WISP <http://www.thebrotherswisp.com/>
>> <https://www.facebook.com/thebrotherswisp>
>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
>> --
>> *From: *"Jared Mauch" 
>> *To: *"Mike Hammett" 
>> *Cc: *"NANOG" 
>> *Sent: *Tuesday, January 3, 2023 9:39:10 AM
>> *Subject: *Re: ROAs Expire
>>
>> On Tue, Jan 03, 2023 at 08:56:28AM -0600, Mike Hammett wrote:
>> > ROAs expire. Creating new ones doesn't seem to be terribly difficult,
>> but why do they expire in the first place?
>>
>> There's several reasons I can see why one would want this:
>>
>> 1) to ensure that proper care is maintained over the IP space, domains,
>> certificiates (ROA is a certificiate), etc expire and require renewal.
>>
>> 2) If there's a new cipher algo flaw or similar, it may become necessary
>> to rotate things.
>>
>> 3) to help avoid some of the problems that exist with unmaintained IRR
>> objects.
>>
>>   

Re: ROAs Expire

[Christopher Morrow]

On Tue, Jan 3, 2023 at 10:53 AM John Curran  wrote:

> Mike -
>
> A friendlier RPKI system would allow you to delegate/authorize the
> automatic action of refreshing your RPKI ROA’s when they are close to
> expiration.
>
> ARIN’s current RPKI system does not provide this (we literally cannot
> under the present schema as we never possess the private key that’s
> necessary for our HSM to perform a ROA generation on your behalf) – but
> other RIRs RPKI systems are built differently and have this functionality
> today in their hosted RPKI systems.
>
> After frequent user requests in this area – along with some requests that
> are related regarding user-interface improvements – we will be moving to a
> hosted RPKI environment that supports automatic ROA rollovers later this
> year.  (Note - as a result of this change, folks who want strong assurance
> of non-repudiation of ROA generation should consider delegated or hybrid
> RPKI setups.)
>
>
>
To clarify, your last paragraph:
  today ARIN has an HSM, for parts of the work, but requires that the user
(me, mike, jared) hold our
  private key(s) used to sign objects locally. this means that ARIN never
sees the private key material.
  a private key would be required to be visible/accessible to ARIN's
system(s) in order to auto-update
  a ROA(s) in such a new system.

  Further, the future system (that will enable auto-update of ROA) will
need access to the private key
  material. This means that POSSIBLY ARIN or a bad-actor may be able to use
that private key material
  for bad deeds. (note I'm not saying ARIN is a bad actor, nor that they
want to do bad things)
  So folks that need/want to be more assured that their private key
material is 'safe' will need to move
  off the ARIN Hosted deployment prior to the new system coming alive.

Maybe that's all super clear to everyone else, but :) sometimes more words
are more better/clear.


> Thanks (and Happy Holidays!)
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
> On Jan 3, 2023, at 10:42 AM, Mike Hammett  wrote:
>
> Nothing went south for me, just got an email from ARIN reminding me that
> they were about to expire.
>
> The reasons you stated all make sense. We'll just have to make sure it's
> easy enough for the less skilled or more busy operators to comply with
> current best practices, lest they not do it at all to avoid the hassle.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Jared Mauch" 
> *To: *"Mike Hammett" 
> *Cc: *"NANOG" 
> *Sent: *Tuesday, January 3, 2023 9:39:10 AM
> *Subject: *Re: ROAs Expire
>
> On Tue, Jan 03, 2023 at 08:56:28AM -0600, Mike Hammett wrote:
> > ROAs expire. Creating new ones doesn't seem to be terribly difficult,
> but why do they expire in the first place?
>
> There's several reasons I can see why one would want this:
>
> 1) to ensure that proper care is maintained over the IP space, domains,
> certificiates (ROA is a certificiate), etc expire and require renewal.
>
> 2) If there's a new cipher algo flaw or similar, it may become necessary
> to rotate things.
>
> 3) to help avoid some of the problems that exist with unmaintained IRR
> objects.
>
> There's more I'm sure, but this is one of the reasons that I
> personally have been hesitatant to roll out some tools, eg: DNSSEC
> (which suffers from a variety of ciphers and for some cases lack of
> ability to publish to parents - i think this was largely resolved).
>
> With this increased security also comes to increased fragility,
> which I suspect is what you are writing about, something likely broke
> for you or someone else due to lack of checking the status of the ROA
> expiration.
>
> This has happened in the past with domains, including big name
> ones, so having something setup (eg: roa watch, similar to x509watch on
> *nix systems) would be appropriate.
>
> I'm sure others can refer to tools or services that can do this,
> but it's always a good idea to check your objects and watch when they go
> away or expire.
>
> - Jared
>
> --
> Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
> clue++;  | http://puck.nether.net/~jared/  My statements are only
> mine.
>
>
>

Re: ROAs Expire

[Christopher Morrow]

On Tue, Jan 3, 2023 at 9:58 AM Mike Hammett  wrote:

> ROAs expire. Creating new ones doesn't seem to be terribly difficult, but
> why do they expire in the first place?
>
>
I think this is covered in the overview rpki document (design decisions):
  https://datatracker.ietf.org/doc/rfc8374/

maybe particularly  section 9.2 is of interest?

Re: Google Speed Test

[Christopher Morrow]

On Wed, Dec 28, 2022 at 12:50 PM Lukas Tribus  wrote:
>
> Hello,
>
> On Wed, 28 Dec 2022 at 17:41, Mike Hammett  wrote:
> >
> > Does AS15169 have a speed test?
>
> Stadia speedtest is still up today:
>
> https://stadia.google.com/speedtest

"Google partners with Measurement Lab (M-Lab) to run this speed test.
Running this test could transfer over 40 MB of data, depending on your
connection speed. Mobile data charges could apply."

that's not guaranteed to be 15169, fwiw.

>
>
> Lukas

Re: AS3356 Announcing 2000::/12

[Christopher Morrow]

On Thu, Dec 8, 2022 at 1:45 AM Heasley  wrote:
>
>
>
> Am 12/7/22 um 22:25 schrieb Don Beal :
>
> 
> How can RPKI / OV prevent such a leak when there is no ROA for 2000::/12,
>
>
> If all ASes participated, no „unknowns“, unknowns could be dropped, ….
>

yea that might be a tad dangerous today :(
and don's right :( unknown is hard today :( (darn you don for being
practical! :) )

crud.. but iRR filters! :)


> what would 6762|2914|174|* invalidate against? Until a future where 
> everything is 'valid', RPKI is unable to pare out less-specific conflicts.
>
> It does look like 3356 pulled the announcement, which is good.
>
>
> On Thu, Dec 8, 2022 at 4:48 AM Christopher Morrow  
> wrote:
>>
>> On Wed, Dec 7, 2022 at 11:25 PM Ryan Hamel  wrote:
>> >
>> > AS3356 has been announcing 2000::/12 for about 3 hours now, an aggregate 
>> > covering over 23K prefixes (just over 25%) of the IPv6 DFZ.
>> >
>> >
>>
>> interesting that this is leaking outside supposed RPKI OV boundaries as well.
>> For example:
>>   6762 3356
>>   2914 3356
>>   174 3356 (apologies to 174, I forget if they signed up to the 'doin
>> ov now' plan)

Re: AS3356 Announcing 2000::/12

[Christopher Morrow]

On Wed, Dec 7, 2022 at 11:25 PM Ryan Hamel  wrote:
>
> AS3356 has been announcing 2000::/12 for about 3 hours now, an aggregate 
> covering over 23K prefixes (just over 25%) of the IPv6 DFZ.
>
>

interesting that this is leaking outside supposed RPKI OV boundaries as well.
For example:
  6762 3356
  2914 3356
  174 3356 (apologies to 174, I forget if they signed up to the 'doin
ov now' plan)

Re: Re: Why do ROV-ASes announce some invalid route?

[Christopher Morrow]

On Fri, Nov 11, 2022 at 8:49 AM Lukas Tribus  wrote:
>
> On Fri, 11 Nov 2022 at 14:00, Christopher Morrow
>  wrote:
> > Also, also, possibly the output path on the session(s) here is not
> > filtering in an OV fashion.
>
> ROV belongs on the input path, let's not ROV on the output towards
> customers / route collectors.

sure. This assumes a 100% coverage for all inputs to the rib-out on
the customer port we're talking about, though.
If you don't have 100% coverage you'll end up with the leaks
seen/reported by the OP.

I don't mean to say/imply:
  "Hey, everyone(anyone) should do OV on output"

I mean to say that:
  "Hey, if you see OV failures leaking, this is probably a side effect
of the behavior/design
   choices a network made." (not doing OV filtering on one of
peer/customer/transit type
   peerings."

-chris

Re: Re: Why do ROV-ASes announce some invalid route?

[Christopher Morrow]

There are 2 sides to the bgp conversation for any ASN, and then really 4 sides.
  customer -> RAS -> peer (settlement-free)
  peer(sfp) -> RAS -> customer
  customer -> ras -> transit
  transit -> ras -> customer

Depending on the RAS's capabilities or status in their journey to
'fully RAS', it's
possible that they may have:
  o "We OV all customer sessions" (notably not SFP peers)
  o "We OV all sessions(*)" (noting not all, and maybe depending on
platform specifics)

There are a bunch of ways this goes wrong :( This also doesn't really
tell what sort of peering
the RAS has set up with RouteViews (customer? peer? partial peer?)

Also, also, possibly the output path on the session(s) here is not
filtering in an OV fashion.

On Thu, Nov 10, 2022 at 9:13 AM 孙乐童  wrote:
>
> Hello Job,
>   Thank you very much for your reply! I got that no AS can actually filter 
> all the invalids. Yet I was trying to figure out why we couldn't see 
> reasonable amount of withdrawals from AS6939 about invalid prefixes, as they 
> explained how they implement ROV 
> (https://mailman.nanog.org/pipermail/nanog/2020-June/108309.html). Perhaps we 
> need to learn their detailed implementations.
>   Thank you very much!
>
> Best wishes,
> Sun Letong
>
> 在2022-11-08 00:11:24,Job Snijders写道：
> > Dear 孙乐童,
> >
> > On Mon, Nov 07, 2022 at 08:40:57PM +0800, 孙乐童 wrote:
> > > We learned from Cloudflare's https://isbgpsafeyet.com/ that some ASes
> > > have deployed RPKI Origin Validation (ROV). However, we downloaded BGP
> > > collection data from RouteViews and RipeRis platforms and found that
> > > some ROV-ASes can announce some invalid routes. For example, from RIB
> > > data at 2022-10-31 00:00:00, 13 out of 17 ASes which declared to
> > > deploy ROV announced invalid routes, and we list the number of related
> > > prefixes for each AS below.
> > >
> > > [snip]
> > >
> > > As a comparison, we count the invalid routes the non-ROV ASes (also
> > > declared in https://isbgpsafeyet.com/) announces, as below:
> > >
> > > We can see that ROV ASes announced apparently fewer invalid routes
> > > compared to the non-ROV ASes, though they did not filter all the
> > > invalids.
> > >
> > > [snip]
> > >
> > > Can anyone help us to correctly interpret this case? Thank you very much.
> >
> > You ask great questions! I hope an answer to your questions can be found
> > in a message I sent a year ago:
> >
> >   https://mailman.nanog.org/pipermail/nanog/2021-April/213346.html
> >
> > The summary: in any sufficiently large network, chances are not 100% of
> > all equipment supports RPKI-based BGP Route Origin Validation; in such
> > cases a handful of invalid routes may still percolate through the
> > system. Another contributing factor might be certain types of software
> > upgrades; where ROV temporarily is disabled on one or more devices. Or
> > perhaps an ISP made a handful of exceptions for test/beacon invalid
> > routes to propagate.
> >
> > Kind regards,
> >
> > Job
>

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Christopher Morrow]

On Tue, Oct 4, 2022 at 8:36 PM  wrote:
>
> The FCC hasn’t enforced it because the burden on large carriers to collect 
> that data would be insane. And it would be reduce the flexibility of large 
> carriers to take on new traffic in disaster situations, which is one of the 
> strongest points of the PSTN. It’s not like the carriers have the data and 
> aren’t using it, they simply don’t have the data.

/me looks at weblogs for a very large internet site
  ".. burden on large carriers to collect that data would be insane..."

ORLY? do tell.

Re: VZ FIOS and Intel TCP IPv6 Checksum Offload problems

[Christopher Morrow]

On Mon, Aug 29, 2022 at 12:00 PM Sean Donelan  wrote:
>
> On Sat, 27 Aug 2022, Michael Thomas wrote:
> >> In some situations where a client machine is connected via some specific
> >> Optical Network Terminals (ONTs), and data is appended after the packet
> >> checksum, the network adapter can drop receive packets when using TCP-IPv6
> >> Checksum Offload for receive traffic.
> >>
> >
> > My reaction is "offload from what"? Isn't this all done in silicon?
>
> Because the interoperability flaw is in silicon, it can't be easily fixed
> in either the legacy wired Intel ethernet controller or fiber ONT.  Would
> need to replace the hardware to fix the silicon.
>
> Need to disable the hardware IPv6 TCP checksum offload, so its not mangled
> or dropped at the silicon layers anymore.
>
> Its annoyingly intermittent and not visible with client-based Wireshark
> because the corruption occurs in the hardware controller.

Uhm, this includes various versions of the intel pro 1000 card... so
that's a TON of gear,
to include like lenovo laptops, for instance. I'd wager that this is
super common in the field.
The PDF in the download says;
  "Products Affected: All 1gbe and 10gbe intel ethernet controllers"

One wonders if this is a case of the 'mac addresses that start with 4
or 6 fail' problem?
(the pdf has zero words about what the actual problem is)

Re: AS701 anycasts any IP?

[Christopher Morrow]

On Fri, Aug 26, 2022 at 5:49 AM Bjoern Franke via NANOG  wrote:
>
> Hi,
> while investigating an issue I was wondering a german IP was only 1-2
> hops away from some RIPE Atlas Probes connected via AS701.
>
> It seems at least probe #50235 and #54508 see any IP directly as next
> hop, as an example here with the IP of mailop.org:
>

the 2 probes are in boston, mass vs new york, new york.
The endpoint appears to be closer to the boston probe (54508).
>From virginia/wdc the endpoint is ~100ms away and in ~germany.
  (the last hop I see says anx84, which might be norway... 'not boston' though)

Is it possible that 701's seeing a local copy of the /24?

looking at their lookingglass for ping/bgp data from billerica, ma
(boston adjacent):
  91.132.144.0/22 (2 entries, 1 announced)
*BGPPreference: 170/-96
Age: 2w2d 6:44:09 Metric: 10 Metric2: 500502
Announcement bits (4): 0-KRT 3-RT 10-BGP_RT_Background
11-Resolve tree 5
AS path: 1299 47147 197540 I  (Originator)

PING 91.132.147.157 (91.132.147.157): 56 data bytes
64 bytes from 91.132.147.157: icmp_seq=0 ttl=55 time=102.899 ms

curious results though :)

> https://atlas.ripe.net/measurements/44133927/
>
> Regards
> Bjoern
>
>
>

Re: Verizon no BGP route to some of AS38365 (182.61.200.0/24)

[Christopher Morrow]

On Thu, Jul 21, 2022 at 11:44 AM holow29  wrote:

> I would expect Verizon to be able to contact CT and figure out why they
> aren't passing the correct routes just as I might expect Baidu to do the
> same thing, I suppose. Ultimately,
>

You seem to be misunderstanding the relationship here...
  Baidu is a CUSTOMER of VZ/701

VZ's only responsibility here is to provide reachabilty to the routes which
Baidu announces to VZ.
There's no reason VZ should believe anything other than the fact that Baidu
is not sending the particular prefix (or covering routes) to VZ 'today'..
for reasons which are entirely Baidu's.

whose responsibility is it other than CT? That is my question. Maybe in
> this instance, it is common in the industry for this to be the
> responsibility of Baidu. That seems counterintuitive to me as it is Verizon
> without the proper route ultimately, but I am not an expert.
>

The person announcing the routes (or not) is the one who makes the decision
to do so...
There's, of course, a possibility that VZ (or any isp instead of VZ in this
particular case) has decided to filter certain prefixes from Baidu's
peering, but
that's not generally the case for ISPs...

Note: there are no ROA for the /24 in question, but Baidu does claim they
may announce: 182.61.200.0/22
according to IRR data...


> Certainly, I think it is incorrect to ask the customer to try to resolve
> these issues after bringing it to the attention of these services. If
> Verizon couldn't reach one of Google's edge servers, would it be Verizon or
> Google's responsibility to fix that if the issue were an intermediate peer
> failing to broadcase the correct route? I have the sneaking suspicion that
> Verizon might actually take some action in that instance...
>
>
you have misunderstood the customer/provider relationship I suspect.


> On Thu, Jul 21, 2022 at 9:31 AM Tom Beecher  wrote:
>
>> Unfortunately it seems like policy that Verizon pushes any issues that
>>> aren't internal routing issues to an external party, but surely they have a
>>> responsibility to maintain their peering and routes to external services as
>>> well.
>>>
>>
>> Baidu is behind CT. If CT is not passing on routes to 701 , what exactly
>> do you expect Verizon to do about it?
>>
>>
>> On Wed, Jul 20, 2022 at 6:40 PM holow29  wrote:
>>
>>> To follow up on this:
>>> I've engaged Verizon's executive office to finally try to get to a
>>> network engineer (because I don't have a contact myself). The (proxied)
>>> response from the engineer was that they aren't receiving any announcements
>>> for these routes to AS701, and I would need to take it up with Baidu. I
>>> guess I would like to understand if that seems reasonable to people since
>>> it is my presumption that Baidu would return and say something similar
>>> (that they advertise their routes to their peers correctly and to take it
>>> up with Verizon). To me, it seems like there is clearly a failing in one of
>>> Verizon's peers where they are not advertising or accepting this route
>>> correctly, but that it would be incumbent on Verizon to do the legwork to
>>> fix it since they are the ones who know their peering agreements and have
>>> these contacts. Unfortunately it seems like policy that Verizon pushes any
>>> issues that aren't internal routing issues to an external party, but surely
>>> they have a responsibility to maintain their peering and routes to external
>>> services as well. In other words, this type of buckpassing does not seem
>>> right to me (and I've heard it from them on other routing issues before),
>>> especially given that they are the ones empowered to fix it. Any thoughts?
>>>
>>> (As it happens, pan.baidu.com now resolves to an IP range that is
>>> routable by Verizon, but it could always revert, and it seems like Verizon
>>> should have these routes regardless.)
>>>
>>> Thanks.
>>>
>>> On Fri, Jun 24, 2022 at 7:41 AM Matthew Huff  wrote:
>>>
 From my limited vantage point it appears that there is some issue
 between Verizon & Baidu. Baidu has 182.61.0.0/16 registered, but is
 only advertising pieces of it globally (or at least from what I can see).
 In our tables,we are receiving none from Verizon of  the subnets that are
 advertised directly from Baidu (origin AS of 38365). The few within that
 registered range that have a different origin AS are coming to us from
 Verizon. For example:



 *>   182.61.0.0/19144.121.203.1410 46887
 3356 4134 58466 38365 i

 *>   182.61.0.0/18144.121.203.1410 46887
 6461 4134 58466 38365 38365 i

 *>   182.61.32.0/19   144.121.203.1410 46887
 3356 4134 58466 38365 i

 *>   182.61.64.0/18   204.148.121.2210 701
 6453 55967 i

 *182.61.128.0/23  204.148.121.2210 701
 4134 4134 4134 4134 4134 58540 ?

 *>   

Re: Mystery MAC address

[Christopher Morrow]

mac addresses can be lies... and they can repeat... joy!


On Fri, Jul 8, 2022 at 12:22 PM JoeSox  wrote:

> Hello,
>
> I have something I have never seen before and was wondering if anyone in
> the community has seen something like this?
>
> So some active directory accounts are getting locked intermittently and I
> had to do some sniffing and I have an IP address showing up in a non-used
> subnet 10.1.2.x
> And it shows an unrecognized MAC address. This virtual machine is in a
> Nutanix environment.
>
> I am trying to figure this out without bringing in paid outside help.
> Thanks in advance for any responses.
> c2:ea:e4:c5:57:e6
> is the MAC in question. I don't fully understand this request. 10.1.2.18
> is the mystery ip that doesn't ping, 10.1.3.9 is the DC.
> AD Audit provides nonexistent machines making the requests and even blank.
> "User account 'Administrator' was locked from computer ''."
>
> [image: image.png]
>
> --
> Thank You,
> Joe
>

Re: Congrats to AS701

[Christopher Morrow]

On Mon, Jun 13, 2022 at 12:00 PM Justin Streiner 
wrote:

> I might call Verizon and ask about v6 availability as I periodically do.
> I'll check if I see anything different on my gear later today.  I have a
> GPON business service with static IPv4 at one location and an older BPON
> business service with static IPv4 in another location.
>
>
As a short and not totally complete update to this problem... A 'long time
listener, first time caller' sort of person
noted to me off-list that:
  "Hey, once upon a time I dealt with hardware/vendor things... and we
wouldn't send 'RA type' packets (solicits/etc)
down the customer leg UNLESS they had already sent a
RouterSolicitation... on the BNG platform."

So... I copy/pasta'd some comcast facing config and.. low and behold my
link sends me a /56 if I ask for one via PD!
for  I can't personally use
the v6 (yet) here, but this is super encouraging!

Perhaps this is 'CPE configuration away' from working in a bunch more
places?

-chris


> Thank you
> jms
>
> On Mon, Jun 13, 2022 at 11:18 AM Nimrod Levy  wrote:
>
>> Also, it doesn't seem to be enabled on ports that have static ipv4
>>
>> but progress is progress. we'll take it.
>>
>> Nimrod
>>
>>
>> On Mon, Jun 13, 2022 at 11:17 AM Matthew Huff  wrote:
>>
>>> Still no IPv6 in Westchester County, NY ☹
>>>
>>>
>>>
>>> Great sign though, maybe NY will get it eventually
>>>
>>>
>>>
>>> *From:* NANOG  * On Behalf Of *Joe
>>> Loiacono
>>> *Sent:* Monday, June 13, 2022 10:55 AM
>>> *To:* nanog@nanog.org
>>> *Subject:* Re: Congrats to AS701
>>>
>>>
>>>
>>> FiOS from Maryland (anonymized):
>>>
>>> enp3s0: flags=4163  mtu 1500
>>> inet 192.168.1.164  netmask 255.255.255.0  broadcast
>>> 192.168.1.255
>>> inet6 fe80::b104:8f4d:e5b2:e13b  prefixlen 64  scopeid 0x20
>>> inet6 2600:4040:b27f:cb00:a9b1:5f59::  prefixlen 64
>>> scopeid 0x0
>>> inet6 2600:4040:b27f:cb00:24a8:7b31::  prefixlen 64
>>> scopeid 0x0
>>> inet6 2600:4040:b27f:cb00:e1b6:8b83::  prefixlen 64
>>> scopeid 0x0
>>> ether d0:67:e5:23:ec:fe  txqueuelen 1000  (Ethernet)
>>> RX packets 2518066  bytes 1448982813 (1.4 GB)
>>> RX errors 0  dropped 0  overruns 0  frame 0
>>> TX packets 2157395  bytes 260073952 (260.0 MB)
>>> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>>
>>> a@b:~$ ping 2607:f8b0:4004:c09::6a
>>> PING 2607:f8b0:4004:c09::6a(2607:f8b0:4004:c09::6a) 56 data bytes
>>> 64 bytes from 2607:f8b0:4004:c09::6a: icmp_seq=1 ttl=59 time=24.0 ms
>>> 64 bytes from 2607:f8b0:4004:c09::6a: icmp_seq=2 ttl=59 time=17.6 ms
>>> 64 bytes from 2607:f8b0:4004:c09::6a: icmp_seq=3 ttl=59 time=20.4 ms
>>> 64 bytes from 2607:f8b0:4004:c09::6a: icmp_seq=4 ttl=59 time=23.4 ms
>>> ^C
>>> --- 2607:f8b0:4004:c09::6a ping statistics ---
>>> 4 packets transmitted, 4 received, 0% packet loss, time 3004ms
>>> rtt min/avg/max/mdev = 17.618/21.351/23.983/2.555 ms
>>>
>>>
>>>
>>> On 6/12/2022 1:55 PM, Christopher Morrow wrote:
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Jun 11, 2022 at 11:03 PM Darrel Lewis (darlewis) <
>>> darle...@cisco.com> wrote:
>>>
>>> I, for one, am having a hard time finding the proper words to express
>>> the joy that I am feeling at this momentous moment!
>>>
>>>
>>>
>>>
>>>
>>> It's quite amazing, I think... that it's taken so long to get to
>>> deployment you can actually see on the fios plant :)
>>>
>>> I'd note I can't see the below on my homestead, but I can at a
>>> relative's (where the ifconfig data is from).
>>>
>>> I also can't tell if the upstream will PD a block to the downstream...
>>> and the VZ CPE is 'not something I want to fiddle with',
>>>
>>> because everytime I have tried at my house I've just taken it out behind
>>> the woodshed with a maul... and replaced it with
>>>
>>> something I CAN configure successfully. (plus.. don't want that TR 069
>>> in my home...)
>>>
>>>
>>>
>>> -chris
>>>
>>>
>>>
>>> -Darrel
>>>
>>>
>>>
>>> On Jun 11, 2022, at 7:05 PM, Christopher Morrow 
>>> wrote:
>>>
>>> 
>>>
>>>
>>>
>>> Looks like FIOS customers may be getting ipv6 deployed toward them,
>>> finally:
>>>
>>> ifconfig snippet from local machine:
>>> inet6 2600:4040:2001:2200:73d2:6bcc:1e6b:43a1  prefixlen 64
>>>  scopeid 0x0
>>> inet6 2600:4040:2001:2200:e87:bf36:b6cb:6ce1  prefixlen 64
>>>  scopeid 0x0
>>>
>>>
>>>
>>> ping attempt:
>>>
>>>   64 bytes from bh-in-f106.1e100.net (2607:f8b0:4004:c09::6a):
>>> icmp_seq=1 ttl=59 time=8.71 ms
>>>
>>>
>>>
>>> 8ms from mclean, va to ashburn, va isn't wondrous, but at least it's
>>> ipv6 (and marginally faster than ipv4)
>>>
>>>
>>>
>>> Congrats to the 701 folk for deploying more widely!
>>>
>>>   (note: I don't know exactly when this started, nor how wide it really
>>> is, but progress here is welcomed by myself at least :) )
>>>
>>> -chris
>>>
>>>

Re: Bgpmon alternative

[Christopher Morrow]

One problem, I have at least, is that all of the 'service I can pay
for/signup for' have odd scaling problems on pricing :( and on top of that
are extra noisy :( and don't tell me how they make any particular judgement
:(

So, they are all, effectively, a loud blackbox that's very expensive :(

Having a solution I can both run myself and hack on to make work to my
liking would be quite nice.
(like bgpalerter)

On Wed, Jun 15, 2022 at 1:20 PM Randy Bush  wrote:

> > I recommend taking a look at
> > https://github.com/nttgin/BGPalerter
>
> i love it.  thanks massimo.
>
> randy
>
> ---
> ra...@psg.com
> `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
> signatures are back, thanks to dmarc header butchery
>

Re: [Story] When IPv6 Fixes IPv4 Peering Issues

[Christopher Morrow]

Curious to know if the 'saved the day' was really 'fell into a different
rate-limit bucket' for UDP by address family :)

On Mon, Jun 13, 2022 at 10:53 AM Jared Mauch  wrote:

>
>
> > On Jun 13, 2022, at 10:25 AM, Brielle  wrote:
> >
> > I quickly reconfigured the Cys WireGuard node to connect to the Den node
> over IPv6 and, after WireGuard did its magic dynamically reconfiguring
> endpoints, suddenly the connection was back up and routing at full speed.
> Hell yeah!
> >
> > So, moral / TLDR of the story?
> >
> > Don't discount taking the time to set up IPv6, even if it's just for
> your important devices. Also, WireGuard > IPsec.
>
> This is great to hear.  I know that many things will operate better in
> IPv6 land vs IPv4 land as in IPv4 land there’s a lot of port-based
> filtering that happens in networks which isn’t the same in IPv6-land.
>
> Super glad to hear that IPv6 saved the day for you!
>
> - Jared

Re: Congrats to AS701

[Christopher Morrow]

On Sat, Jun 11, 2022 at 11:03 PM Darrel Lewis (darlewis) 
wrote:

> I, for one, am having a hard time finding the proper words to express the
> joy that I am feeling at this momentous moment!
>
>
It's quite amazing, I think... that it's taken so long to get to deployment
you can actually see on the fios plant :)
I'd note I can't see the below on my homestead, but I can at a relative's
(where the ifconfig data is from).

I also can't tell if the upstream will PD a block to the downstream... and
the VZ CPE is 'not something I want to fiddle with',
because everytime I have tried at my house I've just taken it out behind
the woodshed with a maul... and replaced it with
something I CAN configure successfully. (plus.. don't want that TR 069 in
my home...)

-chris


> -Darrel
>
> On Jun 11, 2022, at 7:05 PM, Christopher Morrow 
> wrote:
>
> 
>
> Looks like FIOS customers may be getting ipv6 deployed toward them,
> finally:
>
> ifconfig snippet from local machine:
> inet6 2600:4040:2001:2200:73d2:6bcc:1e6b:43a1  prefixlen 64
>  scopeid 0x0
> inet6 2600:4040:2001:2200:e87:bf36:b6cb:6ce1  prefixlen 64
>  scopeid 0x0
>
> ping attempt:
>   64 bytes from bh-in-f106.1e100.net (2607:f8b0:4004:c09::6a): icmp_seq=1
> ttl=59 time=8.71 ms
>
> 8ms from mclean, va to ashburn, va isn't wondrous, but at least it's ipv6
> (and marginally faster than ipv4)
>
> Congrats to the 701 folk for deploying more widely!
>   (note: I don't know exactly when this started, nor how wide it really
> is, but progress here is welcomed by myself at least :) )
> -chris
>
>

Fwd: Congrats to AS701

[Christopher Morrow]

Looks like FIOS customers may be getting ipv6 deployed toward them, finally:

ifconfig snippet from local machine:
inet6 2600:4040:2001:2200:73d2:6bcc:1e6b:43a1  prefixlen 64
 scopeid 0x0
inet6 2600:4040:2001:2200:e87:bf36:b6cb:6ce1  prefixlen 64  scopeid
0x0

ping attempt:
  64 bytes from bh-in-f106.1e100.net (2607:f8b0:4004:c09::6a): icmp_seq=1
ttl=59 time=8.71 ms

8ms from mclean, va to ashburn, va isn't wondrous, but at least it's ipv6
(and marginally faster than ipv4)

Congrats to the 701 folk for deploying more widely!
  (note: I don't know exactly when this started, nor how wide it really is,
but progress here is welcomed by myself at least :) )
-chris

Re: Cogent & Google reachability stable?

[Christopher Morrow]

Are we discussing direct connectivity between 15169/174?
or via a third party(ies)? I ask, because i looks like RouteViews has, in:

http://archive.routeviews.org/bgpdata/2020.07/UPDATES/updates.20200715.0345.bz2

at last this bit of clues:
BGP4MP_ET|1594784883.404691|A|91.218.184.60|49788|35.213.0.0/17|49788 174
6453 15169|IGP|91.218.184.60|0|0|174:21100 174:22010|NAG||
BGP4MP_ET|1594784883.404691|A|91.218.184.60|49788|35.216.0.0/17|49788 174
6453 15169|IGP|91.218.184.60|0|0|174:21100 174:22010|NAG||
BGP4MP_ET|1594784883.404691|A|91.218.184.60|49788|35.206.4.0/24|49788 174
6453 15169|IGP|91.218.184.60|0|0|174:21100 174:22010|NAG||
BGP4MP_ET|1594784912.621864|A|195.208.112.161|3277|35.206.4.0/24|3277 3267
174 6453 15169|IGP|195.208.112.161|0|0|3277:39710|NAG||
BGP4MP_ET|1594784912.621864|A|195.208.112.161|3277|35.213.0.0/17|3277 3267
174 6453 15169|IGP|195.208.112.161|0|0|3277:39710|NAG||
BGP4MP_ET|1594784912.621864|A|195.208.112.161|3277|35.216.0.0/17|3277 3267
174 6453 15169|IGP|195.208.112.161|0|0|3277:39710|NAG||

I didn't go digging much more than that, but I bet looking at each day
before the 15th July 2020 might tell you when routes started to show up
with that type of path.
So, 'since last july' I guess is close to the place where 174 started
seeing 15169 across alternate paths.

On Wed, Jun 8, 2022 at 9:08 PM Jay Hennigan  wrote:

> On 6/8/22 15:41, David Hubbard wrote:
> > Appears HE (ASN6939) is still
> > unreachable though…  I feel like less entities are single homed to HE,
> > but it would still be a calculated risk.
>
> HE is the 800-pound gorilla of IPv6. I would be leery of a carrier
> without reachability to AS6939.
>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Christopher Morrow]

On Mon, Jun 6, 2022 at 4:37 PM Michael Thomas  wrote:

>
> On 6/6/22 12:00 PM, Christopher Morrow wrote:
> > is gatekeeping what users MIGHT do, and/or deciding based on corner
> > cases helpful to this discussion?
> > (this isn't meant as a note directly to dorn, just a convenient place
> > to interject)
> >
> > Aside from planning based on a formula like Jason Livingood's plan...
> > OR based on build/deploy/upgrade costs into pricing.
> > most of the rest of the conversation here sounds like gatekeeping:
> >   "Well, who needs that anyway?"
>
>
> One takeaway for me on this thread is that once you've installed fiber
> the difference in cost between 1G and 100M is not very big if at all.
> That makes a good case for just doing it for future proofing.
>
>
probably true, but also docsis seems perfectly happy to do 1gbps (or more,
see atl comcast deployments of ~10 yrs ago?)
I expect that because of design things in cable plants you need 'moar
headends', but ok.

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Christopher Morrow]

is gatekeeping what users MIGHT do, and/or deciding based on corner cases
helpful to this discussion?
(this isn't meant as a note directly to dorn, just a convenient place to
interject)

Aside from planning based on a formula like Jason Livingood's plan... OR
based on build/deploy/upgrade costs into pricing.
most of the rest of the conversation here sounds like gatekeeping:
  "Well, who needs that anyway?"

or:
  https://en.wikipedia.org/wiki/Reductio_ad_absurdum - in the form of:
"Well who can even use 8k anyway?" or similar.

-chris

On Mon, Jun 6, 2022 at 2:45 PM Dorn Hetzel  wrote:

> Agreed, even with a 16TB drive, that's only 16000*8 ~= 128000 seconds of
> 1-gigabit download rate (under 36 hours) :)
>
> On Mon, Jun 6, 2022 at 2:26 PM Chris Adams  wrote:
>
>> Once upon a time, Michael Thomas  said:
>> > I meant downloads as in gigantic games. If you give them more
>> > bandwidth it just encourages the game makes to build bigger game
>> > downloads.
>>
>> I don't buy that - users are still constrained on storage, especially on
>> consoles.
>> --
>> Chris Adams 
>>
>

Re: Google Fi IPs

[Christopher Morrow]

On Thu, Jun 2, 2022 at 12:55 PM Christopher Morrow 
wrote:

>
>
> On Thu, Jun 2, 2022 at 12:22 PM John Von Essen  wrote:
>
>> Feel free to contact me off-list if your associated with Google Fi.
>>
>> I’m trying to narrow down some IP abuse that I believe is coming from
>> Google Fi mobile devices. The IPs are all coming up as generic Google LLC
>> in whois, and they dont have any reverse DNS. I’m trying to see how I can
>> confirm that these are IPs related to the Google Fi service/network, or
>> just random Google Clould IPs
>>
>> Here are some sample IPs:
>>
>> 35.187.133.202
>> 35.187.133.204
>> 35.187.133.200
>> 34.116.22.76
>> 34.116.22.74
>> 34.116.22.72
>> 107.178.194.231
>> 107.178.194.233
>> 107.178.194.235
>> 107.178.193.10
>> 107.178.193.12
>>
>>
> all of these are very clearly marked out in whois as google-cloud ips:
> NetRange:   35.184.0.0 - 35.191.255.255
> CIDR:   35.184.0.0/13
> NetName:GOOGLE-CLOUD
>
> NetRange:   34.64.0.0 - 34.127.255.255
> CIDR:   34.64.0.0/10
> NetName:GOOGL-2
>
> NetRange:   107.178.192.0 - 107.178.255.255
> CIDR:   107.178.192.0/18
> NetName:GOOGLE-CLOUD
>
> $ for d in $(cat /tmp/x); do host $d; done
> Host 202.133.187.35.in-addr.arpa not found: 2(SERVFAIL)
> Host 204.133.187.35.in-addr.arpa not found: 2(SERVFAIL)
> Host 200.133.187.35.in-addr.arpa not found: 2(SERVFAIL)
> Host 76.22.116.34.in-addr.arpa not found: 2(SERVFAIL)
> Host 74.22.116.34.in-addr.arpa not found: 2(SERVFAIL)
> Host 72.22.116.34.in-addr.arpa not found: 2(SERVFAIL)
> 231.194.178.107.in-addr.arpa domain name pointer
> 231.194.178.107.gae.googleusercontent.com.
> 233.194.178.107.in-addr.arpa domain name pointer
> 233.194.178.107.gae.googleusercontent.com.
> 235.194.178.107.in-addr.arpa domain name pointer
> 235.194.178.107.gae.googleusercontent.com.
> 10.193.178.107.in-addr.arpa domain name pointer
> 10.193.178.107.gae.googleusercontent.com.
> 12.193.178.107.in-addr.arpa domain name pointer
> 12.193.178.107.gae.googleusercontent.com.
>
> I'll see about fixing the missing ptrs... but... 'it's all cloud man!'
>
>

fixing this is in progress.
Also, almost certainly 'fi' shows up as whatever is the address set
assigned to:
  GOOGL-4 - NetName:GOOGLE-VPN


> Thanks
>> John
>>
>>

Re: Google Fi IPs

[Christopher Morrow]

On Thu, Jun 2, 2022 at 12:22 PM John Von Essen  wrote:

> Feel free to contact me off-list if your associated with Google Fi.
>
> I’m trying to narrow down some IP abuse that I believe is coming from
> Google Fi mobile devices. The IPs are all coming up as generic Google LLC
> in whois, and they dont have any reverse DNS. I’m trying to see how I can
> confirm that these are IPs related to the Google Fi service/network, or
> just random Google Clould IPs
>
> Here are some sample IPs:
>
> 35.187.133.202
> 35.187.133.204
> 35.187.133.200
> 34.116.22.76
> 34.116.22.74
> 34.116.22.72
> 107.178.194.231
> 107.178.194.233
> 107.178.194.235
> 107.178.193.10
> 107.178.193.12
>
>
all of these are very clearly marked out in whois as google-cloud ips:
NetRange:   35.184.0.0 - 35.191.255.255
CIDR:   35.184.0.0/13
NetName:GOOGLE-CLOUD

NetRange:   34.64.0.0 - 34.127.255.255
CIDR:   34.64.0.0/10
NetName:GOOGL-2

NetRange:   107.178.192.0 - 107.178.255.255
CIDR:   107.178.192.0/18
NetName:GOOGLE-CLOUD

$ for d in $(cat /tmp/x); do host $d; done
Host 202.133.187.35.in-addr.arpa not found: 2(SERVFAIL)
Host 204.133.187.35.in-addr.arpa not found: 2(SERVFAIL)
Host 200.133.187.35.in-addr.arpa not found: 2(SERVFAIL)
Host 76.22.116.34.in-addr.arpa not found: 2(SERVFAIL)
Host 74.22.116.34.in-addr.arpa not found: 2(SERVFAIL)
Host 72.22.116.34.in-addr.arpa not found: 2(SERVFAIL)
231.194.178.107.in-addr.arpa domain name pointer
231.194.178.107.gae.googleusercontent.com.
233.194.178.107.in-addr.arpa domain name pointer
233.194.178.107.gae.googleusercontent.com.
235.194.178.107.in-addr.arpa domain name pointer
235.194.178.107.gae.googleusercontent.com.
10.193.178.107.in-addr.arpa domain name pointer
10.193.178.107.gae.googleusercontent.com.
12.193.178.107.in-addr.arpa domain name pointer
12.193.178.107.gae.googleusercontent.com.

I'll see about fixing the missing ptrs... but... 'it's all cloud man!'


> Thanks
> John
>
>

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Christopher Morrow]

On Wed, Jun 1, 2022 at 1:10 PM Seth Mattinen  wrote:

> On 5/23/22 12:00 PM, Michael Thomas wrote:
> >
> > On 5/23/22 11:49 AM, Aaron Wendel wrote:
> >> The Fiber Broadband Association estimates that the average US
> >> household will need more than a gig within 5 years.  Why not just jump
> >> it to a gig or more?
> >
> >
> > Really? What is the average household doing to use up a gig worth of
> > bandwidth?
>
>
this seems like the wrong question to ask. Or at least a short-sighted
question.
One question to ask is:
  "If I have to upgrade from X to 1gbps for my infrastructure over the next
5 years, what's the outlay in capex/opex?"

followed by:
  "What's my cost recovery plan now that I know what the bill will be?"

Some of that might be USF, some might be fees from subscribers, etc.

Being a gatekeeper to what folk can do at home seems ... not
terrific, though.


> I want decent upload speeds for offsite backups of my home NAS. But no,
> upload is usually some pitiful fraction of download. The local cable
>

having symmetric speeds over 20mbps certainly is nice, as a user living in
that world.

Re: Verizon NJ <-> Hetzner DE, routes via LA?

[Christopher Morrow]

On Wed, May 18, 2022 at 2:29 PM Tomas Jonsson  wrote:

> Since yesterday, I've started to see an increase in latency between my
> self in NJ on Verizon FIOS and Hetzner in DE. Even using Verizon:s
> looking glass is giving me 250ms. This is an increase of about 150ms
> (Seems to be true for most of the US East Coast)
> A traceroute seems to tell me that the traffic is routed via LA, which
> could explain the increase in latency.
>
> Traceroute from Verizon looking glass page, sourcing Newark
> https://www.verizon.com/business/why-verizon/looking-glass/
>
> traceroute to 144.76.94.10 (144.76.94.10), 30 hops max, 52 byte packets
>   1  0.et-10-3-0.GW7.LAX15.ALTER.NET (140.222.235.147)  61.052 ms  61.522
> ms  61.063 ms
>   2  152.179.21.22 (152.179.21.22)  158.708 ms  158.683 ms  158.681 ms
>   3  * * pd900ccde.dip0.t-ipconnect.de (217.0.204.222)  263.187 ms
>

that's odd to see, I had thought DTAG was a peer of 701 at some point.
maybe that's an incorrect 15 yr old memory :( (or maybe things changed!)

it happens that from IAD area ... same path via LAX :(
It also seems strange that 3320 would ONLY appear in LAX... maybe their
east-coast
landings are feeling under the weather?

  4  62.157.248.138 (62.157.248.138)  249.071 ms  248.570 ms  248.737 ms
>   5  * * *
>   6  ex9k2.dc10.fsn1.hetzner.com (213.239.229.62)  250.333 ms  252.488 ms
>   250.232 ms
>
>
> Does anyone have any more insight? (Verizon status pages says everything
> is fine, ofc)
>

the link you see above is a customer link ,so.. sure, everything for VZ is
fine :)
their customer though MAY be having a sad day.

Re: AT, Comcast, Verizon, Others Commit to Low-Income Broadband Program

[Christopher Morrow]

On Mon, May 9, 2022 at 10:32 AM Sean Donelan  wrote:

>
> AT, Comcast, Verizon, Others Commit to Low-Income Broadband Program
> Providers will help offer high-speed internet to millions of households
> under the infrastructure law
>
>
> https://www.wsj.com/articles/internet-providers-commit-to-low-income-broadband-program-under-infrastructure-law-11652086801
>
>
> Waiting to see what the catch-22 is.  In the past, large providers have
> imposed various dark patterns which raised the cost, and made discount
> programs difficult to find.  Instead directing people to more expensive
> services or requiring extra costs.
>
>
One would hope[*] that the shame caused by various articles showing
children sitting outside their schools to
use wifi instead of home wifi/internet coupled with school systems
getting/donating/using mifi-equivalent units
to dis-advantaged folks would make this less likely to happen.

-chris
* "Hope is not a strategy" :(

Previous 2021 program
>
> https://arstechnica.com/tech-policy/2021/05/verizon-uses-fcc-pandemic-subsidy-to-upsell-customers-to-pricier-plans/
>
>

Re: how networking happens in Hawaii

[Christopher Morrow]

This reads a lot like dsl wars between ilecs and clecs in the late 90s and
early 2ks.

Great times? Or Greatest times?

On Fri, Apr 29, 2022, 15:44 scott via NANOG  wrote:

>
>
> I thought I'd put a smile on your faces for Friday.  This is how
> networking happens in Hawaii...
>
>
> https://www.civilbeat.org/2022/04/thousands-of-hawaiians-could-lose-phone-and-internet-service-amid-bankruptcy-dispute
>
>
> --
> "State regulators have opened an emergency investigation of Sandwich
> Isles Communications..."
>
> "The investigation comes as Sandwich Isles is apparently blocking access
> to its telecom infrastructure to another provider, Hawaiian Telcom,
> alleging trespass, filing police reports and putting customer phone and
> internet service at risk."
>
> "Sandwich Isles Communications is an Oahu-based telephone company
> founded in 1995 with a mission to provide communication services to
> Native Hawaiians living on homesteads"
>
> "In 2015, founder Albert Hee was convicted of criminal tax fraud...Hee
> was sentenced in 2016 to 46 months in prison."
>
> "With federal backing, the company built the Paniolo Network, a web of
> undersea and terrestrial fiber optic cables."
>
> "...a bankruptcy trustee ordered the sale of the Paniolo Network to
> Hawaiian Telcom."
>
> "Hawaiian Telcom says Sandwich Isles has removed, destroyed or tampered
> with Hawaiian Telcom locks on perimeter fences surrounding buildings
> purchased by Hawaiian Telcom. And that Sandwich Isles has installed its
> own locks and devices on buildings and premises owned by Hawaiian
> Telcom, as well as welding shut access gates. The company also says
> Sandwich Isles has made multiple false police reports alleging Hawaiian
> Telcom is trespassing on its property."
>
> "Al Hee was requesting that Hawaiian Telcom’s lock on its Paniolo
> Building at Laiopua on the Big Island be replaced. Otherwise, Hee said
> he would call the police."
>
> "In a Sept. 11 letter to customers, Sandwich Isles blamed the situation
> on Hawaiian Telcom."
> --
>
>
> When your brother is very connected politically I guess one feels
> invincible...
>
> "...welding shut access gates..."  hahaha!  Insanity!
>
> There're other 'outages' that didn't make the article.  Repeated fiber
> damaged off shore, etc.
>
>
> scott
>

Re: RFC 9225 - Software Defects Considered Harmful

[Christopher Morrow]

On Fri, Apr 1, 2022 at 3:12 PM Eric Kuhnke  wrote:

> If there's a bug in an ISP's implementation of RFC2549 carrier
> 'equipment', is that considered a software bug, hardware, or subject of
> ornithological research?
>
>
Certainly that would depend on what part of the pipeline was involved, no?


>
>
> On Fri, 1 Apr 2022 at 10:40, Job Snijders via NANOG 
> wrote:
>
>> Hi all,
>>
>> It's super official now: no more software bugs in networking gear.
>> Sorry it took so long to document what the best current practise is!
>>
>> Kind regards,
>>
>> Job / Chris / Remco
>>
>> - Forwarded message from rfc-edi...@rfc-editor.org -
>> Date: Fri,  1 Apr 2022 10:17:37 -0700 (PDT)
>> From: rfc-edi...@rfc-editor.org
>> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
>> Cc: drafts-update-...@iana.org, rfc-edi...@rfc-editor.org
>> Subject: RFC 9225 on Software Defects Considered Harmful
>>
>> A new Request for Comments is now available in online RFC libraries.
>>
>> RFC 9225
>>
>> Title:  Software Defects Considered Harmful
>> Author: J. Snijders,
>> C. Morrow,
>> R. van Mook
>> Status: Informational
>> Stream: Independent
>> Date:   1 April 2022
>> Mailbox:j...@fastly.com,
>> morr...@ops-netman.net,
>> re...@asteroidhq.com
>> Pages:  6
>> Updates/Obsoletes/SeeAlso:   None
>>
>> I-D Tag:draft-dont-write-bugs-00.txt
>>
>> URL:https://www.rfc-editor.org/info/rfc9225
>> DOI:10.17487/RFC9225
>>
>> This document discourages the practice of introducing software
>> defects in general and in network protocol implementations
>> specifically.  Software defects are one of the largest cost drivers
>> for the networking industry.  This document is intended to clarify
>> the best current practice in this regard.
>>
>>
>> INFORMATIONAL: This memo provides information for the Internet community.
>> It does not specify an Internet standard of any kind. Distribution of
>> this memo is unlimited.
>>
>> This announcement is sent to the IETF-Announce and rfc-dist lists.
>> To subscribe or unsubscribe, see
>>   https://www.ietf.org/mailman/listinfo/ietf-announce
>>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>
>> For searching the RFC series, see https://www.rfc-editor.org/search
>> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>>
>> Requests for special distribution should be addressed to either the
>> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
>> specifically noted otherwise on the RFC itself, all RFCs are for
>> unlimited distribution.
>>
>> The RFC Editor Team
>> Association Management Solutions, LLC
>>
>> ___
>> IETF-Announce mailing list
>> ietf-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>
>> - End forwarded message -
>>
>

Re: V6 still not supported

[Christopher Morrow]

On Wed, Mar 30, 2022 at 1:21 PM John Kristoff  wrote:

> On Wed, 30 Mar 2022 18:36:24 +0200
> Jared Brown  wrote:
>
> >   IPv4 address blocks have a fixed one-time cost, not an ongoing
> > $X/month cost.
>
> From an RIR perhaps, but when demand changes for your available pool,
> what happens downstream?
>
> When you rent servers from providers, unless you bring your
> own address space, the invoice includes the cost of one or more IPv4
> addresses, often with the option to rent additional IPv4 addresses on a
> per month basis.  Just this week I received notice of a $2/VM
> price increase from one provider.  They stated "demand for IP
> address has caused a shortage and increased prices".
>
>
also, you know.. it's a monetizable asset now, so ... why not just charge
rent? :)
I mean, in like 12 months you can pay for 2 ips if you charge 2$/month /
ip.

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

[Christopher Morrow]

On Sat, Mar 26, 2022, 21:42 John Gilmore  wrote:

>
> Today Google is documenting to its cloud customers that they should use
> 240/4 for internal networks.  (Read draft-schoen-intarea-unicast-240 for
> the citation.)  We have received inquiries from two other huge Internet
> companies, which are investigating or already using 240/4 as private
> IPv4 address space.
>

I think the advice in the draft, and on the quoted page of Google cloud
docs is that you can use whatever address space you want for your voc
network. I think it also says that choosing poorly could make portions if
the internet unreachable.

I don't see that the docs specify usage of 240/4 though.

>

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

[Christopher Morrow]

1) please join the list properly and stop replying to the digests.
(note there have been many folks asking you to do this, disconnected
message/new-threads
are super super super annoying and remove the parts of the discussion from
a coherent thread)

On Fri, Mar 25, 2022 at 12:25 PM Abraham Y. Chen  wrote:




> 1)" ... 240/4 is way more effort than its proponents want to believe
> and even if it were reclassified effectively as GUA, it doesn’t buy all
> that much life for IPv4. ...   ": Perhaps you have not bothered to scan
> through a two page whitepaper (URL below, again) that I submitted a week or
> so ago? It promises simple implementation and significant increase of
> assignable IPv4 addresses, even extendable to the similar size of IPv6 if
> we could forgo our mentality about the IP addresses as "Personal
> Properties", by switching to treat them as "Natural Resources".
>
>   https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>

This paper is super thin on any reasonable level of detail, and seems to
wholly miss the mark on ipv4 usage patterns.

Re: ISP data collection from home routers

[Christopher Morrow]

View of traffic into the ISP with Netflow/etc is very different than all on
my lan traffic.

Tr-069 is bad news.

On Thu, Mar 24, 2022, 15:53 Tom Beecher  wrote:

> You don't even have to use their equipment. My provider at home is Charter
> / Spectrum. I own my own cable modem  / router ,they have no equipment in
> my home. Their privacy policy is pretty standard.
>
> Essentially :
> - Anything they can see that I transmit they will collect.
> - Anything they can see when I use their apps , even if I'm not on their
> network, they will collect.
> - They will use that information for their technical and business reasons,
> whatever they want.
> - I am very limited in what I can request that they don't collect or use.
>
> None of this is new in the US. I think more people care about this than we
> think, but people don't really have an option to vote with their wallets.
>
> On Thu, Mar 24, 2022 at 6:45 AM Giovane C. M. Moura via NANOG <
> nanog@nanog.org> wrote:
>
>> Hello there,
>>
>> Several years ago, a friend of mine was working for a large telco and
>> his job was to detect which clients had the worst networking experience.
>>
>> To do that, the telco had this hadoop cluster, where it collected _tons_
>> of data from home users routers, and his job was to use ML to tell the
>> signal from the noise.
>>
>>   I remember seeing a sample csv from this data, which contained
>> _thousands_ of data fields (features) from each client.
>>
>> I was _shocked_ by the amount of (meta)data they are able to pull from
>> home routers. These even included your wifi network name _and_ password!
>> (it's been several years since then).
>>
>> And home users are _completely_ unaware of this.
>>
>> So my question to you folks is:
>>
>> - What's the policy regulations on this? I don't remember the features
>> (thousands) but I'm pretty sure you could some profiling with it.
>>
>> - Is anyone aware of any public discussion on this? I have never seen it.
>>
>> Thanks,
>>
>> Giovane Moura
>>
>

Re: ISP data collection from home routers

[Christopher Morrow]

On Thu, Mar 24, 2022 at 10:04 AM Giovane C. M. Moura via NANOG <
nanog@nanog.org> wrote:

>
> > Who cares about the SSID???
>
> I don't remember the data model, but I remember that they retrieved data
> very often, multiple times a minute.
>
>
Please keep in mind that TR-069 (which in all likelihood is how the data
you remember captured was captured) provides
raw packet access to the customer side of the device.

yes, this is a problem, yes it's certainly been/being abused.
Yes the protocol is garbage and implementations are also garbage :(
see the, at least 1, blackhat/defcon presentations about TR-069 problems.

https://www.youtube.com/watch?v=XXhV7zpc6m8
https://www.geekzone.co.nz/forums.asp?forumid=49=214760_no=5
https://www.blackhatethicalhacking.com/news/multiple-backdoors-and-vulnerabilities-discovered-in-fiberhome-routers/

there's really no reason at all to have this exposed as it is :(

Re: V6 still not supported

[Christopher Morrow]

On Tue, Mar 22, 2022 at 5:36 PM Michael Thomas  wrote:

>
> On 3/22/22 5:45 AM, Randy Bush wrote:
>


> right would have had any better chance of being adopted? My experience
> with Cisco product managers at the time is that they couldn't give a
> shit about the technical aspects of an ipng. If their silicon forwarding
> couldn't handle it, they weren't interested unless customers were
>
>
Somewhere in this thread Randy sent a link to his ivtf
screed^H^H^H^H^H^Hposition-paper.
I think his point there was essentially: "Hey, vendors are coin operated,
they build what people
are asking for, if they are willing to pay AND if there are enough of them
paying"

Re: are underwater routers a thing?

[Christopher Morrow]

John's probably seen this but  I think it addresses power on cables and
branching nodes (which are just optical /roadm devices)

https://youtu.be/H9R4tznCNB0


On Thu, Mar 17, 2022, 22:40 John Levine  wrote:

> It appears that Jerry Cloe  said:
> >-=-=-=-=-=-
> >
> >it look like it was completely at sea, but it would kind of make sense
> >to leave them at sea if you could put a router there.
> >
> >First thing that comes to mind is power, how would you power them?
>
> Undersea cables have had power for repeaters since TAT-1 in 1956.  I
> think we can consider that to be a solved problem.
>
> R's,
> John
>

Re: Dropping support for the .ru top level domain

[Christopher Morrow]

https://mailman.nanog.org/pipermail/nanog/2022-March/217815.html

On Mon, Mar 14, 2022 at 11:29 AM Patrick Bryant  wrote:

> 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
> ru  nameserver = b.dns.ripn.net
> ru  nameserver = d.dns.ripn.net
> ru  nameserver = e.dns.ripn.net
> ru  nameserver = f.dns.ripn.net
>
> The impact of any action would take time (days) to propagate.
>
>

Re: Making Use of 240/4 NetBlock

[Christopher Morrow]

On Sun, Mar 13, 2022 at 7:55 PM William Herrin  wrote:

> On Sun, Mar 13, 2022 at 12:29 PM Christopher Morrow
>  wrote:
> > What's the actual proposal for 240/4?
> > Is it: "Make this usable by me on my /intranet/?"
> > Is it: "Make this usable across the internet between bespoke endpoints?"
> > Is it: "Make this usable for any services/users on the wider internet,
> treat it like any other unicast ipv4 address?"
>
> Hi Chris,
>
> I can't speak for anyone else but my proposal is: (A) do the
> standards-level activity which is common to all three proposals, (B)
> give the vendors a couple years to catch up to the new standard, and
> then (C) pick a next step based on what's then the operational
> reality.
>
> The standards-level activity common to all three proposals is:
>
> 1. Define 240/4 excluding 255.255.255.255/32 as unicast addresses (no
> longer "undefined" future use) but continue holding them in reserve.
> 2. Advise hardware and software vendors to treat 240/4 as unicast when
> configured by the user or received by protocol.
> 3. Stop.
>
>
ok, sounds interesting/ok to me :)
I was mostly wondering about the endgame, the 'reason' for the proposal(s)
that keep coming up.

One version of them is: "well, that's 16 /8's!!! think of the ipv4 market!"
(or similar)
I don't think it's particularly productive to wait on 16 /8's which really
are a 1.5 yr lengthening
of the v4 runway/landing-strip. I get that we'll be doing ipv4 things at
scale for at
least a decade more, but even the most generous reading of your 'do
standads, get
vendors, let rolllout happen'  is, I think at least 10 yrs away as well.

using the space intenrally kinda already works... having some standards
action that
said: "err, this is rfc1918-like space" would help internal uses. Not
having that means
that you are (as a deployer of 240/4 internally) constantly ~1 IANA/RIR
decision away
from not being able ot route to parts of the internet.

-chris

Re: Making Use of 240/4 NetBlock

[Christopher Morrow]

On Sun, Mar 13, 2022 at 10:39 AM William Herrin  wrote:

> On Sun, Mar 13, 2022 at 1:22 AM Joe Maimon  wrote:
> > The true dilemma is that any amelioration of IPv4 scarcity may indeed
> > contribute to further delaying mass global IPv6 adoption, regardless of
> > whose effort and time is involved.
>
>
What's the actual proposal for 240/4?
Is it: "Make this usable by me on my /intranet/?"
Is it: "Make this usable across the internet between bespoke endpoints?"
Is it: "Make this usable for any services/users on the wider internet,
treat it like any other unicast ipv4 address?"
Is it: "Something entirely different"

The first 2 probably already work today, if you take the time to control
the horizontal and vertical of your networking space.
The last is probably workable, given enough time to flush out all of the
endpoints which (today) probably treat 240/4 as 'special'.

So.. to move forward with 240/4 on the wider internet you'd need a bunch of
software / hardware updates, and time for those to rollout.
Then you'd need sacrificial lambs in the user and service endpoints.

All of this to regain ~16 /8's worth of space (presuming you could use
255/8?).
I think a /8 is 'free' on the internet for about a month, so 1.5 yrs of new
address allocations, terrific?

At the end of the day, again, almost all proposals to 'add more ipv4 space'
come down to 1 month per /8.
I think part of Jordi's point is:
  "Is that 1 month really worth the effort?
  is there a reason that all of the softare/hardware uplift and time to
deploy is not being spent on v6?"

At this point in our matrix timeline it seems to me that:
  "If you were going to deploy v6, you did... if you didn't oh, well..
eventually you will?"

I'd prefer to not have to deploy  in a rush or on timelines I can't
cointrol if I hadn't deployed already.
Will that timeline be 'soon' anytime soon? I don't know :( I think Grant's
"not until i'm long retired" guess
is as good as any though :(

-chris

Re: V6 still widely supported (was Re: CC: s to Non List Members,

[Christopher Morrow]

On Fri, Mar 11, 2022 at 4:16 PM Josh Luthman 
wrote:

> Verizon Wireless does have v6.  I see a 100.64/24 on my phone all the time.
>
>
wireless != wired/internet/fios/dsl

Verizon, as I noted elsewhere, in the wired network (as701 / 702 / 703,
mostly these days) supported v6 in ~2005 across the entire backbone(s).
This technology never seems to have trickled down to the residential
(consumer and small business) edge.


> On Fri, Mar 11, 2022 at 4:11 PM John Covici  wrote:
>
>> Verizon does not support ipv6 as far as I know, I have fios and they
>> said it was not supported.
>>
>> On Fri, 11 Mar 2022 15:20:48 -0500,
>> John Levine wrote:
>> >
>> > It appears that Joe Maimon  said:
>> > >higher penetration of native v6, I would restate that a bit more
>> > >conservatively as
>> > >
>> > >Google's statistics are likely a fair barometer for USA usage in the
>> > >large content provider arena which have a strong mobile representation.
>> >
>> > AT, Comcast, and Charter/Spectrum, the three largest cable companies,
>> have IPv6
>> > support.  I expect a lot of Google searches and Gmail messages come
>> from them, too.
>> >
>> > I think it's more accurate to say that large networks have looked at the
>> > costs and implemented IPv6.  Small networks, many of which have no need
>> > to expand beyond their existing IPv4 allocations, largely have not.
>> >
>> > Of course, there are a lot more small networks than large ones, even
>> though
>> > they don't necessarily represent many users, so guess who we hear from?
>> >
>> > R"s,
>> > John
>>
>> --
>> Your life is like a penny.  You're going to lose it.  The question is:
>> How do
>> you spend it?
>>
>>  John Covici wb2una
>>  cov...@ccs.covici.com
>>
>

Re: V6 still not supported

[Christopher Morrow]

not to echo cameron's comment too much, but...

On Thu, Mar 10, 2022 at 3:44 PM Josh Luthman 
wrote:

> >but nowadays, some are going all v6.
>
> Where is there v6 only services/content?
>
>>
>>
I don't think any of this matters, really.
Is deploying v6 doable? yes
Is deploying it going to cost some clams? probably? maybe?
Is it important to users? no? yes? maybe?

The point of all of this 'deploy v6' conversation is REALLY:
  "Hey, eventually, in the long term using v4 is going to get more expensive
and more inconvenient... probably."

Some folk have  taken the view that:
  "Do some work now, flush out the problems and be prepared so it's not an
emergency later"

some folk are waiting on everyone else (or enough everyone else) to flush
out the problems for them.
I don't see a lot of profit in trying to convince people that are on the
'meh, waiting on the  before v6 for me!'

-chris

btw, The year is 2022, verizon FIOS still has no actual v6 deployment...
In the year ~2005 AS701 was fully v6 capable.
In ~2009 the AS19262 edge was capable of ipv6. (think my chat with a
noc/eng person was pre-aurora... so 2009 seems right)
I guess not enough folk in AS701/19262/FIOS land are asking for v6? or
something?

Re: LEC copper removal from commercial properties

[Christopher Morrow]

On Thu, Feb 17, 2022 at 11:09 AM Anne P. Mitchell, Esq. 
wrote:

>
> https://docs.fcc.gov/public/attachments/FCC-19-72A1.docx
>
> It says nothing about this.  And certainly the FCC would not issue
> something with such a short date fuse;  that letter appears to be a scam
> using scare and pressure tactics. Perhaps they are looking to steal your
> copper.
>
>
laughable that anyone thinks: "remove all copper, swap to fiber by 8/2022"
is even close to a reasonable date/timeframe.

Re: junos config commit question

[Christopher Morrow]

On Fri, Feb 11, 2022 at 5:26 PM Ryan Hamel  wrote:

> If it's before committing the changes just run "top" to get back to the
> root of the configuration tree, then "rollback 0" to go back to the version
> before any changes were made, then just "exit" out.
>
> Ryan
>
>
> On Fri, Feb 11, 2022, 2:20 PM Lyndon Nerenberg (VE7TFX/VE6BBM) <
> lyn...@orthanc.ca> wrote:
>
>> On an EX4300 switch running JunOS 14.1 let's imagine I typed
>>
>> config
>> delete interfaces
>>
>>
you may ALSO be interested in the idea that you SHOULD be doing:
  configure exclusive
  fiddle
  fart
  oops!
  exit (safe to exit, your changes will get wiped out)

note that 'configure exclusive' means other people can't ALSO change the
config out from under you (and you have locked the config, so)


> before coming to my senses.  How am I supposed to back out of that
>> mess?  For the life of me, after a week of reading the 3000 page
>> reference manual, and endless DuckDuckGoing, I cannot see a simple
>> way of just abandoning the commit.  I've got to be missing something
>> stunningly obvious here because it's unthinkable that this functionality
>> doesn't exist.  Help?!?
>>
>> The only way out I can see is to drop into the shell, make an
>> uncompressed copy of juniper.conf.gz, then pop back into the config
>> editor and load that over top of the editor's config view.  Surely
>> there's a saner way of dealing with this.
>>
>> --lyndon
>>
>

Re: Authoritative Resources for Public DNS Pinging

[Christopher Morrow]

On Wed, Feb 9, 2022 at 2:10 PM Lady Benjamin Cannon of Glencoe 
wrote:

> ok that’s amazing.
>
> RFC1149 amazing.
>
>
> Side note, am I missing something obvious where I can’t just have hardware
> routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let
> the world ping the brains out of it?
>
>
I suspect that half the reason: "ping 8.8.8.8" (do not do this!) is used
is: "easy to remember 8.8.8.8"
and half is: "Well, that IP is well connected enough that you are
reasonably assured that: 'enough of the internet is up '" if it replies.

(maybe it's 75/25? or 80/20 not 5050... but you get my point)

Re: Authoritative Resources for Public DNS Pinging

[Christopher Morrow]

On Tue, Feb 8, 2022 at 4:05 PM Mike Hammett  wrote:

> Some people need a clue by four and I'm looking to build my collection of
> them.
>
>
> Someone on Outages was nice enough to send this about someone else's
> thread:
> https://peering.google.com/#/learn-more/faq
>
> "Google services, including Google Public DNS, are not designed as ICMP
> network testing services"
>
>
you know what you COULD do though... probe it with DNS requests, and then
you know, test the service being offered, and still know that 'the internet
is not on fire'.



>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Tom Beecher" 
> *To: *"Mike Hammett" 
> *Cc: *"NANOG" 
> *Sent: *Tuesday, February 8, 2022 3:01:27 PM
> *Subject: *Re: Authoritative Resources for Public DNS Pinging
>
> Are there any authoritative resources from said organizations saying you
>> shouldn't use their servers for your persistent ping destinations?
>
>
> I'm not sure that an ' authoritative resource ' is really needed. It
> should be generally understood at this point in the internet's life that
> networks will block / restrict some or all ICMP traffic as they need to.
>
> On Tue, Feb 8, 2022 at 12:58 PM Mike Hammett  wrote:
>
>> Yes, pinging public DNS servers is bad.
>>
>> Googling didn't help me find anything.
>>
>> Are there any authoritative resources from said organizations saying you
>> shouldn't use their servers for your persistent ping destinations?
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>>
>
>

Re: Slack.com DNSSEC on Feb 12th 15:00 UTC

[Christopher Morrow]

On Fri, Feb 4, 2022 at 10:54 AM Bjørn Mork  wrote:

>
> I assume you know which names you are going to serve?
>
>
how would they be able to serve:
  footgun.slack.com
   bjornbjorn.slack.com
   ilovecorn.slack.com

so immediately without that wildcard though?
:)

Re: Request to participate in 2-min study survey on IPv6 Adoption

[Christopher Morrow]

>
>
> sounds like no one a taker on the survey then...

Re: What do you think about the "cloudification" of mobile?

[Christopher Morrow]

On Wed, Jan 26, 2022 at 2:37 PM Michael Thomas  wrote:

>
> I think for the vast majority of cloud users they'd do a way worse job at
> uptime than the providers. Whether that applies to some telcos, I'm not
> sure.
>
>
It seems like some of the situation is:
  "5g/mobile builds include a bunch more 'general machine' resources which
offload a bunch of the work from what was dedicated appliances/etc."

Followed quickly by:
  "Well, we don't have the resources/etc to design/build/run/maintain that
sort of thing in the field"

In a bunch of mobile deployments (in the US at least) a lot of the work was
done by some vendor already, so swapping one vendor for another isn't
particularly new.
   "Out with Nortel, in with Ericcsson!"

As to 'is this cloud?' or not, that's probably not super important? If the
telco (as an example) could come to an agreement with ~bunches of local
sysadmin shops
who'd all cooperate and build/deploy 'the same thing' (from the goes-into
and goes-outof perspective) a price points which would be palatable. I
imagine the telcos would have taken that direction.  Instead, they choose
to minimize the number of contracts and options and get cookie-cutter
deployments.

Folk may grate at 'aws' or 'azure' or 'gcp' ... but really the telco folk
(the customer in this case) is choosing someone to run infra for them,
under contract with what they hope are appropriate SLO/SLA and repair
properties. It certainly behooves them to think about failure scenarios,
but that's what SLO/SLA are for, right? :) and offloading the methods of
repair/avoidance is part of the contract process.

-chris

Re: Flow collection and analysis

[Christopher Morrow]

On Tue, Jan 25, 2022 at 10:53 AM David Bass  wrote:

> Wondering what others in the small to medium sized networks out there are
> using these days for netflow data collection, and your opinion on the tool?


a question not asked, and answer not provided here, is:
  "What are you actually trying to do with the netflow?"

Answers of the form:
  "Dos detection and mitigation planning"
  "Discover peering options/opportunities"
  "billing customers"
  "traffic analysis for future network planning"
  "abuse monitoring/management/investigations"
  "pretty noc graphs"

are helpful.. I'm sure other answers would as well.. but: "how do you
collect?" is "with a collector" and isn't super helpful if the collector
can't feed into the tooling / infrastructure / long-term goal you have.

Re: Long hops on international paths

[Christopher Morrow]

Looking at your 1 repeat ORD example:

On Tue, Jan 18, 2022 at 12:17 AM PAUL R BARFORD  wrote:

> 6  64.125.15.65  1.895 ms  [x] (zayo.telia.ter1.ord7.us.zip.zayo.com.,
> CAIDA-GEOLOC -> Chicago, IL, US)
>
> 7  62.115.118.59  99.242 ms[x] (prs-b3-link.ip.twelve99.net.,
> CAIDA-GEOLOC -> Paris, FR)
>
>
>
 65.15.125.64.in-addr.arpa name = zayo.telia.ter1.ord7.us.zip.zayo.com.
64.15.125.64.in-addr.arpa name = ae51.zayo.ter1.ord7.us.zip.zayo.com.

it looks like the probes you selected (at least the depaul univ one(s)) are
finding the 'best path' to whatever destinations via depaul -> zayo ->
telia.
It looks like zayo/telia interconnect at that /31.
Based on:

https://www.teliacarrier.com/dam/jcr:fc260a69-98a2-47d3-8d30-ca7095318413/telia-carrier-map-america-nov-2021.png

i'd guess that:
 1) telia has an mpls core with no-decrement-ttl enabled
 2) the hidden hosp include NYC and possibly cleveland/wdc
 3) judging the path information purely on traceroute hops is error prone.

Re: Long hops on international paths

[Christopher Morrow]

On Mon, Jan 17, 2022 at 5:31 PM PAUL R BARFORD  wrote:

> Dear Pengxiong,
>
> Thanks for your questions:
>
>
>1. We are using CAIDA’s Internet Topology Data Kit (ITDK) that uses
>the MIDAR alias resolution method to infer IP addresses assigned to the
>same router.
>2. We understand the concerns about IP geolocation.  Interfaces of the
>router in question are assigned similar domain names e.g., “
>chi-b2-link.ip.twelve99.net” (62.115.50.61). We also used CAIDA’s
>ITDK, which provides geolocation information, and indicates that this
>router is located in Chicago.  We cross-reference with Maxmind where
>possible.  In this particular case, there is the telltale in the use of
>"chi" in the domain name.
>3.
>
>
I think nick's point about ttl expiry and missing some context on
topology still stands.
I'd be that the paths between 2 continents do not actually land in
chicago... that you're seeing (or not seeing) missing hops between the
coast(s) and chicago inside 1299's network in the US.


>
>1.
>
> Hope that helps.
>
> Regards, PB
> --
> *From:* Pengxiong Zhu 
> *Sent:* Monday, January 17, 2022 3:23 PM
> *To:* PAUL R BARFORD 
> *Cc:* nanog@nanog.org 
> *Subject:* Re: Long hops on international paths
>
> Hi Paul,
>
> Just curious. How do you determine they are the same routers? Is it based
> on IP address or MAC addresses? Or using CAIDA’s router alias database?
>
> Also how do you draw the conclusion that the AS1299 router is indeed in
> Chicago? IP-geolocation based on rDNS is not always accurate though.
>
>
> Pengxiong
>
> On Mon, Jan 17, 2022 at 10:03 AM PAUL R BARFORD  wrote:
>
> Hello,
>
> I am a researcher at the University of Wisconsin.  My colleagues at
> Northwestern University and I are studying international Internet
> connectivity and would appreciate your perspective on a recent finding.
>
> We're using traceroute data from CAIDA's Ark project for our work.  We've 
> observed
> that many international links (i.e., a single hop on an end-to-end path
> that connects two countries where end points on the hop are identified via
> rDNS) tend to originate/terminate at the same routers.  Said another way,
> we are observing a relatively small set of routers in different countries
> tend to have a majority of the international connections - this is
> especially the case for hops that terminate in the US.  For example,
> there is a router operated by Telia (AS1299) in Chicago that has a high
> concentration of such links.  We were a bit surprised by this finding since
> even though it makes sense that the set of providers is relatively small
> (i.e., those that offer global connectivity), we assumed that the set of
> routers that used for international connectivity within any one country
> would tend to be more widely distributed (at least with respect to how they
> appear in traceroute data - MPLS notwithstanding).
>
> We're interested in whether or not this is indeed standard practice and if
> so, the cost/benefit for configuring international connectivity in this
> way?
>
> Any thoughts or insights you might have would be greatly appreciated -
> off-list responses are welcome.
>
> Thank you.
>
> Regards, PB
>
> Paul Barford
> University of Wisconsin - Madison
>
> --
>
> Regards,
> Pengxiong Zhu
> Department of Computer Science and Engineering
> University of California, Riverside
>

Re: Cloudflare Abuse Contact

[Christopher Morrow]

On Fri, Jan 7, 2022 at 12:07 PM Mike Hale  wrote:

> Hi all,
>
> Does anyone have a cloudflare abuse contact?  The email address in the
> whois doesn't actually go to their abuse team, and their abuse form
>

RAbuseHandle: ABUSE2916-ARIN
RAbuseName:   Abuse
RAbusePhone:  +1-650-319-8930
RAbuseEmail:  ab...@cloudflare.com

that doesn't end up in an actual abuse tracking system for them?
Maybe it's the 'classic' problem of the abuse@ address getting
spam-filtered happening?


> doesn't address the issue we're seeing (a massive DNS flood).
>
> Thank you much!
>
> - Mike
>
> --
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
>

Re: Theorical question about cyclic dependency in IRR filtering

[Christopher Morrow]

On Tue, Nov 30, 2021 at 3:20 AM Ben Maddison  wrote:

> Hi Chris,
>
> On 11/29, Christopher Morrow wrote:
> > On Mon, Nov 29, 2021 at 8:14 AM Job Snijders via NANOG 
> > wrote:
> >
> > > Hi Anurag,
> > >
> > > Circular dependencies definitely are a thing to keep in mind when
> > > designing IRR and RPKI pipelines!
> > >
> > > In the case of IRR: It is quite rare to query the RIR IRR services
> > > directly. Instead, the common practise is that utilities such as bgpq3,
> > > peval, and bgpq4 query “IRRd” (https://IRRd.net) instances at for
> example
> > > whois.radb.net and rr.ntt.net. You can verify this with tcpdump. These
> > > IRRd instances serve as intermediate caches, and will continue to
> serve old
> > > cached data in case the origin is down. This phenomenon in the global
> IRR
> > > deployment avoids a lot of potential for circular dependencies.
> > >
> > > Also, some organisations use threshold checks before deploying new
> > > IRR-based filters to reduce risk of “misfiring”.
> > >
> > >
> > beyond just 'did the filter deployed change by +/- X%'
> > you probably don't want to deploy content if you can't actually talk to
> the
> > source... which was anurag's proposed problem.
> >
> The point that Job was (I think?) trying to make was that by querying a
> mirror for IRR data at filter generation time, as opposed to the source
> DB directly, the issue that Anurag envisioned can be avoided.
>
> I would recommend that anyone (esp. transit operators) using IRR data
> for filter generation run a local mirror whose reachability is not
> subject to IRR-based filters.
>
>
yup, sure; "remove external dependencies, move them  internal" :)
you can STILL end up with zero prefixes even in this case, of course.


> Of course, disruption of the NRTM connection between the mirror and the
> source DB can still result in local data becoming stale/incomplete.
>
>
yup!


> You can imagine a situation where an NRTM update to an object covering
> the source DB address space is missed during a connectivity outage, and
> that missed change causes the outage to become persistent.
> However, I think that is fairly contrived. I have certainly never seen
> it in practise.
>
>
sure, there's a black-swan comment in here somewhere :)
The overall comment set here is really:
  "Plan for errors and graceful resumption of service in their existence"
  (and planning is hard)


> Cheers,
>
> Ben
>

Re: Theorical question about cyclic dependency in IRR filtering

[Christopher Morrow]

On Mon, Nov 29, 2021 at 8:14 AM Job Snijders via NANOG 
wrote:

> Hi Anurag,
>
> Circular dependencies definitely are a thing to keep in mind when
> designing IRR and RPKI pipelines!
>
> In the case of IRR: It is quite rare to query the RIR IRR services
> directly. Instead, the common practise is that utilities such as bgpq3,
> peval, and bgpq4 query “IRRd” (https://IRRd.net) instances at for example
> whois.radb.net and rr.ntt.net. You can verify this with tcpdump. These
> IRRd instances serve as intermediate caches, and will continue to serve old
> cached data in case the origin is down. This phenomenon in the global IRR
> deployment avoids a lot of potential for circular dependencies.
>
> Also, some organisations use threshold checks before deploying new
> IRR-based filters to reduce risk of “misfiring”.
>
>
beyond just 'did the filter deployed change by +/- X%'
you probably don't want to deploy content if you can't actually talk to the
source... which was anurag's proposed problem.

I suppose there are a myriad of actual failure modes though ;) and we'll
always find more as deployments progress... hurray?

Re: IPv6 and CDN's

[Christopher Morrow]

On Sat, Nov 27, 2021, 17:36 Owen DeLong via NANOG  wrote:

> Well, 1.4x faster is a bit of an odd metric. I presume that means that
> connection set up times measured were on average
> 1/1.4 times as long for IPv6 as they were for IPv4, but there are other
> possible interpretations.
>
> So really, that’s a convoluted way of saying it takes 29% less time to set
> up an IPv6 connection than an IPv4 connection on average.
>
> I can believe that is likely in a scenario where one is dealing with IPv4
> NAT overhead.
>


Why isn't this just inconsistent paths between V6 and V4/nat? (Divergent
topologies)

Re: multihoming

[Christopher Morrow]

On Wed, Nov 24, 2021 at 5:12 PM Geoff Huston  wrote:

>
>
> > On 25 Nov 2021, at 7:57 am, Christopher Morrow 
> wrote:
> >
> > Are you proposing SCTP? There is sadly not much more hope for widespread
> adoption of that as of IPv6.
> >
> > or perhaps MP-TCP? :)  or shim6?
>
> Shim6 died a comprehensive death many yers ago. I recall NANOG played a
> role in it's untimely demise. :-)
>
>
oh, darn! :)

reading the ID that masataka referenced, it sounded very much like shim6
about ~4 yrs prior to shim6's "invention".
I also don't recall seeing the draft referenced during the shim6
conversations.

Also, for completeness, MP-TCP clearly does not help UDP or ICMP flows...
nor IPSEC nor GRE nor...
unless you HTTP over MP-TCP and encap UDP/ICMP/GRE/IPSEC over that!

Talk about layer violations! talk about fun!

-chris

Re: multihoming

[Christopher Morrow]

On Wed, Nov 24, 2021 at 9:12 AM Baldur Norddahl 
wrote:

>
>
> On Wed, 24 Nov 2021 at 08:16, Masataka Ohta <
> mo...@necom830.hpcl.titech.ac.jp> wrote:
>
>> So, as modifying end systems is inevitable, there is
>> no reason not to support full end to end multihoming
>> including modifications to support multiple addresses
>> by TCP and some applications.
>>
>> Masataka Ohta
>>
>
> Are you proposing SCTP? There is sadly not much more hope for widespread
> adoption of that as of IPv6.
>
>
or perhaps MP-TCP? :)  or shim6?

Re: IPv6 and CDN's

[Christopher Morrow]

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

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


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


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

Re: DNS pulling BGP routes?

[Christopher Morrow]

On Wed, Oct 13, 2021 at 10:56 AM Tom Beecher  wrote:

> But, I certainly mean that CDN operators should not request
>> peering directly to access/retail ISPs merely because they have
>> their own transit, because the transit is not at all neutral.
>>
>
> I'm still confused.
>
> Let's say I have a CDN network, with a datacenter somewhere, an edge site
> somewhere else. I carry my bits from my datacenter, across my internal
> network, to my edge site. This is where I intend to hand the bits over to
> someone else to carry them to the end user.
>
> Let's say in this site, I have a paid transit connection , and a peering
> session directly with the end user's ISP. Where is anything related to
> neutrality being 'violated', regardless of which path I choose to send the
> bits out?
>
>
It sounds like masataka is saying that the network between your
'datacenter' and 'cdn node' is a 'transit network'.
I think 'transit network' is a sentence fragment much like: "bgp peer" ..
it's overloaded (in this conversation at least)
so probably some more clarity is required in the conversation to progress
in a meaningful manner.


> On Wed, Oct 13, 2021 at 10:36 AM Masataka Ohta <
> mo...@necom830.hpcl.titech.ac.jp> wrote:
>
>> Tom Beecher wrote:
>>
>> >> For network neutrality, backbone providers *MUST* be neutral
>> >> for contents they carry.
>> >>
>> >> However, CDN providers having their own backbone are using
>> >> their backbone for contents they prefer, which is *NOT*
>> >> neutral at all.
>> >>
>> >> As such, access/retail providers may pay for peering with
>> >> neutral backbone providers for their customers but should
>> >> reject direct peering request from, actively behaving against
>> >> neutrality, CDN providers.
>>
>> > If I am understanding you correctly, are you arguing that anyone with a
>> > network MUST be forced to become a transit provider for anyone else, in
>> the
>> > name of "neutrality"?
>>
>> No, not at all.
>>
>> For example, CDN (N stands for a network) operators may rely on
>> neutral transit providers to connect their CDN to access/retail
>> providers.
>>
>> But, I certainly mean that CDN operators should not request
>> peering directly to access/retail ISPs merely because they have
>> their own transit, because the transit is not at all neutral.
>>
>> Masataka Ohta
>>
>

Re: DNS pulling BGP routes?

[Christopher Morrow]

On Sat, Oct 9, 2021 at 11:16 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Bill Woodcock wrote:
>
> >> It may be that facebook uses all the four name server IP addresses
> >> in each edge node. But, it effectively kills essential redundancy
> >> of DNS to have two or more name servers (at separate locations)
> >> and the natural consequence is, as you can see, mass disaster.
> >
> > Yep.  I think we even had a NANOG talk on exactly that specific topic a
> long time ago.
> >
> >
> https://www.pch.net/resources/Papers/dns-service-architecture/dns-service-architecture-v10.pdf
>
> Yes, having separate sets of anycast addresses by two or more pops
> should be fine.
>
>
To be fair, it looks like FB has 4 /32's (and 4 /128's) for their DNS
authoritatives.
All from different /24's or /48's, so they should have decent routing
diversity.
They could choose to announce half/half from alternate pops, or other games
such as this.
I don't know that that would have solved any of the problems last week nor
any problems in the future.
I think Bill's slide 30 is pretty much what FB has/had deployed:
  1) I would think the a/b cloud is really 'as similar a set of paths from
like deployments as possible
  2) redundant pairs of servers in the same transit/network
  3) hidden masters (almost certainly these are in the depths of the FB
datacenter network)
  (though also this part isn't important for the conversation)
  4) control/sync traffic on a different topology than the customer serving
one


> However, if CDN provider has their own transit backbone, which is,
> seemingly, not assumed by your slides, and retail ISPs are tightly
>

I think it is, actually, in slide 30 ?
   "We need a network topology to carry control and synchronization traffic
between the nodes"

connected to only one pop of the CDN provider, the CDN provider
>

it's also not clear that FB is connecting their CDN to single points in any
provider...
I'd guess there are some cases of that, but for larger networks I would
imagine there are multiple CDN
deployments per network. I can't imagine that it's safe to deploy 1 CDN
node for all of 7018 or 3320...
for instance.


> may be motivated to let users access only one pop killing essential
> redundancy of DNS, which should be overengineering, which is my
> concern of the paragraph quoted by you.
>
>
it seems that the problem FB ran into was really that there wasn't either:
   "secondary path to communicate: "You are the last one standing, do not
die"  (to an edge node)
 or:
  "maintain a very long/less-preferred path to a core location(s) to
maintain service in case the CDN disappears"

There are almost certainly more complexities which FB is not discussion in
their design/deployment which
affected their services last week, but it doesn't look like they were very
far off on their deployment, if they
need to maintain back-end connectivity to serve customers from the CDN
locales.

-chris

Re: verizon fios, northeast, routing issues?

[Christopher Morrow]

On Sat, Oct 9, 2021, 13:45 Miles Fidelman 
wrote:

> Any Verizon folks here?
>
>
>
> I've been having some rather weird network issues lately - just reading
> email via IMAP, from home.  Over a 1gig FIOS connection to a machine in
> a nearby Tierpoint data center that has LOTS of good connectivity.
>
> I just tried some traceroutes, and got some interesting results:
>
> These originate on a machine connected to a 1gig FIOS feed, and end at a
> machine, located in a Tierpoint datacenter, about 10 miles from here.
>
> traceroute to ntcorp.com (207.154.13.58), 64 hops max, 52 byte packets
>   1  * fios_quantum_gateway (192.168.1.1)  3.530 ms  2.822 ms
>   2  * * *
>   3  100.41.27.110 (100.41.27.110)  14.970 ms  5.323 ms  6.306 ms
>   4  0.csi1.bstnmafr-mse01-bb-su1.alter.net (140.222.10.32)  11.069 ms
> 8.477 ms  17.097 ms
>   5  * * *
>   6  0.ae1.br1.bos30.alter.net (140.222.236.253)  17.121 ms  19.027 ms
>  0.ae2.br1.bos30.alter.net (140.222.236.255)  19.795 ms
>   7  * * *
>   8  colo4-dalla.bear1.boston1.level3.net (4.53.61.86)  2205.648 ms
> 8.331 ms  13.161 ms
>   9  static-33-65-203-66.axsne.net (66.203.65.33)  16.951 ms  13.791 ms
>  static-145-65-203-66.axsne.net (66.203.65.145)  21.503 ms
> 10  server1.ntcorp.com (207.154.13.58)  17.872 ms  15.902 ms  14.415 ms
>
> Several things jump out:
>
> 1. alter.net is not a common path between here & there - usually a lower
> grade connection, when other backbones aren't working right


>
>
> Alternet is the domain used by legacy uunet equipment/ips, or was that
> domain "forever".


>
>
>
> 2. origin - alter.net - level.3 - endpoint is just bizarre, one would


>
> Why? "Br" is the role name used for sfp peer interconnect devices on
> uunet's network.


>
> think that the regional FIOS network has a direct connection to level.3
> (it also seems kind of odd that the packets are flowing from Acton MA,
> to Boston, and back out to Marlboro MA - there's an awful lot of fiber
> running along Rt. 495, and the networks are fairly dense around here)
>
> 3. The intermittent, high delays (factor of 10) jump out  (also, when
> running ping tests, there seem to be intermittent periods of long
> sequences of timeouts)
>
> All in all it's really mucking with both streaming services, and simply
> posting emails (SMTP timeouts).
>
> All of which leads me to wonder if there's something mucked up with
> Verizon's routing tables (or a particular network interface).
>
> Any insights (or fixes) to be had?
>
> Thanks,
>
> Miles Fidelman
>
>
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.   Yogi Berra
>
> Theory is when you know everything but nothing works.
> Practice is when everything works but no one knows why.
> In our lab, theory and practice are combined:
> nothing works and no one knows why.  ... unknown
>
>

Re: DNS pulling BGP routes?

[Christopher Morrow]

(I'm going to hate myself in the morning, but)

On Fri, Oct 8, 2021 at 10:22 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> William Herrin wrote:
>
>
> https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
>
> our DNS servers disable those BGP advertisements if they
> themselves can not speak to our data centers
>
> The end result was that our DNS servers became unreachable
> even though they were still operational.
>
> means their DNS servers were serving the zone, even after
> they recognize their zone data were too old, that is, expired.
>
>
that's not what this means. I think Mr. Petach previously described this,
but:
  1) dns server in pop serves some content (ttls aren't important right now)
  2) dns server uses some quagga/gated/bird/etc to announce locally: "Hey,
foo/32 here!"
  (imagine this triggers an 'aggregate route' or 'network statement'
(pick your vendor solution) to appear in the global table)
  3) dns server also 'ping backend server set'
  4) when 3 fails for X period of time 'tell quagga/bird/etc to stop
announcing the /32'

then the local pop no longer sources the aggregate (/24 or /23 or
whatever)... so traffic SHOULD (externally)
flow toward another copy of the /23 or /24 or whatever...

there's not a lot of magic here... and it's not about the zone data really
at all.

Re: IPv6 woes - RFC

[Christopher Morrow]

On Wed, Sep 29, 2021 at 4:39 AM  wrote:

> Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
>
> Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy
> routing and NATing however I want..
>
>
why of COURSE you do source address selection!
so simple!


>
> -- Original message --
>
> From: Mark Andrews 
> To: b...@uu3.net
> Cc: nanog@nanog.org
> Subject: Re: IPv6 woes - RFC
> Date: Wed, 29 Sep 2021 00:28:40 +1000
>
>
>
> > On 28 Sep 2021, at 19:19, b...@uu3.net wrote:
> >
> > Heh, NAT is not that evil after all. Do you expect that all the home
> > people will get routable public IPs for all they toys inside house?
>
> Yes! Remember routable does not mean that it is reachable from outside.
>
> > And if they change ISP they will get new range?
>
> Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
> has only been specified for 18 years now.  The IPv6 address ranges ISP
> get for RIRs are based on handing out multiple /64 to every customer.
>
> > Doesnt sounds nice to me.. But I guess I its just me
>
> It sounds like you need to do some reading about IPv6, then actually
> use it.  100s of millions of home customers are get routable IPv6 prefixes
> today around the world.  It's not scary.  Things don˙˙t blow up.
>
> > Yeah I am aware of putting additional aliases on loopback.
> >
> > No futher comment about ND and DHCP.
> >
> > Well, at a time when TCP/IP was invented, 32bit address space looked
> > pretty much big... I dont blame them than they didnt predicted future..
> > Unfortunately, cant say the same about IPv6 R taskforce ;)
> >
> > Hah, multicast... Ill skip it.
> >
> > Followed change to support CIDR, Internet was still small and considered
> > R field...
> >
> > Okey, I think its no need to futher pollute NANOG list with this.
> > I said at the begining that this is just my subjective opinion.
> > This will not help IPv6 case at all.
> >
> > At least from my (2) standpoint it would be really cool that IPv6
> > would be finally addopted.
> >
> > I just wanted to share my toughts about why im not big fan of IPv6.
> > I also wanted to hear other opinions what they dislike about it, no
> > list of how cool IPv6 is and how everyone should use it right away.
> >
> >
> > -- Original message --
> >
> > From: Owen DeLong 
> > To: b...@uu3.net
> > Cc: nanog@nanog.org
> > Subject: Re: IPv6 woes - RFC
> > Date: Sat, 25 Sep 2021 12:01:22 -0700
> >
> >
> >
> >> On Sep 25, 2021, at 01:57 , b...@uu3.net wrote:
> >>
> >> Well, I think we should not compare IPX to IPv4 because those protocols
> >> were made to handle completly different networks?
> >>
> >> Yeah, IPv6 is new, but its more like revolution instead of evolution.
> >>
> >> Well, Industry seems to addapt things quickly when they are good enough.
> >> Better things replace worse. Of course its not always the case,
> sometimes
> >> things are being forced here.. And thats how I feel about IPv6..
> >
> > Sometimes worse things replace better. NAT, for example was definitely
> not
> > an improvement to IPv4. It was a necessary evil intended to be a
> temporary
> > fix.
> >
> >>
> >> IPv4 Lookback is 127.0.0.1/8
> >> You can use bind IPs within range by applications. Handy
> >> In IPv6 its not the case.
> >
> > You are free to assign any additional IPv6 addresses you like to the
> loopback
> > interface and then bind them to applications. Personally, I haven˙˙t
> found a
> > particularly good use for this, but it is possible.
> >
> > It does mean that instead of wasting 1/256th of the entire address space
> > in every context on loopbacks, you have to assign what you need there,
> > but you can easily assign a /64 prefix to a loopback interface and have
> > applications bind within range.
> >
> >> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
> >> Tables overflows, attacks and DDoS.. Why to repeat history again?
> >
> > Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs.
> > ARP. Table overflows are (not really an issue in my experience) the
> > result of a larger address space than the memory available for the L2
> > forwarding table on switches or the ND table on hosts. This isn˙˙t due
> > to a difference in ND vs. ARP. It is due to the fact that there are no
> > 64-bit networks in IPv4, but they are commonplace in IPv6.
> >
> > Mostly this has been solved in software by managing table discards more
> > effectively.
> >
> >> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some
> >> issues. If this is not the case, im sorry. Its been a while when I last
> time
> >> played with IPv6...
> >
> > I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any
> significant
> > problems with it other than some minor inconveniences introduced by the
> ability
> > to have different DUID types and vendors doing semi-obnoxious things
> along that
> > line.
> >
> >> IPv6 interop: yeah, I agree here.. But people involved with IPv6