Re: Correcting national address databases?

[Nimrod Levy]

Also, address validation in web forms is often "stupid".
Imagine a system for a service that disallows PO boxes.
Now imagine the address you're trying to input is on "Post Office Rd"
NOW imagine trying to explain that to support.
Their solution was to submit a paper form.
My solution was to input "PostOffice Rd" which amazingly worked.

Nimrod


On Thu, May 30, 2024 at 4:31 PM Sean Donelan  wrote:

>
> Since I did address database software for public libraries for a couple of
> decades  Addresses are complicated.
>
> In North American (USA & Canada) there are approximately 80,000
> localities, counties, states and federal addressing authorities (mostly
> local building and planning departments). These are the official (legal)
> addressing authorities.  Tax and real estate records usual the legal
> property definition.
>
>
>
> Because its a PITA to deal with 80,000 different authorities...
>
> The USPS (and Canada Post)) maintains a national directory of addresses
> valid for mailing purposes.  Not every address. The addresses they
> deliver based on local jurisdiction address information, but modified for
> postal needs.
>
> The telephone company (formerly Ma Bell, then ILECs, now PSAPs and states)
> maintain the Master Street Address Guide (MSAG) for E911 purposes. Again
> based on local jurisdication address information, but modified for
> telco/cellular/PSAP needs.
>
> The US Census maintains TIGER and Master Address File (MAF) for planning
> enumeration operations every 10 years. Geocodes domiciles (i.e. where
> people live, not work) for census workers, not necessarily postal or
> telephone addressses.
>
> Several commercial (i.e. expensive) databases for various purposes, such
> as driving, mapping, advertising, etc; all use one of the government
> address databases as their base. Enhance the base information with
> satellites, airplane and street view mapping.
>
>
> When a record is wrong, figuring out the source is a bit of an art.
>
> Mail/Shipping/Ecommerce => start with USPS database
>
> Telco/wireless/E911 => start with MSAG database
>
> Politics/Gerrymandering => start with Census database
>
> Tax, real estate, other => start with local building/planning department
>
>
> On Thu, 30 May 2024, Mike Hammett wrote:
> > This is the Internet, after all, so I will be corrected if I'm wrong.
> > 911 is based on MSAG (Master Street Address Guide), not USPS. However,
> many
> > operators are likely using the USPS system to sanitize the inputs.
>

Re: Congrats to AS701

[Nimrod Levy]

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: A few questions regarding about RPKI/invalids

[Nimrod Levy]

On Wed, Mar 30, 2022 at 10:35 AM Job Snijders via NANOG 
wrote:

>
> I'd reject them. Why carve out an exception merely because the
> number is 'large'? :-)
>
>
To add to this, many routes does not equal lots of traffic or even
important traffic.

If it continues to be invalid, someone didn't bother to make sure it works
everywhere.

Keep dropping them.

--
Nimrod

Re: The great Netflix vpn debacle! (geofeeds)

[Nimrod Levy]

On Wed, Sep 1, 2021 at 2:26 PM Michael Thomas  wrote:

>
> On 9/1/21 10:59 AM, Nimrod Levy wrote:
> > All this chatter about IPv6 support on devices is fun and all, but
> > there are providers still not on board.
> > They operate in my neighborhood and they know who they are...
> >
> This is about inside your premise before any NAT's enter the picture.
> What would be nice is if home routers offered up v6 as the default way
> to number and v6 tunnels past ISP's that don't have v6. Home routers
> could make that all rather seamless where users wouldn't need to know
> that was happening. It's really a pity that home routers are a race to
> the bottom where everything else with networking is expected to evolve
> over time.
>

I can't disagree about the quality of CPE, but I don't think that adding
tunnels by default is appropriate. We tried that with 6to4 and while that
worked, it didn't work well. Where would the far end of the tunnel
terminate? Who wants to build and manage that infrastructure? I'd rather
have the ISPs focus on deploying native IPv6 connectivity or at the very
worst, on-net 6rd. But I can tell you from experience that 6rd will only
take you so far before you figure out that you really needed native in the
first place.

Even more so, tunnels don't solve the problem that started this thread in
the first place. Netfilx (and probably others) consider IPv6 tunnel brokers
to be VPN providers and deny those connections. I stopped using a tunnel at
home for that very reason.

I think it's 100% appropriate for a CPE to not offer IPv6 on the inside
interfaces if it doesn't have a v6 upstream connection. What would the
point be?


> Mike
>

Re: The great Netflix vpn debacle! (geofeeds)

[Nimrod Levy]

All this chatter about IPv6 support on devices is fun and all, but there
are providers still not on board.
They operate in my neighborhood and they know who they are...

Nimrod

interesting troubleshooting

[Nimrod Levy]

I just ran into an issue that I thought was worth sharing with the NANOG
community. With recently increased visibility on keeping the Internet
running smoothly, I thought that sharing this small experience could
benefit everyone.

I was contacted by my NOC to investigate a LAG that was not distributing
traffic evenly among the members to the point where one member was
congested while the utilization on the LAG was reasonably low. Looking at
my netflow data, I was able to confirm that this was caused by a single
large flow of ESP traffic. Fortunately, I was able to shift this flow to
another path that had enough headroom available so that the flow could be
accommodated on a single member link.

With the increase in remote workers and VPN traffic that won't hash across
multiple paths, I thought this anecdote might help someone else track down
a problem that might not be so obvious.

Please take this message in the spirit in which it was intended and refrain
from the snarky "just upgrade you links" comments.

-- 
Nimrod

Re: Short-circuited traceroutes on FIOS

[Nimrod Levy]

I'm in the same region as Chris and I still can't make it fail. I wonder if
it's because I have static addressing?

On Tue, Dec 10, 2019 at 11:59 PM Christopher Morrow 
wrote:

> On Tue, Dec 10, 2019 at 11:44 PM Lee  wrote:
> > It's protocol specific.  Windows tracert uses icmp instead of udp.
> > On a linux box try
> >   ping -t 2 205.132.109.90
> >
> > You should get a time to live exceeded but the Verizon router gives
> > you an echo reply instead.
>
> that's hilariously bad :( I think this is the OLT really that's doing
> this...
> $ ping -t 3 205.132.109.90
> PING 205.132.109.90 (205.132.109.90) 56(84) bytes of data.
> From 130.81.32.236 icmp_seq=1 Time to live exceeded
>
> $ ping -t 1 205.132.109.90
> PING 205.132.109.90 (205.132.109.90) 56(84) bytes of data.
> From 192.168.100.1 icmp_seq=1 Time to live exceeded
>
> $ ping -t 2 205.132.109.90
> PING 205.132.109.90 (205.132.109.90) 56(84) bytes of data.
> 64 bytes from 205.132.109.90: icmp_seq=1 ttl=254 time=3.38 ms
>
> An outbound traceroute has:
>  1  _gateway (192.168.100.1)  2.537 ms  2.587 ms  2.703 ms
>  2  * * *
>  3  B3320.WASHDC-LCR-21.verizon-gni.net (130.81.32.236)  6.638 ms
> B3320.WASHDC-LCR-22.verizon-gni.net (130.81.32.238)  6.223 ms  6.414
> ms
> ...
>
> and inbound that hop 2 is:
>  6  HundredGigE2-4-0-3.WASHDC-LCR-22.verizon-gni.NET (140.222.238.55)
> 5.504 ms HundredGigE2-6-0-3.WASHDC-LCR-21.verizon-gni.NET
> (140.222.234.53)  9.261 ms  9.266 ms
>  7  ae203-0.WASHDC-VFTTP-320.verizon-gni.net ()  7.955 ms  3.026 ms
> ae204-0.WASHDC-VFTTP-320.verizon-gni.net (130.81.32.239)  2.347 ms
>
> oh well, just wonky gpon again?
>

Re: Short-circuited traceroutes on FIOS

[Nimrod Levy]

Is that unique to the FiOS gateway device? I don't use their router and my
traces go right out.


On Tue, Dec 10, 2019 at 3:08 PM Joe Maimon  wrote:

> Apparently Verizon FIOS is a red herring, terminating ICMP traceroutes
> right on their gateways.
>
> More internet breakage. Thanks for the information to all who responded.
>
> Random control test.
>
> C:\Users\Home>tracert -d 1.4.5.6
>
> Tracing route to 1.4.5.6 over a maximum of 30 hops
>
>115 ms 5 ms<1 ms  172.18.24.1
>2 3 ms23 ms24 ms  192.168.2.33
>3 3 ms 6 ms 3 ms  1.4.5.6
>
> Trace complete.
>
>
> Joe
>
> Joe Maimon wrote:
> > Anyone have an idea why there are some destinations that on
> > residential verizon fios here in NY area terminate right on first
> > external hop?
> >
> > There seems to be a CDN common denominator here. On other networks
> > with more typical BGP paths and traceroutes, users are reporting
> > issues accessing these sites.
> >
> > C:\Users\Home>tracert www.usfoods.com
> >
> > Tracing route to statics.usfoods.com [205.132.109.90]
> > over a maximum of 30 hops:
> >
> >   1 3 ms<1 ms<1 ms  172.18.24.1
> >   2 4 ms 3 ms 3 ms  192.168.2.33
> >   317 ms 6 ms 3 ms  statics.usfoods.com [205.132.109.90]
> >
> > Trace complete.
> >
> > C:\Users\Home>tracert atworkhp.americanexpress.com
> >
> > Tracing route to atworkhp.americanexpress.com.akadns.net [139.71.19.87]
> > over a maximum of 30 hops:
> >
> >   1 2 ms<1 ms<1 ms  172.18.24.1
> >   2 3 ms 4 ms23 ms  192.168.2.33
> >   321 ms11 ms 5 ms atworkhomepage2.americanexpress.com
> > [139.71.19.87]
> >
> > Trace complete.
> >
> > C:\Users\Home>tracert portal.discover.com
> >
> > Tracing route to e14577.x.akamaiedge.net [23.51.172.254]
> > over a maximum of 30 hops:
> >
> >   1 3 ms 1 ms18 ms  172.18.24.1
> >   221 ms 7 ms 6 ms  192.168.2.33
> >   3 4 ms 2 ms 2 ms
> > a23-51-172-254.deploy.static.akamaitechnologies.com [23.51.172.254]
> >
> > Trace complete.
> >
> >
> >
>
>

Re: ATT NOC

[Nimrod Levy]

We're not accepting the route from our peers due to the AS-SET in the path:
  174 199659 {65002}, (aggregated by 199659 10.10.10.3), (received-only)
  2914 199659 {65002}, (aggregated by 199659 10.10.10.1), (received-only)



On Tue, Oct 10, 2017 at 12:35 PM Gavin Henry  wrote:

> Hi Nimrod,
>
> Sorry. Our resolvers that are having the issue live at:
>
> 185.8.92.12
> 185.8.92.13
>
> part of 185.8.92.0/22
>
> Destination IP's we're trying to reach are:
>
> dns4.hertz.com has address 12.5.245.250
> dns5.hertz.com has address 12.147.231.250
> dns6.hertz.com has address 12.28.81.250
>
> These live within in our routing table:
>
> 12.5.245.0/24
> 12.147.231.0/24
> 12.28.81.0/24
>
> Thanks.
>
-- 

--
Nimrod

Re: ATT NOC

[Nimrod Levy]

Please provide source and destination.

On Tue, Oct 10, 2017 at 12:22 PM Gavin Henry  wrote:

> Hi all,
>
> For a while now (11 days) we've been trying to reach ATT as it some of
> our traffic is dying within their network. It's traffic destined for
> their customer networks so we can't raise a ticket with ATT directly.
> We've emailed their NOC, but nothing and since then been trying to
> raise tickes via phone with their customers that we can't reach, but
> we're not their customers eitherI'm pretty certain one of our /22
> is getting dropped, as our other /22 works (we're small guys).
>
> Can anyone help confirm our theory by putting us in touch?
>
> Thanks.
>
> --
> Kind Regards,
>
> Gavin Henry.
> Managing Director.
>
-- 

--
Nimrod

Re: ATT (AS7018) cannot reach AS31334

[Nimrod Levy]

>From what I can see, 31334 is sending prefixes covering this IP to
upstreams 1273 and 6939 (possibly others, but that's what I saw).  Neither
of these networks propagate those prefixes into 7018 directly or indirectly
so we have no path to get there.  I would encourage 31334 to check with
their upstreams to understand why the routes don't get sent to 7018.

--
Nimrod


On Mon, Apr 17, 2017 at 10:28 AM David Hill  wrote:

> Hi -
>
> I am a ATT customer unable to reach AS31334.  Is anyone on this list
> able to check into this?  It works from non-ATT route-servers I have
> tested on.
>
> ATT route-server
> 
> rvi...@route-server.ip.att.net> ping 2a02:8100:4:2::156e count 3
> PING6(56=40+8+8 bytes) 2001:1890:111d:1::28 --> 2a02:8100:4:2::156e
>
> --- 2a02:8100:4:2::156e ping6 statistics ---
> 3 packets transmitted, 0 packets received, 100% packet loss
>
> Thank you,
> David
>
-- 

--
Nimrod