Re: Fast backbone to NA from Asia

[Justin Streiner]

What do you mean by "really fast transit"?
Are you referring to round-trip latency?  If so, what sort of latency
target are you looking to hit?
Where in North America are you trying to reach, using which providers?
If the networks in North America and Asia are multihomed, that provides
some level of protection from peering disputes.

Thank you
jms


On Tue, May 21, 2024 at 8:25 AM Scott Q.  wrote:

> I apologize if this is off-topic, but I am looking to purchase some VPS in
> Asia on a network that has really fast transit to NA and not affected by
> the latest peering disputes. The network should have really good
> connectivity to India / Indonesia / Thailand and ideally Australia as well.
>
> Please reply off-list.
>

Re: IPv6 uptake (was: The Reg does 240/4)

[Justin Streiner]

We went pretty deep into the weeds on NAT in this thread - far deeper than
I expected ;)

Getting back to the recently revised topic of this thread - IPv6 uptake -
what have peoples' experiences been related to crafting sane v6 firewall
rulesets in recent products from the major firewall players (Palo Alto,
Cisco, Fortinet, etc)?  On the last major v6 deployment I did, working with
the firewalls was definitely one of the major pain points because the
support / stability was really lacking, or there wasn't full feature parity
between their v4 and v6 capabilities.

Thank you
jms

On Fri, Feb 16, 2024 at 11:04 PM William Herrin  wrote:

> On Fri, Feb 16, 2024 at 7:41 PM John R. Levine  wrote:
> > > That it's possible to implement network security well without using
> > > NAT does not contradict the claim that NAT enhances network security.
> >
> > I think we're each overgeneralizing from our individual expeience.
> >
> > You can configure a V6 firewall to be default closed as easily as you can
> > configure a NAT.
>
> Hi John,
>
> We're probably not speaking the same language. You're talking about
> configuring the function of one layer in a security stack. I'm talking
> about adding or removing a layer in a security stack. Address
> overloaded NAT in conjunction with private internal addresses is an
> additional layer in a security stack. It has security-relevant
> properties that the other layers don't duplicate. Regardless of how
> you configure it.
>
> Also, you can't "configure" a layer to be default closed. That's a
> property of the security layer. It either is or it is not.
>
> You can configure a layer to be "default deny," which I assume is what
> you meant. The issue is that anything that can be configured can be
> accidentally unconfigured. When default-deny is accidentally
> unconfigured, the network becomes wide open. When NAT is accidentally
> unconfigured, the network stops functioning entirely. The gate is
> closed.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: IPv6 uptake (was: The Reg does 240/4)

[Justin Streiner]

The Internet edge and core portion of deploying IPv6 - dual-stack or
otherwise - is fairly easy. I led efforts to do this at a large .edu
starting in 2010/11.  The biggest hurdles are/were/might still be:
1. Coming up with a good address plan that will do what you want and scale
as needed.  It should also be flexible enough to accommodate re-writes if
you think of something that needs to be added/changed down the road :)
2. For providers who run older kit, v6 support might still be a bit dodgy.
You might also run into things like TCAM exhaustion, neighbor table
exhaustion, etc.  The point at which box X tips over is often not well
defined and depends on your use case and configuration.
3. The last time I checked, v6 support in firewalls and other middle-mile
devices was still poor.  Hopefully that has gotten better in the last 6-7
years.  My current day job doesn't have me touching firewalls, so I haven't
kept up on developments here.  I recall coming up with a base firewall
ruleset for Cisco ASAs to balance security with the functionality v6 needs
to work correctly.  Hopefully firewall vendors have gotten better about
building templates to handle some of the heavy lifting.
4. Getting people to unlearn the "NAT=Security" mindset that we were forced
to accept in the v4 world.

Thank you
jms

On Thu, Feb 15, 2024 at 8:43 PM John Levine  wrote:

> It appears that Stephen Satchell  said:
> >Several people in NANOG have opined that there are a number of mail
> >servers on the Internet operating with IPv6 addresses.  OK.  I have a
> >mail server, which has been on the Internet for decades.  On IPv4.
> >
> >For the last four years, every attempt to get a PTR record in ip6.arpa
> >from my ISP has been rejected, usually with a nasty dismissive.
>
> I don't think you'll get much disagreement that AT is not a great ISP.
>
> One straightforward workaround is to get an IPv6 tunnel from
> Hurricane. It's free, it works, and they will delegate the rDNS
> anywhere you want. My local ISP doesn't do IPv6 at all (they're a
> rural phone company who of course say you are the only person who's
> ever asked) so until they do, HE is a quite adequate option.
>
> R's,
> John
>

Re: Outside plant - prewire customer demarc preference

[Justin Streiner]

We just built a new house in 2021. The builder ran 2" schedule 40 from the
side of the house out to the distribution point in front of my neighbor's
house.  I didn't specify 2" - that's what the builder ran.  A portion of
that run must have existed before construction because no one had to tear
up my neighbor's yard to get to the distro box.

Once I convinced Verizon that Fios was indeed available in this
neighborhood (separate matter entirely), it was an easy matter for the tech
to pull the drop cable through the empty conduit, drill a hole a few feet
above the foundation and land the cable in the basement.

I didn't run any surface tube or conduit in the basement, but there was
enough room for the install tech to run the cable without too much of a
fight.

Thank you
jms

On Fri, Dec 8, 2023, 2:06 PM Eric Kuhnke  wrote:

> If anyone assumes that residential real estate general contractors and low
> voltage/wiring subcontractors know or care about wifi signal or not putting
> RF units inside metal boxes - that would be a bad assumption to make.
>
>
> On Thu, Dec 7, 2023 at 10:18 PM Jay Hennigan  wrote:
>
>> On 12/6/23 23:22, Eric Kuhnke wrote:
>> > I think an important point for pre-wire and residential real estate
>> > developers to consider is also the conflicting needs of keeping things
>> > "neat and tidy" and last mile CPE location vs wifi coverage.
>>
>> If you assume that the appropriate place for a wifi access point is
>> colocated with the NID/ONT/CPE, you're doing it wrong.
>>
>> --
>> Jay Hennigan - j...@west.net
>> Network Engineering - CCIE #7880
>> 503 897-8550 - WB6RDV
>>
>>

Re: Your input sought on PeeringDB's Network Type field

[Justin Streiner]

Leo:

The survey might also want to include response options along the lines of:
"Don't know / N/A".

Thank you
jms


On Wed, Jun 14, 2023 at 12:18 PM Leo Vegoda  wrote:

> Hi,
>
> PeeringDB's Product Committee wants your input on whether the Network
> Type field is useful. Should it go? Should it change?
>
> We have published a very short blog post describing the options and
> linking to the survey.
>
> https://docs.peeringdb.com/blog/network_type_your_input_sought/
>
> Your input will influence our decision.
>
> Thanks,
>
> Leo Vegoda for PeeringDB's Product Committee
>

Re: Do ISP's collect and analyze traffic of users?

[Justin Streiner]

Hank:

No doubt there is a massive amount of information that can be gathered from
in-box telemetry.  This thread appears to be more focused on providers
gathering data from traffic in flight across their infrastructure.

Thank you
jms

On Fri, May 19, 2023 at 8:49 AM Hank Nussbacher 
wrote:

> On 19/05/2023 15:27, Justin Streiner wrote:
>
> It amazes me how people can focus on Netflow metadata and ignore things
> like Microsoft telemetry data from every Windows box, or ignore the
> massive amount of html cookies that are traded by companies or how
> almost every corporate firewall or anti-spam box "reports" back to the
> mother ship and sends tons of information via secret channels like
> hashed DNS lookups just to be avoided.
>
> Regards,
> Hank
>
> > There are already so many different ways that organizations can find
> > out all sorts of information about individual users, as others have
> > noted (social media interactions, mobile location/GPS data, call/text
> > history, interactions with specific sites, etc), that there probably
> > isn't much incentive for many providers to harvest data beyond what is
> > needed for troubleshooting and capacity planning.  Plus, gathering
> > more data - potentially down to the level packet payload - is not an
> > easy problem to solve (read: expensive) and doesn't scale well at all.
> > 100G links are very common today, and 400G is becoming so.  I doubt
> > that many infrastructure providers would be able to justify the major
> > investments in extra infrastructure to support this, for a revenue
> > stream that likely wouldn't match that investment, which would make
> > such an investment a loss-leader.
> >
> > Content providers - particularly social media platforms - have a
> > somewhat different business model, but those providers already have
> > many different ways to harvest and sell large troves of user data.
> >
> > Thank you
> > jms
>
>

Re: Do ISP's collect and analyze traffic of users?

[Justin Streiner]

There are already so many different ways that organizations can find out
all sorts of information about individual users, as others have noted
(social media interactions, mobile location/GPS data, call/text history,
interactions with specific sites, etc), that there probably isn't much
incentive for many providers to harvest data beyond what is needed for
troubleshooting and capacity planning.  Plus, gathering more data -
potentially down to the level packet payload - is not an easy problem to
solve (read: expensive) and doesn't scale well at all. 100G links are very
common today, and 400G is becoming so.  I doubt that many infrastructure
providers would be able to justify the major investments in extra
infrastructure to support this, for a revenue stream that likely wouldn't
match that investment, which would make such an investment a loss-leader.

Content providers - particularly social media platforms - have a somewhat
different business model, but those providers already have many different
ways to harvest and sell large troves of user data.

Thank you
jms

On Tue, May 16, 2023 at 3:44 PM Matthew Petach 
wrote:

>
>
> On Tue, May 16, 2023 at 1:10 AM Jeroen Massar  wrote:
>
>>
>>
>> > On 16 May 2023, at 06:46, Matthew Petach  wrote:
>> > [..]
>> > I admit, I'm perhaps a little behind on the latest netflow whiz-bangs,
>> > but I've never seen a netflow record type that included HTTP cookies
>> > or PCAP data before.
>>
>> Take your pick from the "latest" ~2009 IPFIX Information Elements:
>>
>> https://www.iana.org/assignments/ipfix/ipfix.xhtml
>>
>> One can stuff almost anything in there.
>>
>> Now if one should, and if one is allowed to.
>>
>
> Wow.
>
> Thank you, Jeroen, I was indeed a bit out of date.
> Thank you for the pointer!
>
> (For those in the same boat as I, here's the relevant portion that clearly
> points out that yes, you can export the entire packet if you so desire):
>
> 313 ipHeaderPacketSection octetArray default current
>
> This Information Element carries a series of n octets from the IP header
> of a sampled packet, starting sectionOffset octets into the IP header.
>
> However, if no sectionOffset field corresponding to this Information
> Element is present, then a sectionOffset of zero applies, and the octets
> MUST be from the start of the IP header.
>
> With sufficient length, this element also reports octets from the IP
> payload. However, full packet capture of arbitrary packet streams is
> explicitly out of scope per the Security Considerations sections of [
> RFC5477 ] and [RFC2804
> ].
>
>
>
>  Thanks!
>
> Matt
> (still learning after all these years.   ^_^ )
>
>

Re: Aptum refuses to SWIP

[Justin Streiner]

When I worked for a local/regional ISP in the late 90s/early 00s, we
initially SWIP'd assignments for business customers and did generic
assignments for things like dial-up address pools or NAT front-end ranges
for residential customers, but provided more detailed information for
business customers.  Around 1998/1999 we switched from doing SWIPs to
running our own rwhois server.  Because we had good documentation, our IP
block requests to ARIN were generally pretty painless.

Thank you
jms

On Thu, May 4, 2023 at 5:36 PM Lyndon Nerenberg (VE7TFX/VE6BBM) <
lyn...@orthanc.ca> wrote:

> It seems Aptum has decided they will no longer SWIP any of their
> address space.  I've been trying to get a SWIP for a /48 that we
> were allocated in 2017, but they refuse.  And I also see they have
> pro-actively gone in and un-SWIPed both our /24s.
>
> Since you are ignoring my tickets about this, maybe somebody from
> Aptum would care to speak up in public and defend this "policy?"
>
> --lyndon
>

Re: Windstream/Kinetic OSP assistance/clie sought

[Justin Streiner]

Other people on their street do have Kinetic, and I believe Windstream laid
cable from the street to their house, but they are being told there are no
facilities to connect them to an OLT or some other type of termination
device.

Thank you
jms

On Sat, Apr 22, 2023, 23:58 Alex Ryu  wrote:

> It is new construction home, it may be HoA, so it is controlled by HoA
> which may have some deal with one provider for landline.
>
> So it may be dictated by HoA until it reach to certain level when that
> binding deal is expired.
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows
>
>
>
> *From: *Justin Streiner 
> *Sent: *Saturday, April 22, 2023 10:46 PM
> *To: *NANOG 
> *Subject: *Windstream/Kinetic OSP assistance/clie sought
>
>
>
> Some of my family recently moved to an area of North Carolina where
> high-speed residential Internet connectivity options seem to be very
> limited. Outside of the options below, the only thing they're able to get
> is satellite Internet service, and the performance has been very poor
>
>
>
> They moved into an area where the neighbors have Kinetic (Windstream's
> Internet service) but my relatives have been told that there are no
> facilities available for them. This is new construction, so perhaps it's
> possible that their address hasn't been added into whatever systems
> Windstream/Kinetic use for service pre-qualification?
>
>
>
> Is there anyone I can talk to at Winstream to find out if it is indeed
> possible to get service at their address, or if there is way I can get past
> the gatekeepers?
>
>
>
> Any guidance from someone in the know at Windstream would be greatly
> appreciated.
>
>
>
> Thank you
>
> jms
>
>
>
>
>

Windstream/Kinetic OSP assistance/clie sought

[Justin Streiner]

Some of my family recently moved to an area of North Carolina where
high-speed residential Internet connectivity options seem to be very
limited. Outside of the options below, the only thing they're able to get
is satellite Internet service, and the performance has been very poor

They moved into an area where the neighbors have Kinetic (Windstream's
Internet service) but my relatives have been told that there are no
facilities available for them. This is new construction, so perhaps it's
possible that their address hasn't been added into whatever systems
Windstream/Kinetic use for service pre-qualification?

Is there anyone I can talk to at Winstream to find out if it is indeed
possible to get service at their address, or if there is way I can get past
the gatekeepers?

Any guidance from someone in the know at Windstream would be greatly
appreciated.

Thank you
jms

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

[Justin Streiner]

Sounds like either the National Driver Register or NHTSA is single-homed to
Verizon, or the state DMVs each have a WAN circuit of some sort through
Verizon to where the National Driver Register system physically lives.  If
it's the latter, it sounds like a job that could be handled much more
effectively using site-to-site VPN tunnels, but I understand the realities
of being stuck in a long-term contract, policy mandates that dictate a
physical connection, or things along those lines.  Government agencies can
and sometimes do get funding for infrastructure upgrades and resiliency -
at least if they budget for it...

I'm sure the backstory here is both mundane and interesting.

Thank you
jms

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.
>
> 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: Why are ad networks so slow with IPv6?

[Justin Streiner]

Is your experience the same if you run a browser-based ad blocker or
something external like Pi-hole?  I have Fios, but Verizon hasn't rolled v6
out here that I can see.  My v6 traffic runs over a tunnel to Hurricane
Electric, and I haven't noticed any unusually slow load times for the ads
that make it through Pi-hole/uBlock/etc.

Thank you
jms

On Mon, Jul 11, 2022 at 11:03 AM Sean Donelan  wrote:

>
> Verizon FIOS has been rolling out IPv6 across Northern Virginia. Hurrah!
>
> Stuff with ads (which is almost everything on the modern Internet) now
> load much more slowly or timeout.
>
>
> Changed IPv4/IPv6 connection preferences to use IPv4 first. Much improved
> user experience.
>

Re: Reporting Comcast outside plant issues?

[Justin Streiner]

Thank you to everyone who responded off-list.  I was able to get a repair
ticket opened with Comcast and they will be dispatching a crew to take a
look.

Thank you
jms

On Sun, Jun 26, 2022 at 10:27 PM Justin Streiner 
wrote:

> Does anyone here have a contact at Comcast for reporting outside plant
> issues that are not (at the moment) service-affecting? I am not a Comcast
> customer, and they make it nearly impossible for non-customers to reach
> them unless you're signing up for service.
>
> There is a long coax span (2-300 feetthat has come off of a pair of
> utility poles and is laying on the ground near my house. I moved it off of
> the road to keep it from getting run over, but reaching anyone at Comcast
> to get the cable re-attached to the poles has been difficult.
>
> Any insight anyone (off-list is fine) could offer would be appreciated.
>
> Thank you
> jms
>
>
>

Reporting Comcast outside plant issues?

[Justin Streiner]

Does anyone here have a contact at Comcast for reporting outside plant
issues that are not (at the moment) service-affecting? I am not a Comcast
customer, and they make it nearly impossible for non-customers to reach
them unless you're signing up for service.

There is a long coax span (2-300 feetthat has come off of a pair of utility
poles and is laying on the ground near my house. I moved it off of the road
to keep it from getting run over, but reaching anyone at Comcast to get the
cable re-attached to the poles has been difficult.

Any insight anyone (off-list is fine) could offer would be appreciated.

Thank you
jms

Re: Congrats to AS701

[Justin Streiner]

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.

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: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Justin Streiner]

Abe:

To your first point about denying that anyone is being stopped from working
on IPv4, I'm referring to users being able to communicate via IPv4.  I have
seen no evidence of that.

I'm not familiar with the process of submitting ideas to IETF, so I'll
leave that for others who are more knowledgeable on that to speak up if
they're so inclined.

Thank you
jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen  wrote:

>
> 1)"... no one is stopping anyone from working on IPv4 ... ":
> After all these discussions, are you still denying this basic issue? For
> example, there has not been any straightforward way to introduce IPv4
> enhancement ideas to IETF since at least 2015. If you know the way, please
> make it public. I am sure that many are eager to learn about it. Thanks.
>

Re: are underwater routers a thing?

[Justin Streiner]

High voltage DC from landing stations to the underwater amps and submarine
branching units.

jms

On Thu, Mar 17, 2022, 22:46 Karl Auer  wrote:

> On Thu, 2022-03-17 at 21:26 -0500, Jerry Cloe wrote:
> > First thing that comes to mind is power, how would you power them?
>
> Hydroelectricity (or wave energy), *obviously*. Sheesh.
>
> :-)
>
> Regards, K.
>
> --
> ~~~
> Karl Auer (ka...@biplane.com.au)
> http://www.biplane.com.au/kauer
>
> GPG fingerprint: 61A0 99A9 8823 3A75 871E 5D90 BADB B237 260C 9C58
> Old fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170
>
>
>
>

Re: home router battery backup

[Justin Streiner]

I'm one of the atypical users, when compared to the population at large,
but probably in line for this audience.

Critical gear is on a transfer switch and both inputs to that come from
UPSs that are on separate circuits. Less critical gear is fed from one UPS
or the other to balance the load and allow headroom for a load shift due to
a UPS failure.  My office gear is on a separate UPS on a different circuit.

Thank you
jms

On Wed, Jan 12, 2022, 13:01 Scott T Anderson via NANOG 
wrote:

> Hi NANOG mailing list,
>
>
>
> I am a graduate student, currently conducting research on how power
> outages affect home Internet users. I know that the FCC has a regulation
> since 2015 (47 CFR Section 9.20) requiring ISPs to provide an option to
> voice customers to purchase a battery backup for emergency voice services
> during power outages. As this is only an option and only applies to
> customers who subscribe to voice services, I was wondering if anyone had
> any insights on the prevalence of battery backup for home modem/routers?
> I.e., what percentage of home users actually install a battery backup in
> their home modem/router or use an external UPS?
>
>
>
> Thanks.
>
> Scott
>
>
>
> Reference for 47 CFR Section 9.20:
> https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9/subpart-H/section-9.20
>
>
>

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Justin Streiner]

The proposals I've seen all seem to deliver minimal benefit for the massive
lift (technical, administrative, political, etc) involved to keep IPv4
alive a little longer.

Makes about as much sense as trying to destabilize US currency by
counterfeiting pennies.

Thank you
jms



On Thu, Nov 18, 2021 at 12:39 PM Joe Maimon  wrote:

>
>
> John R. Levine wrote:
> >> The only effort involved on the IETF's jurisdiction was to stop
> >> squatting on 240/4 and perhaps maybe some other small pieces of IPv4
> >> that could possibly be better used elsewhere by others who may choose
> >> to do so.
> >
> > The IETF is not the Network Police, and all IETF standards are
> > entirely voluntary.
>
> And that is exactly why they said that even though they think it might
> possibly entail similar effort to deployment of IPv6 and that IPv6 is
> supposed to obsolete IPv4 before any such effort can be realized, they
> would be amenable to reclassifying 240/4 as anything other than
> reserved, removing that barrier from those whom may voluntarily decide
> to follow that updated standard, should they find the time to squeeze in
> another project the same size and effort of IPv6 into their spare time.
>
> Seems the IETF does indeed think it is the network police. And that they
> get to decide winners and losers.
> >
> > Nothing is keeping you from persuading people to change their software
> > to treat class E addresses as routable other than the detail that the
> > idea is silly.
> >
> > R's,
> > John
> >
>
> And indeed, they have done so. Now who looks silly?
>
> Joe
>
>

Re: S.Korea broadband firm sues Netflix after traffic surge

[Justin Streiner]

On Wed, Oct 20, 2021 at 3:41 PM Matthew Walster  wrote:
The user initiates the connection to the CDN. The user is paying for a
level of access to the internet via the BT network, with varying tiers of
speed at particular costs. They are advertised as "Unlimited broadband: With
no data caps or download limits, you can do as much as you like online." on
their website. Many CDNs bring the data closer to the customer, either
embedded within their network, or meeting at various PoPs/IXPs around the
country.

Seems pretty disingenuous to now say the called party has to pay as well,
in stark contrast to decades of precedent with their telephone product,
just because their customers are actually using what they were sold.

All in all, this raises an interesting question. Is British Telecom running
> their networks so hot, that just keeping the lights on requires capacity
> upgrades or are they just looking for freebies?


What happened is pretty clear, and not just for BT or SK.  Those providers,
as a business decision, built their business models around a certain level
of oversubscription that would strike a balance between customers not being
unhappy and squeezing as much headroom out of the network before upgrades
are required (beefier routers/switches, fatter pipes, more peering/transit,
etc).  That business model got upended when that acceptable level of
oversubscription changed.  Video streaming was the puddle of
gasoline/petrol on the floor, and the change in user traffic patterns was
the lit match.

By asking content providers to hand over money to those carriers in
exchange for (better) access to their customers, many of the ISPs could in
fact be triple-dipping because they already get revenue from their
customers and some also get various government subsidies to provide certain
types of service or services in certain areas.

Definitely doesn't pass the sniff test.

Thank you
jms

>

Re: IPv6 woes - RFC

[Justin Streiner]

On Sat, Sep 4, 2021, 22:49 John Levine  wrote:

> I have asked my ISP about IPv6 and their answer is that that they're not
> opposed to
> it but since I am the only person who has asked for it, it's quite low on
> the list
> of things to do.
>

Sounds like a consulting opportunity :)

Thank you
jms

>

Re: FreeBSD's ping Integrates IPv6

[Justin Streiner]

I think he meant that the underlying OS on lots of network gear is either
some variant of Linux or BSD.

Thank you
jms

On Sun, Jul 4, 2021, 11:40 Mark Tinka  wrote:

>
>
> On 7/4/21 17:15, Bjørn Mork wrote:
>
> > I seriously doubt that.  You're just not aware of it.
>
> I think I'd know if I've run "ping" on a box.
>
> Mark.
>

Re: Microsoft problems...

[Justin Streiner]

Can you be a bit more specific regarding what you're seeing or not seeing?

Are you reaching MS through IP transit/peer connections, or are you having
issues reaching MS cloud services over ExpressRoute circuits?

Thank you
jms

On Mon, Mar 15, 2021 at 4:04 PM  wrote:

> Anyone else noticing major MAJOR problems with various MS services?
>
> Geoff
>
>

Re: Famous operational issues

[Justin Streiner]

An interesting sub-thread to this could be:

Have you ever unintentionally crashed a device by running a perfectly
innocuous command?
1. Crashed a 6500/Sup2 by typing "show ip dhcp binding".
2. "clear interface XXX" on a Nexus 7K triggered a cascading/undocument
Sev1 bug that caused two linecards to crash and reload, and take down about
two dozen buildings on campus at the .edu where I used to work.
3. For those that ever had the misfortune of using early versions of the
"bcc" command shell* on Bay Networks routers, which was intended to make
the CLI make look and feel more like a Cisco router, you have my
condolences.  One would reasonably expect "delete ?" to respond with a list
of valid arguments for that command.  Instead, it deleted, well...
everything, and prompted an on-site restore/reboot.

BCC originally stood for "Bay Command Console", but we joked that it really
stood for "Blatant Cisco Clone".

On Tue, Feb 16, 2021 at 2:37 PM John Kristoff  wrote:

> Friends,
>
> I'd like to start a thread about the most famous and widespread Internet
> operational issues, outages or implementation incompatibilities you
> have seen.
>
> Which examples would make up your top three?
>
> To get things started, I'd suggest the AS 7007 event is perhaps  the
> most notorious and likely to top many lists including mine.  So if
> that is one for you I'm asking for just two more.
>
> I'm particularly interested in this as the first step in developing a
> future NANOG session.  I'd be particularly interested in any issues
> that also identify key individuals that might still be around and
> interested in participating in a retrospective.  I already have someone
> that is willing to talk about AS 7007, which shouldn't be hard to guess
> who.
>
> Thanks in advance for your suggestions,
>
> John
>

Re: Famous operational issues

[Justin Streiner]

Beyond the widespread outages, I have so many personal war stories that
it's hard to pick a favorite.

My first job out of college in the mid-late 90s was at an ISP in Pittsburgh
that I joined pretty early in its existence, and everyone did a bit of
everything. I was hired to do sysadmin stuff, networking, pretty much
whatever was needed. About a year after I started, we brought up a new mail
system with an external RAID enclosure for the mail store itself.  One day,
we saw indications that one of the disks in the RAID enclosure was starting
to fail, so I scheduled a maintenance window to replace the disk and let
the controller rebuild the data and integrate it back into the RAID set.
No big worries, right?

It's Tuesday at about 2 AM.

Well, the kernel on the RAID controller itself decided that when I pulled
the failing drive would be a fine time to panic, and more or less turn
itself into a bit-blender, and take all the mailstore down with it.  After
a few hours of watching fsck make no progress on anything, in terms of
trying to un-fsck the mailstore, we made the decision in consultation with
the CEO to pull the plug on trying to bring the old RAID enclosure back to
life, and focus on finding suitable replacement hardware and rebuild from
scratch.  We also discovered that the most recent backups of the mailstore
were over a month old :(

I think our CEO ended up driving several hours to procure a suitable
enclosure.  By the time we got the enclosure installed, filesystems built,
and got whatever tape backups we had restored, and tested the integrity of
the system, it was now Thursday around 8 AM. Coincidentally, that was the
same day the company hosted a big VIP gathering (the mayor was there, along
with lots of investors and other bigwigs), so I had to come back and put on
a suit to hobnob with the VIPs after getting a total of 6 hours of sleep in
about the previous 3 days.  I still don't know how I got home that night
without wrapping my vehicle around a utility pole (due to being over-tired,
not due to alcohol).

Many painful lessons learned over that stretch of days, as often the case
as a company grows from startup mode and builds more robust technology and
business processes as a consequence of growth.

jms

On Tue, Feb 16, 2021 at 2:37 PM John Kristoff  wrote:

> Friends,
>
> I'd like to start a thread about the most famous and widespread Internet
> operational issues, outages or implementation incompatibilities you
> have seen.
>
> Which examples would make up your top three?
>
> To get things started, I'd suggest the AS 7007 event is perhaps  the
> most notorious and likely to top many lists including mine.  So if
> that is one for you I'm asking for just two more.
>
> I'm particularly interested in this as the first step in developing a
> future NANOG session.  I'd be particularly interested in any issues
> that also identify key individuals that might still be around and
> interested in participating in a retrospective.  I already have someone
> that is willing to talk about AS 7007, which shouldn't be hard to guess
> who.
>
> Thanks in advance for your suggestions,
>
> John
>

Re: Famous operational issues

[Justin Streiner]

On Thu, Feb 18, 2021 at 5:38 PM Warren Kumari  wrote:

>
> 2: A somewhat similar thing would happen with the Ascend TNT Max, which
> had side-to-side airflow. These were dial termination boxes, and so people
> would install racks and racks of them. The first one would draw in cool air
> on the left, heat it up and ship it out the right. The next one over would
> draw in warm air on the left, heat it up further, and ship it out the
> right... Somewhere there is a fairly famous photo of a rack of TNT Maxes,
> with the final one literally on fire, and still passing packets.
>

We had several racks of TNTs at the peak of our dial POP phase, and I
believe we ended up designing baffles for the sides of those racks to pull
in cool air from the front of the rack to the left side of the chassis and
exhaust it out the back from the right side.  It wasn't perfect, but it did
the job.

The TNTs with channelized T3 interfaces were a great way to terminate lots
of modems in a reasonable amount of rack space with minimal cabling.

Thank you
jms

Re: Famous operational issues

[Justin Streiner]

Would this also extend to intentional actions that may have had unintended
consequences, such as provider A intentionally de-peering provider B, or
the monopoly telco for $country cutting itself off from the rest of the
global Internet for various reasons (technical, political, or otherwise)?

That said, I'd still have to stick with AS7007, the Baltimore tunnel fire,
and 9/11 as the most prominent examples of widespread issues/outages and
how those issues were addressed.

Honorable mention: $vendor BGP bugs, either due to $vendor ignoring the
relevant RFCs, implementing them incorrectly, or an outage exposed a design
flaw that the RFCs didn't catch.  Too many of those to list here :)

jms

On Tue, Feb 16, 2021 at 2:37 PM John Kristoff  wrote:

> Friends,
>
> I'd like to start a thread about the most famous and widespread Internet
> operational issues, outages or implementation incompatibilities you
> have seen.
>
> Which examples would make up your top three?
>
> To get things started, I'd suggest the AS 7007 event is perhaps  the
> most notorious and likely to top many lists including mine.  So if
> that is one for you I'm asking for just two more.
>
> I'm particularly interested in this as the first step in developing a
> future NANOG session.  I'd be particularly interested in any issues
> that also identify key individuals that might still be around and
> interested in participating in a retrospective.  I already have someone
> that is willing to talk about AS 7007, which shouldn't be hard to guess
> who.
>
> Thanks in advance for your suggestions,
>
> John
>

Re: IPv4 Mismanagement

[Justin Streiner]

It is a thankless task, but something that becomes increasingly important
as $provider starts to run low on IPv4 space to assign to customers.

Thank you
jms

On Mon, Oct 5, 2020, 20:19 Tom Hill  wrote:

> On 04/10/2020 02:17, Wayne Bouchard wrote:
> > Groups that have such things I can only presume do not do a good job
> > of periodically going through and auditing their IP allocations or, if
> > they do, then they don't do a good enough job of cleaning up all the
> > details.
>
> It is a long-winded, laborious, thankless task (well, mostly thankless)
> and we should be writing software to do it for us. Of course, we all
> know how bad everyone is at that, ergo it isn't often done.
>
> On the other hand, perhaps these ISPs are worried that they might be
> audited by an RIR?
>
> --
> Tom
>

Re: IPv4 Mismanagement

[Justin Streiner]

I suspect many providers don't have good business processes for reclaiming
IP space that was assigned to customers who have either disconnected or
voluntarily returned the space.

The provider I started out with in the mid/late 90s bootstrapped itself
with IP space from MCI (now, CenturyLink... I think?) and UUNET (now
Verizon Business), but we handed those blocks back when we started getting
provider-independent space from ARIN.  No idea what became of that space
after we stopped announcing it.

jms

On Fri, Oct 2, 2020 at 3:38 PM Ryan Wilkins  wrote:

> I have the same thing with a service that was disconnected a couple years
> ago.  Four IP blocks of /24 size are still swipped to us and we’re
> announcing them.  I don’t put any customers on them and just use them for
> temporary things for fear that some day someone will want them back.
>
> On Oct 2, 2020, at 2:50 PM, Matt Brennan  wrote:
>
>
> A service I disconnected more than 2 years ago still has a /24 of their
> space SWIPED to me. Their NOC closed the ticket I opened to remove. Unknown
> if it's actually in use for another customer.
>
> I also had a conversation last week with another ISP (we were
> renegotiating our contract) about this. The order form they sent me had
> multiple /28's we had "given back" years ago still listed. Turns out
> they're still being routed to us as well.
>
> I would bet it happens all over the place.
>
> -Matt
>
> On Fri, Oct 2, 2020 at 2:00 PM Matt Hoppes <
> mattli...@rivervalleyinternet.net> wrote:
>
>> I'm sitting here in the office on a Friday performing some IP
>> maintenance and I see that one of our upstreams is still filtering an IP
>> range we haven't used in years.   I dig into it a bit more and it turns
>> out a major carrier still has them SWIPed to us.
>>
>> This got me curious and I dug more into IPs from back in our early days
>> and discovered there are two Tier-1 carriers we no longer do business
>> with that still have large blocks of their own IPs SWIPED and allocated
>> to us.
>>
>> This is really confusing and concerning.   I know it's not the
>> end-all-be-all, but I wonder how much IPv4 exhaustion is being caused by
>> this type of IPv4 mis-management, where IPs are still shown as
>> "allocated" to a customer who hasn't used them in years.
>>
>> I've seen this behavior from Frontier and CenturyLink to name just a few.
>>
>> Any thoughts on this?
>>
>
>

Re: RIPE our of IPv4

[Justin Streiner]

On Sat, Nov 30, 2019 at 7:58 PM Brandon Martin 
wrote:

> Does Verizon still own/manage ANY of their Fios territories?  I thought it
> was all sold off to Frontier at this point.  It certainly all is, along
> with all their legacy LEC territories not having FTTx and having some form
> of DSL, around here.  The latter DSL offerings are usually pretty
> hilarious.  It's mostly run out of the CO or existing RTUs from the POTS
> era.  I can't imagine they have a ton of subscribers outside of areas with
> literally no other wireline options, and I'm guessing a lot of that
> infrastructure hasn't been touched in a decade-plus.
>
> Is Frontier-managed Fios included in those numbers regardless, or are they
> separate like I'd expect them to be?
>

I don't think those numbers include wireline territories that were
transferred from Verizon to Frontier, but in my area (western
Pennsylvania), Fios service is provided by Verizon.

Verizon hasn't updated their IPv6 resource site since at least 2012.  It
still includes a subtle but significant typo. A /56 does not give you "56
LANs"

Requests for updates from front-line customer service go into a black hole,
as do sidebar questions to our Verizon account team at $dayjob.

jms

Re: RIPE our of IPv4

[Justin Streiner]

On Sat, Nov 30, 2019 at 11:46 AM Ca By  wrote:

>
> That said, google see nearly 40% of their traffic on  ipv6 in the usa ,
> growth trend looks strong
>
> https://www.google.com/intl/en/ipv6/statistics.html
>
> And
>
> Comcast (71%), Charter (52%), VZ (85%),  ATT (60 and 78%) , and T-Mobile
> (95%) have the majority of their subs on ipv6
>
> https://www.worldipv6launch.org/measurements/
>

Verizon is an interesting case.  While IPv6 penetration on the wireless
side is very high, the same is not true on the Fios/DSL side.  IPv6
deployment there is nearly nonexistent.
I've heard rumblings that some early Fios users will need to have their
ONTs replaced to be able to get v6, regardless if the router itself
supports it.  I don't know if this is true, because I've never been able to
get a straight/authoritative answer from Verizon.

While a tunnel from HE works perfectly well, it would be nice to have
native v6 from VZ.

jms


> Sadly, ipv6 is creating a bifurcation of the internet.  Scale shops have
> v6, and non-scale shops don’t. The big players are pulling away, and that
> makes things bleak for the folks just trying to tread water in ipv4.
>
>
>>
>> Frankly, I'm surprised anti-IPv6 people still have employment.
>>
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>>
>> -Brian
>>
>>
>> --
>> *From: *"Brian Knight" 
>> *To: *"Mark Andrews" 
>> *Cc: *"nanog" 
>> *Sent: *Friday, November 29, 2019 10:29:17 AM
>> *Subject: *Re: RIPE our of IPv4
>>
>>
>> > On Nov 27, 2019, at 4:04 PM, Mark Andrews  wrote:
>> >
>> > 
>> >
>> >> On 28 Nov 2019, at 06:08, Brian Knight  wrote:
>> >>
>> >>> On 2019-11-26 17:11, Ca By wrote:
>> >>> On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha > >
>> >>> wrote:
>>  - On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us
>> wrote:
>> >>
>> >> [snip]
>>  there is no ROI at this point. In this kind of environment there
>> needs to
>>  be a strong case to invest the capex to support IPv6.
>>  IPv6 must be supported on the CxO level in order to be deployed.
>>  Thanks,
>>  Sabri, (Badum tsss) MBA
>> >>> I seewell let me translate it you MBA-eese for you:
>> >>> FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the
>> cohort
>> >>> experienced 300% CAGR. Also, everything is mobile, and all mobile
>> providers
>> >>> in the usa offer ipv6 by default in most cases. Latency! Scale! As
>> your
>> >>> company launches its digital transformation iot 2020 virtualization
>> >>> container initiatives, ipv6 will be an integral part of staying
>> relevant on
>> >>> the blockchain.  Also, FANG did it nearly 10 years ago.  Big content
>> and
>> >>> big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance
>> and
>> >>> iot botnets.
>> >>
>> >> None of which matters a damn to almost all of my business eyeball
>> customers.  They can still get from our network to 100% of all Internet
>> content & services via IPv4 in 2019.
>> >
>> > No you can’t.  You can’t reach the machine I’m typing on via IPv4 and
>> it is ON THE INTERNET.  It is directly reachable via IPv6.  Selling
>> Internet connectivity without IPv6 should be considered fraud these days.
>> Don’t
>> > you believe in “Truth in Advertising”?
>>
>> I had meant to write “They can still get from our network to 100% of all
>> Internet content and services that matter to them [our customers] via
>> IPv4...”
>>
>> 0% of my IPv4-only customers have opened tickets saying they cannot reach
>> some service that is only IPv6 accessible. So if they do care about IPv6
>> connectivity, they haven’t communicated that to us.
>>
>> > Mark Andrews, ISC
>> > 1 Seymour St., Dundas Valley, NSW
>> 
>> 2117, Australia
>> > PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>> >
>>
>> Thanks,
>>
>> -Brian
>>
>>

Re: IPv6 Thought Experiment

[Justin Streiner]

I suspect that even if there was an entity with the reach to impose such a
tax, people will resort to deploying CGN more, to hide their IPv4 usage to
the extent possible.  That's time, money, and effort taken away from moving
to IPv6.

You might also find that many taxed organizations will simply ignore the
tax or refuse to pay it, under the assumption that the taxing entity
doesn't have standing to impose such taxes.  Someone from Russia is likely
to take a tax notice from, say, some agency in the USA and toss it in the
circular file :)

As others have said, threatening the Internet community with punitive
action is a sure way to discourage people from adopting IPv6.  While the
pace of adoption might not be acceptable to some, everyone has to move at
their own pace, or vote with their wallets where possible.

Thank you
jms

On Wed, Oct 2, 2019 at 12:34 PM Antonios Chariton 
wrote:

> Dear list,
> First of all, let me apologize if this post is not allowed by the list. To
> my best interpretation of the guidelines [1] it is allowed, but may be in a
> gray area due to rule #7.
>
> I would like to propose the following thought experiment about IPv6, and I
> would like your opinion on what you believe would happen in such a case.
> Feel free to reply on or off list.
>
> What if, globally, and starting at January 1st, 2020, someone (imagine a
> government or similar, but with global reach) imposed an IPv4 tax. For
> every IPv4 address on the Global Internet Routing Table, you had to pay a
> tax. Let’s assume that this can be imposed, must be paid, and cannot be
> avoided using some loophole. Let’s say that this tax would be $2, and it
> would double, every 3 or 6 months.
>
> What do you think would happen? Would it be the only way to reach 100%
> IPv6 deployment, or even that wouldn’t be sufficient?
>
> And for bonus points, consider the following: what if all certification
> bodies of equipment, for certifications like FCC’s or CE in Europe, for
> applications after Jan 1st 2023 would include a “MUST NOT support IPv4”..
>
> What I am trying to understand is whether deploying IPv6 is a pure
> financial problem. If it is, in this scenario, it would very very soon
> become much more pricey to not deploy it.
>
> I know there are a lot of gaps in this, for example who imposes this, what
> is the "Global Internet Routing Table", etc. but let’s try to see around
> them, to the core idea behind them.
>
> Thanks,
> Antonis
>
> ---
> Links
> ---
> 1: https://nanog.org/resources/usage-guidelines/
>