Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Randy Bush]

> Radb only supports

again, north america is a special snowflake.  radb is a routing
registry, not an allocation registry.  inetnum: and NetRange: are
allocation objects.

if you get your address space from arin, you have to use their
webby stuff to add the Comments: to the allocation object.

ryuu.rg.net:/Users/randy> whois -h whois.arin.net 192.169.0.0
NetRange:   192.169.0.0 - 192.169.1.255
CIDR:   192.169.0.0/23
NetName:PSG169
NetHandle:  NET-192-169-0-0-1
Parent: NET192 (NET-192-0-0-0-0)
NetType:Direct Assignment
OriginAS:   
Organization:   RGnet, LLC (RGNETI-1)
RegDate:2005-04-12
Updated:2020-09-14
Comment:Geofeed https://rg.net/geofeed
Ref:https://rdap.arin.net/registry/ip/192.169.0.0

randy

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Ca By]

On Mon, Sep 14, 2020 at 6:00 PM Randy Bush  wrote:

> > Would your arin approach of netrange work in all regions?
>
>
>
> no.  to the best of my knowledge, other regional registries and
>
> independent irr registries use rpsl; i.e. inetnum: and remarks:.
>

Radb only supports

route

-route6

-aut-num

-as-set

-route-set




>
>
> randy
>
>

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Randy Bush]

> Would your arin approach of netrange work in all regions?

no.  to the best of my knowledge, other regional registries and
independent irr registries use rpsl; i.e. inetnum: and remarks:.

randy

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Ca By]

On Mon, Sep 14, 2020 at 5:53 PM Randy Bush  wrote:

> >> the edit buffer, yet to be published, has
>
> >>
>
> >>Currently, the registry data published by ARIN is not RPSL;
>
> >>therefore, when fetching from ARIN whois, the "NetRange" attribute/
>
> >>key must be treated as "inetnum" and the "Comment" attribute must be
>
> >>treated as "remarks".
>
> >>
>
> >> comments appreciated
>
> >
>
> > Is it possible to have one method work in all regions instead of a one
>
> > off for arin ?
>
>
>
> rirs have a compatibility problem and arin is the worst.
>
>
>
> rirs' "stats" files, the data of record, are pretty incompatible, and we
>
> could not add data to them anyway.
>
>
>
> reverse dns delegations might be interesting except for the showstopper
>
> issues i recently posted in another message.
>
>
>
> that leaves whois and the rpsl-like data.  unless i am missing
>
> something.
>
>
>
> < imagine snark here >
>
>
Sorry, let me be more specific.

Would your arin approach of netrange work in all regions?


>
> randy
>
>

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Randy Bush]

>> the edit buffer, yet to be published, has
>>
>>Currently, the registry data published by ARIN is not RPSL;
>>therefore, when fetching from ARIN whois, the "NetRange" attribute/
>>key must be treated as "inetnum" and the "Comment" attribute must be
>>treated as "remarks".
>>
>> comments appreciated
>
> Is it possible to have one method work in all regions instead of a one
> off for arin ?

rirs have a compatibility problem and arin is the worst.

rirs' "stats" files, the data of record, are pretty incompatible, and we
could not add data to them anyway.

reverse dns delegations might be interesting except for the showstopper
issues i recently posted in another message.

that leaves whois and the rpsl-like data.  unless i am missing
something.

< imagine snark here >

randy

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Ca By]

On Mon, Sep 14, 2020 at 3:02 PM Randy Bush  wrote:

> the edit buffer, yet to be published, has
>
>
>
>Currently, the registry data published by ARIN is not RPSL;
>
>therefore, when fetching from ARIN whois, the "NetRange" attribute/
>
>key must be treated as "inetnum" and the "Comment" attribute must be
>
>treated as "remarks".
>
>
>
> comments appreciated
>
>
Is it possible to have one method work in all regions instead of a one off
for arin ?


>
> randy
>
>

Re: IP addresses on subnet edge (/24)

[Robert L Mathews]

On 9/14/20 2:25 PM, Andrey Khomyakov wrote:
> TL;DR I suspect there are middle boxes that don't like IPs ending in
> .255. Anyone seen that?

Yes. We'd every so often get random complaints that "my friend can't
reach my website but I can", etc., with not enough detail to track it
down. The problem would disappear when we moved it to another IP address.

Because of this, we stopped allocating customer websites on .0 and .255
IP addresses about 10 years ago, instead using them for internal /
controlled access purposes where we could investigate any problems.
(Which never occur. )

-- 
Robert L Mathews, Tiger Technologies, http://www.tigertech.net/

why not use dns for draft-ymbk-opsawg-finding-geofeeds?

[Randy Bush]

[ am i going to regret cross-posting? ]

a friend raised in private the question of whether the dns could be used
instead of rpsl.

essentially, dns does not search down-tree for you.  it only answers
exact specific queries.  for some reason lost in time, well at least
lost in my mind, rpsl servers give you the nearest enclosing object.

e.g., if i query for the ip address of psg.com, 147.28.0.62, i get the
encompassing inetnum: object.

ryuu.rg.net:/Users/randy> whois -h whois.ripe.net 147.28.0.62   
inetnum:147.28.0.0 - 147.28.31.255
netname:RGNET-RSCH-147-0
country:EE
org:ORG-RO47-RIPE
admin-c:RB45695-RIPE
tech-c: RB45695-RIPE
abuse-c:AR52766-RIPE
status: LEGACY
mnt-by: MAINT-RGNET
remarks:Geofeed https://rg.net/geofeed
created:2020-09-03T22:23:37Z
last-modified:  2020-09-13T20:16:05Z
source: RIPE # Filtered

and now i know not to query further in the range 147.28.0.0/19.  note
the geofeed pointer is not at the exact ip, or at the /24, or at the
/16.  and have fun getting the magic of knowing it is the /19 into the
dns.

one does not want to query the dns for an RR 62.0.28.147.in-addr.arpa
because, for this to be useful, either
  o you need the geoloc data with every PTR record (think ipv6 and
slaac)
  o you need some non-existent magic to get you the geoloc data for some
unspecified less specific granularity

if netflix wants to collect the geofeeds once a month.  do we propose
they dns query all ipv4 and ipv6 host addresses?

i suspect there are also cultural issues.  in most isps of scale, dns is
close to customer service, a different 'silo' from provisioning.  rpsl
not so much.  i am sure massimo is learning more about the silos in ntt
than he would care to.  but he was able to deploy this hack in a week.
i would bet that he could never get a dns hack deployed.

possibly amusing tangential note: we once tried to do rpki in the dns,
see https://tools.ietf.org/html/draft-bates-bgp4-nlri-orig-verif-00
aside from other issues, dns only allows a single delegation, which
would preclude two owners in a make before break transition.

randy

Re: IP addresses on subnet edge (/24)

[Mark Andrews]

You may want to do traceroute using syn/ack packets to find the offending piece 
of equipment (may require modifying traceroute to set the syn and ack).

> On 15 Sep 2020, at 07:25, Andrey Khomyakov  wrote:
> 
> TL;DR I suspect there are middle boxes that don't like IPs ending in .255. 
> Anyone seen that?
> 
> Folks,
> We are troubleshooting a strange issue where some of our customers cannot 
> establish a successful connection with our HTTP front end. In addition to 
> checking the usual things like routing and interface errors and security 
> policy configurations, hopening support tickets with the load balancer vendor 
> so far all to no avail, we did packet captures.
> Based on the packet captures we receive a SYN, we reply with SYN-ACK, but the 
> client never actually receives that SYN-ACK. In a different instance the 
> 3-way completes, followed by TLS client hello to us, we reply with TLS Server 
> Hello and that server hello never makes it to the client.
> And again, this is only affecting a small subset of customers thus suggesting 
> it's not the load balancer or the edge routing configuration (in fact we can 
> traceroute fine to the customer's IP).
> So far the only remaining theory that remains is that there are middle boxes 
> out there that do not like IPs ending in .255. The service that the clients 
> can't get to is hosted on two IPs ending in .255
> Let's just say they are x.x.121.255 and x.x.125.255. We even stood up a basic 
> "hello world" web server on x.x.124.255 with the same result. Standing up the 
> very same basic webserver on x.x.124.250 allows the client to succeed.
> So far we have a friendly customer who has been working with us on 
> troubleshooting the issue and we have some pcaps from the client's side 
> somewhat confirming that it's not the customer's system either.
> This friendly customer is in a small 5 people office with Spectrum business 
> internet (that's the SYN-ACK case). The same customer tried hopping on his 
> LTE hotspot which came up as Cellco Partnership DBA Verizon Wireless with the 
> same result (that's the TLS server hello case). That same customer with the 
> same workstation drives a town over and he can get to the application fine 
> (we are still waiting for the customer to let us know what that source IP is 
> when it does work).
> Before you suggest that those .255 addresses are broadcasts on some VLAN, 
> they are not. They are injected as /32s using a routing protocol, while the 
> VLAN addressing is all RFC1918 addressing.
> 
> --Andrey

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: IP addresses on subnet edge (/24)

[Töma Gavrichenkov]

Peacez

On Tue, Sep 15, 2020, 12:26 AM Andrey Khomyakov 
wrote:

> TL;DR I suspect there are middle boxes that don't like IPs ending in .255.
> Anyone seen that?
>

Also .0 and .1.

Yes, there was some kind of a strange behavior with those addresses
before.  We excluded those from rotation back in 2011 when that was really
biting us.  There's an impression that this issue has become much less
troubling over the years, didn't have time to investigate though.

--
Töma

>

Re: SPAM: Re: Cogent emails

[Tom Hill]

On 14/09/2020 18:13, Simon Lockhart wrote:
> We gave in and just bought a small amount of transit from them.

Aha! You're the reason they don't stop! :p

-- 
Tom

Re: IP addresses on subnet edge (/24)

[Tom Hill]

On 14/09/2020 22:25, Andrey Khomyakov wrote:
> TL;DR I suspect there are middle boxes that don't like IPs ending in
> .255. Anyone seen that?

Yes, but not for many, MANY years. I would expect that this service
might not like addresses ending in .0 either?

It was ca. 2010, when I started receiving an increasing number of
complaints that connections from addresses ending in .0 or .255 were
failing toward my (at the time) hosted services. This behaviour was
eventually* narrowed to iptables rules carelessly included with 'Atomic
Secured Linux' that purposely blackholed connections if the source
address' most specific octet happened to contain .0 or .255.

I'm sure that 'ASL' wasn't the only piece of software to have shipped
with this default behaviour, so should you discover any box of any sort,
configuration (or age) blindly hampering the connectivity for addresses
with all-1s or all-0s in any of the three most-specific octets, please
take this as infallible permission to promptly introduce it to the
nearest body of water. :)

* I still have AAISP - my home ISP at the time - to thank for routing me
a /30 with a .255 address in it! It wouldn't have been as easy to
resolve without that - very few UK consumers were being assigned
addresses with .255 in them at the time.

-- 
Tom

Re: IP addresses on subnet edge (/24)

[Warren Kumari]

On Mon, Sep 14, 2020 at 5:28 PM Andrey Khomyakov
 wrote:
>
> TL;DR I suspect there are middle boxes that don't like IPs ending in .255. 
> Anyone seen that?

Windows XP/Windows 2003 both had an issue where addresses ending in
.255 wouldn't work, regardless of the mask. It seems unlikely that
there are middleboxes that are still that old kicking around (largely
because they would likely have been 0wned and tossed out), but...

There used to be a knowledge base article on this -
http://support.microsoft.com/kb/281579 according to my bookmarks, but
it has disappeared...

W


>
> Folks,
> We are troubleshooting a strange issue where some of our customers cannot 
> establish a successful connection with our HTTP front end. In addition to 
> checking the usual things like routing and interface errors and security 
> policy configurations, hopening support tickets with the load balancer vendor 
> so far all to no avail, we did packet captures.
> Based on the packet captures we receive a SYN, we reply with SYN-ACK, but the 
> client never actually receives that SYN-ACK. In a different instance the 
> 3-way completes, followed by TLS client hello to us, we reply with TLS Server 
> Hello and that server hello never makes it to the client.
> And again, this is only affecting a small subset of customers thus suggesting 
> it's not the load balancer or the edge routing configuration (in fact we can 
> traceroute fine to the customer's IP).
> So far the only remaining theory that remains is that there are middle boxes 
> out there that do not like IPs ending in .255. The service that the clients 
> can't get to is hosted on two IPs ending in .255
> Let's just say they are x.x.121.255 and x.x.125.255. We even stood up a basic 
> "hello world" web server on x.x.124.255 with the same result. Standing up the 
> very same basic webserver on x.x.124.250 allows the client to succeed.
> So far we have a friendly customer who has been working with us on 
> troubleshooting the issue and we have some pcaps from the client's side 
> somewhat confirming that it's not the customer's system either.
> This friendly customer is in a small 5 people office with Spectrum business 
> internet (that's the SYN-ACK case). The same customer tried hopping on his 
> LTE hotspot which came up as Cellco Partnership DBA Verizon Wireless with the 
> same result (that's the TLS server hello case). That same customer with the 
> same workstation drives a town over and he can get to the application fine 
> (we are still waiting for the customer to let us know what that source IP is 
> when it does work).
> Before you suggest that those .255 addresses are broadcasts on some VLAN, 
> they are not. They are injected as /32s using a routing protocol, while the 
> VLAN addressing is all RFC1918 addressing.
>
> --Andrey



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Randy Bush]

the edit buffer, yet to be published, has

   Currently, the registry data published by ARIN is not RPSL;
   therefore, when fetching from ARIN whois, the "NetRange" attribute/
   key must be treated as "inetnum" and the "Comment" attribute must be
   treated as "remarks".

comments appreciated

randy

Re: Cogent emails

[Randy Bush]

i get 50 times as many emails bitching about cogent spam as i get cogent
spam.  and my spam filter is trained to take care of the latter.

randy

Re: curious spam...

[Mark Seiden]

> On Sep 14, 2020, at 5:04 PM, John Levine  wrote:
> 
> In article 
>  you 
> write:
>> I moved to Seattle. Today I found my grmail box subscribed to a
>> congressman's list from a nearby Washington jurisdiction. Not some
>> random congressman. And not any of the addresses I give out; my gmail
>> box's address which I don't. ...
> 
> It's strange but I think it's not typical.  I have given tagged
> addresses to lots of political candidates and am getting buckets
> of mail, like five a day from each of the presidential campaigns
> to those addresses.
> 
> I am getting no political spam to my gmail box, and do not recall any
> that wasn't clearly due to nitwits signing me up who thought that my
> address (which is my name) was their address.
> 
> R's,
> John

on a probably unrelated note, the new yorker has an interesting piece this week 
about the 
ultra invasive trump2020 app, provided by Phunware.

The writer claims in the last 'graph that they managed to track down an email 
address she 
never provided to the app:

“...the messages I began getting from the Trump campaign every couple of hours 
were sent not only to the name and address I’d used to access the app. They 
were also sent to the e-mail address and name associated with the credit card 
I’d used to buy the phone and its SIM card, neither of which I had shared with 
the campaign. Despite my best efforts, they knew who I was and where to reach 
me."

https://www.newyorker.com/news/campaign-chronicles/the-trump-campaigns-mobile-app-is-collecting-massive-amounts-of-voter-data

IP addresses on subnet edge (/24)

[Andrey Khomyakov]

TL;DR I suspect there are middle boxes that don't like IPs ending in .255.
Anyone seen that?

Folks,
We are troubleshooting a strange issue where some of our customers cannot
establish a successful connection with our HTTP front end. In addition to
checking the usual things like routing and interface errors and security
policy configurations, hopening support tickets with the load balancer
vendor so far all to no avail, we did packet captures.
Based on the packet captures we receive a SYN, we reply with SYN-ACK, but
the client never actually receives that SYN-ACK. In a different instance
the 3-way completes, followed by TLS client hello to us, we reply with TLS
Server Hello and that server hello never makes it to the client.
And again, this is only affecting a small subset of customers thus
suggesting it's not the load balancer or the edge routing configuration (in
fact we can traceroute fine to the customer's IP).
So far the only remaining theory that remains is that there are middle
boxes out there that do not like IPs ending in .255. The service that the
clients can't get to is hosted on two IPs ending in .255
Let's just say they are x.x.121.255 and x.x.125.255. We even stood up a
basic "hello world" web server on x.x.124.255 with the same result.
Standing up the very same basic webserver on x.x.124.250 allows the client
to succeed.
So far we have a friendly customer who has been working with us on
troubleshooting the issue and we have some pcaps from the client's side
somewhat confirming that it's not the customer's system either.
This friendly customer is in a small 5 people office with Spectrum business
internet (that's the SYN-ACK case). The same customer tried hopping on his
LTE hotspot which came up as Cellco Partnership DBA Verizon Wireless with
the same result (that's the TLS server hello case). That same customer with
the same workstation drives a town over and he can get to the application
fine (we are still waiting for the customer to let us know what that source
IP is when it does work).
Before you suggest that those .255 addresses are broadcasts on some VLAN,
they are not. They are injected as /32s using a routing protocol, while the
VLAN addressing is all RFC1918 addressing.

--Andrey

Re: curious spam...

[John Levine]

In article 
 you 
write:
>I moved to Seattle. Today I found my grmail box subscribed to a
>congressman's list from a nearby Washington jurisdiction. Not some
>random congressman. And not any of the addresses I give out; my gmail
>box's address which I don't. ...

It's strange but I think it's not typical.  I have given tagged
addresses to lots of political candidates and am getting buckets
of mail, like five a day from each of the presidential campaigns
to those addresses.

I am getting no political spam to my gmail box, and do not recall any
that wasn't clearly due to nitwits signing me up who thought that my
address (which is my name) was their address.

R's,
John

RE: SRv6

[aaron1]

Oh snap!  Hey hey, that's good, thanks Nick.  I had to go into the locator 
service of the remote pe and find a sid that would respond to ping.  

This is apparently an OAM Endpoint with Punt (End.OP)

https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-0/segment-routing/configuration/guide/b-segment-routing-cg-asr9000-70x/b-segment-routing-cg-asr9000-70x_chapter_011.html

Here I'm executing ping/trace from the SRv6 ingress pe...to the egress PE

RP/0/RP0/CPU0:r1#ping fc00:0:4:4::1 source lo0 use-srv6-op-sid fc00:0:0:4:40::
Mon Sep 14 20:27:09.727 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to fc00:0:4:4::1, timeout is 2 seconds:
S
Success rate is 100 percent (5/5), round-trip min/avg/max = 329/371/416 ms


RP/0/RP0/CPU0:r1#traceroute fc00:0:4:4::1 source lo0 use-srv6-op-sid 
fc00:0:0:4:40::
Mon Sep 14 20:27:19.068 UTC

Type escape sequence to abort.
Tracing the route to fc00:0:4:4::1

 1  :::0.0.0.0
[IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1) 
] 29 msec
[IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1) 
] 56 msec
[IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1) 
] 12 msec
 2  :::0.0.0.0
[IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1) 
] 118 msec
[IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1) 
] 101 msec
[IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1) 
] 99 msec
 3  fc00:0:4:4::1 224 msec 277 msec 254 msec
 4  :::0.0.0.0 237 msec 209 msec 204 msec
 5  fc00:0:4:4::1 386 msec 431 msec 403 msec


Now I see this on the wireshark capture...

Ethernet - 86dd
Ipv6 - DA fc00:0:0:4:40:: (cool, this is the active/top SID, and not the 
ping'ed DA)
- routing header for v6 (segment routing)
--- segments left: 1
--- address next segment: fc00:0:4:4::1
Icmpv6



-Aaron

Re: Cogent emails

[Ryan Wilkins]

All I did was express interest a few years ago and ever since then they’ve 
called and emailed me pretty regularly.  Just got one yesterday.  I’m probably 
on the fourth sales guy now since I first asked.

Ryan Wilkins

> On Sep 14, 2020, at 3:00 PM, Jesse DuPont  
> wrote:
> 
> We started getting emails the moment we got our own AS (earlier this year).

Re: SRv6

[Nick Hilliard]

aar...@gvtc.com wrote on 14/09/2020 20:03:

Thanks Nick, I only see the following layers...  I see no extension headers
behind the ipv6 header.  I sent you the wireshark sniff directly so you can
see what I'm seeing.


you should see extension headers if you're doing more complex stuff? 
E.g. if you run a ping / traceroute with the "use-srv6-op-sid" 
parameter, or create a segment list under "segment-routing srv6 traffic 
engineering", that should throw in some EHs.


Nick

Re: Phoenix-IX Contact

[Bill Woodcock]

> On Sep 14, 2020, at 9:31 PM, Kate Gerry  wrote:
> 
> Does anybody have a contact who works at Phoenix-IX? I have been attempting 
> to reach somebody there for a while now without any luck.
> 
> Attempts to each out to peer...@phoenix-ix.net as well as Ninja-IX have been 
> without any luck. We also tried reaching out to Paul Emmons via LinkedIn mail 
> and never received a response.

Paul is the correct person.

-Bill



signature.asc
Description: Message signed with OpenPGP

Phoenix-IX Contact

[Kate Gerry]

Does anybody have a contact who works at Phoenix-IX? I have been attempting to 
reach somebody there for a while now without any luck.

Attempts to each out to peer...@phoenix-ix.net  
as well as Ninja-IX have been without any luck. We also tried reaching out to 
Paul Emmons via LinkedIn mail and never received a response.

Any assistance either on or off the list is appreciated.

Thanks!

--
Kate


signature.asc
Description: Message signed with OpenPGP

RE: SRv6

[aaron1]

Thanks Nick, I only see the following layers...  I see no extension headers
behind the ipv6 header.  I sent you the wireshark sniff directly so you can
see what I'm seeing.

Ethernet - Type 0x86dd
Ipv6 - Next Header IPIP (4)
Ipv4
Icmp

-Aaron

Re: Cogent emails

[Jesse DuPont]

  
  
We started getting emails the moment we got our own AS (earlier this
year).

  
  
  
  
  
  
  
  
  
  
  
  
  
  
Jesse DuPont
Owner
  / Network
  Architect
  email:
  jesse.dup...@celeritycorp.net
  Celerity
  Networks LLC / Celerity
Broadband LLC
  Like us!
  facebook.com/celeritynetworksllc
Like
  us!
  facebook.com/celeritybroadband
 
  

On 9/14/20 11:13 AM, Dovid Bender
  wrote:


  
  The question is if they are back to contacting the
names on whois or they magically found our emails "another way"
and they have plausible deniability.
 
  
  
  
On Mon, Sep 14, 2020 at 1:07
  PM David Guo  wrote:


  

  Yes, every week
   
  Proof
   
  https://vip1.loli.net/2020/09/15/bq3lHGuvNRkW9YS.jpg
   
  
From: NANOG
  xtom@nanog.org> 
On Behalf Of Dovid Bender
  Sent: Tuesday, September 15, 2020 12:46 AM
  To: NANOG 
  Subject: Cogent emails
  
   
  
Is anyone starting to get the
  "cogent emails" again?

   


   

  

  

  


  

Re: curious spam...

[David Hubbard]

Here in Florida the self-preservation interests of the two party system have 
resulted in all voter registrations being made public, including email, d/o/b, 
phone, home address (since you can't legally register any other), party 
affiliation.  If you used your private email for any state government 
registrations, they may have leaked it as soon as you moved.  Alternatively, if 
your previous state had already leaked it, and you have declared a party 
affiliation, the state level entity likely shared it with the national entity, 
who then shared it with the new state entity where you moved so they can spam 
you all over again.  I made the mistake of donating to a party backed candidate 
about a decade ago, and the cesspool of political entities associated with that 
party continue to email and text me every single cycle.  Unless I start suing, 
or change all my contact info, there's no likely any way I'll ever get it to 
stop.

I believe several states' DMV's have been found to be selling license 
registration info as a revenue source too.

Florida does have a way to not have your personal info released; it's 
conveniently only available to people you'd expect, first responders, judges, 
and of course, members of congress.



On 9/14/20, 2:32 PM, "NANOG on behalf of William Herrin" 
 wrote:

Howdy,

I've noticed something odd. When I lived in Virginia, I started
receiving email directly to my gmail box from my U.S. Representative.
Unsolicited spam from Congressmen is nothing new but it was a little
odd that they found my gmail box (which I don't give out) and not one
of the hundreds of aliases at herrin.us or dirtside.com which I do
give out. The gmail box exists only in mail headers; "From" is always
a different address.

I moved to Seattle. Today I found my grmail box subscribed to a
congressman's list from a nearby Washington jurisdiction. Not some
random congressman. And not any of the addresses I give out; my gmail
box's address which I don't.

Anyone else have a similar experience? Any idea how a hidden address
is making it on to relevant congressmens' lists but not any others?
That's weird right?

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: curious spam...

[Aaron C. de Bruyn via NANOG]

Yes.  I get spammed about once a week from Jaime Herrera Beutler.  Never
looked at the headers though.
It's entirely possible someone is either pranking me by signing me up to
political lists or they harvested my well-known address from somewhere.

I'll check the headers next time.

-A

On Mon, Sep 14, 2020 at 11:33 AM William Herrin  wrote:

> Howdy,
>
> I've noticed something odd. When I lived in Virginia, I started
> receiving email directly to my gmail box from my U.S. Representative.
> Unsolicited spam from Congressmen is nothing new but it was a little
> odd that they found my gmail box (which I don't give out) and not one
> of the hundreds of aliases at herrin.us or dirtside.com which I do
> give out. The gmail box exists only in mail headers; "From" is always
> a different address.
>
> I moved to Seattle. Today I found my grmail box subscribed to a
> congressman's list from a nearby Washington jurisdiction. Not some
> random congressman. And not any of the addresses I give out; my gmail
> box's address which I don't.
>
> Anyone else have a similar experience? Any idea how a hidden address
> is making it on to relevant congressmens' lists but not any others?
> That's weird right?
>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: SRv6

[Nick Hilliard]

aar...@gvtc.com wrote on 14/09/2020 18:57:

But rather, shows my L3VPN v4 traffic riding v6 and that’s it.


that is how SRv6 works.  IPv6 + extension headers (+ a bit extra which 
is incompatible with ipv6).



Let me know if I’m seeing an SRH and just don’t know it, LOL.


Check out the IPv6 Extension Headers in the underlay packet.

Nick

curious spam...

[William Herrin]

Howdy,

I've noticed something odd. When I lived in Virginia, I started
receiving email directly to my gmail box from my U.S. Representative.
Unsolicited spam from Congressmen is nothing new but it was a little
odd that they found my gmail box (which I don't give out) and not one
of the hundreds of aliases at herrin.us or dirtside.com which I do
give out. The gmail box exists only in mail headers; "From" is always
a different address.

I moved to Seattle. Today I found my grmail box subscribed to a
congressman's list from a nearby Washington jurisdiction. Not some
random congressman. And not any of the addresses I give out; my gmail
box's address which I don't.

Anyone else have a similar experience? Any idea how a hidden address
is making it on to relevant congressmens' lists but not any others?
That's weird right?

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: SPAM: Re: Cogent emails

[Mike Hammett]

I manage three networks. All three have transit from Cogent. I get assaulted 
non-stop by Cogent sales reps. 




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

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

- Original Message -

From: "Simon Lockhart"  
To: "David Guo"  
Cc: "NANOG"  
Sent: Monday, September 14, 2020 12:13:37 PM 
Subject: SPAM: Re: Cogent emails 

We gave in and just bought a small amount of transit from them. The sales 
emails stopped. Seems to be about the only effective method. 

Simon 

On Mon Sep 14, 2020 at 05:07:28PM +, David Guo via NANOG wrote: 
> Yes, every week 
> 
> Proof 
> 
> https://vip1.loli.net/2020/09/15/bq3lHGuvNRkW9YS.jpg 

SRv6

[aaron1]

I have what seems to be a good SRv6 test in my lab running XRv9k 7.0.2

 

But I'm wondering why the sniffer doesn't show the much-spoken-of SRH
(Segment Routing Header).. But rather, shows my L3VPN v4 traffic riding v6
and that's it.  Let me know if I'm seeing an SRH and just don't know it,
LOL.

 

Ethernet - Type 0x86dd

Ipv6 - Next Header IPIP (4)

Ipv4 - icmp echo (my tests ce to ce end to end)

 

Those layers is all it shows.  I've read a lot about SRv6 with SID's inside
extension headers or segment routing header, but I'm not seeing it.

 

Any idea what this is that I'm seeing ?

 

I've configured the PE's IAW
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r6-6/se
gment-routing/configuration/guide/b-segment-routing-cg-asr9000-66x/b-segment
-routing-cg-asr9000-66x_chapter_011.html#id_95420

 

I can give you more info if you wish.  

 

Aaron

aar...@gvtc.com

 

Re: SPAM: Re: Cogent emails

[Mike Lyon]

I tell them to hit me up once they have direct peering with HE.net.

Haven’t heard from them since.

-Mike

> On Sep 14, 2020, at 10:15, Simon Lockhart  wrote:
> 
> We gave in and just bought a small amount of transit from them. The sales 
> emails stopped. Seems to be about the only effective method.
> 
> Simon
> 
>> On Mon Sep 14, 2020 at 05:07:28PM +, David Guo via NANOG wrote:
>> Yes, every week
>> 
>> Proof
>> 
>> https://vip1.loli.net/2020/09/15/bq3lHGuvNRkW9YS.jpg

Re: Cogent emails

[Dovid Bender]

The question is if they are back to contacting the names on whois or they
magically found our emails "another way" and they have plausible
deniability.


On Mon, Sep 14, 2020 at 1:07 PM David Guo  wrote:

> Yes, every week
>
>
>
> Proof
>
>
>
> https://vip1.loli.net/2020/09/15/bq3lHGuvNRkW9YS.jpg
>
>
>
> *From:* NANOG  * On Behalf Of *Dovid
> Bender
> *Sent:* Tuesday, September 15, 2020 12:46 AM
> *To:* NANOG 
> *Subject:* Cogent emails
>
>
>
> Is anyone starting to get the "cogent emails" again?
>
>
>
>
>

SPAM: Re: Cogent emails

[Simon Lockhart]

We gave in and just bought a small amount of transit from them. The sales 
emails stopped. Seems to be about the only effective method.

Simon

On Mon Sep 14, 2020 at 05:07:28PM +, David Guo via NANOG wrote:
> Yes, every week
> 
> Proof
> 
> https://vip1.loli.net/2020/09/15/bq3lHGuvNRkW9YS.jpg

RE: Cogent emails

[David Guo via NANOG]

Yes, every week

Proof

https://vip1.loli.net/2020/09/15/bq3lHGuvNRkW9YS.jpg

From: NANOG  On Behalf Of Dovid Bender
Sent: Tuesday, September 15, 2020 12:46 AM
To: NANOG 
Subject: Cogent emails

Is anyone starting to get the "cogent emails" again?

Cogent emails

[Dovid Bender]

Is anyone starting to get the "cogent emails" again?

Re: sr - spring - what's the deal with 2 names

[Mark Tinka]

On 10/Sep/20 21:09, aar...@gvtc.com wrote:
> Thanks for the heads up Mark... I see docs showing SRv6 not supported until 
> XR 6.6, I put XR7 in my lab to start testing it...

I wasn't talking about SRv6... I am talking about SR-MPLS, signaled via
and supported for IPv6, in the IGP.

Mark.