Re: Squat space is now being advertised by AS 749 (DoD Network Information Center)

[Paul Ferguson]

Both articles are base don Doug Madory's research:

https://www.kentik.com/blog/wait-did-as8003-just-disappear/

Cheers,

- ferg


On 9/10/21 5:26 PM, Daniel Lacey wrote:


Just saw an article in the Washington Post explaining what went on…

It was a follow up to the Apr 24 and 26 articles…

I don’t have a link without a subscription….

Basically, unused IPv4 addresses from DOD were being transferred to 
Global Resource  Systems. It was transferred back today.This is some 
pilot program for network resilience by the Pentagon unit Defense 
Digital Service.


I don’t know if this is a smoke screen or exactly what “they” say it is…
Just trying to fill in the blanks…

On Sep 10, 2021, at 15:40, Compton, Rich A  
wrote:




Hi, this week it looks like the DoD owned squat space that was 
previously advertised by AS 8008 (a shadow company called Global 
Resource Systems, 
seehttps://apnews.com/article/technology-business-government-and-politics-b26ab809d1e9fdb53314f56299399949 
) 
is now being advertised by AS 749 (DoD Network Information Center).  
Does anyone have any idea why this change was made?  Is the DoD 
planning on actually legitimately putting services on the space soon 
instead of using it as a giant honeypot?  Or maybe even selling it?


Thanks,

Rich




--
Paul Ferguson
Tacoma, WA  USA
Illegitimi non carborundum.

Re: Squat space is now being advertised by AS 749 (DoD Network Information Center)

[Daniel Lacey]

Just saw an article in the Washington Post explaining what went on…

It was a follow up to the Apr 24 and 26 articles…

I don’t have a link without a subscription….

Basically, unused IPv4 addresses from DOD were being transferred to Global 
Resource  Systems. It was transferred back today.This is some pilot program for 
network resilience by the Pentagon unit Defense Digital Service.

I don’t know if this is a smoke screen or exactly what “they” say it is…
Just trying to fill in the blanks…

> On Sep 10, 2021, at 15:40, Compton, Rich A  wrote:
> 
> 
> Hi, this week it looks like the DoD owned squat space that was previously 
> advertised by AS 8008 (a shadow company called Global Resource Systems, see 
> https://apnews.com/article/technology-business-government-and-politics-b26ab809d1e9fdb53314f56299399949)
>  is now being advertised by AS 749 (DoD Network Information Center).  Does 
> anyone have any idea why this change was made?  Is the DoD planning on 
> actually legitimately putting services on the space soon instead of using it 
> as a giant honeypot?  Or maybe even selling it?
>  
> Thanks, 
> Rich
>  
> The contents of this e-mail message and 
> any attachments are intended solely for the 
> addressee(s) and may contain confidential 
> and/or legally privileged information. If you
> are not the intended recipient of this message
> or if this message has been addressed to you 
> in error, please immediately alert the sender
> by reply e-mail and then delete this message 
> and any attachments. If you are not the 
> intended recipient, you are notified that 
> any use, dissemination, distribution, copying,
> or storage of this message or any attachment 
> is strictly prohibited.

Re: Xfi Advances Security (comcast)

[Eric Kuhnke]

Ideally being your own customer owned cable modem that meets specs (Comcast
does allow this in some regions) that will function as a layer 2 bridge.

On Fri, Sep 10, 2021, 1:46 PM Owen DeLong  wrote:

> First thing I do with any cable modem is convert it to bridge mode.
>
> The fewer “smarts” in the cable modem doing odd things to my traffic, the
> better.
>
> Owen
>
>
> On Sep 10, 2021, at 10:40 , Eric Kuhnke  wrote:
>
> I know this is not a solution to your problem, but I have found myself
> more often running the public interface of openvpn systems on port 443. Any
> sufficiently advanced DPI setup will be able to tell that it's not quite
> normal https traffic.
>
> But 99% of the time it seems to serve the purpose of defeating
> heavily-restricted "free" wifi in airports, hotels, random guest/amenity
> wifi stuff, which obviously can't block https/443 to the world these days.
>
> On Fri, Sep 10, 2021 at 11:08 AM Jason Kuehl 
> wrote:
>
>> This is an SSL VPN that is being blocked. This is what failure looks
>> like. Curl is the same.
>>
>> Once we disable the Xfi  Advanced Security everyone can connect.
>>
>> [image: image.png]
>>
>> On Fri, Sep 10, 2021 at 11:01 AM Jim Popovitch via NANOG 
>> wrote:
>>
>>> On Fri, 2021-09-10 at 10:31 -0400, Jason Kuehl wrote:
>>> > For whatever reason Comcast Xfinity is blocking my VPN URL.
>>>
>>> Not certain that this applies, but Concast Advanced Security (setup in
>>> your Comcast gateway) only allows outbound VPN connections to UDP ports
>>> 500, 4500, and 62515 and TCP port 1723.
>>>
>>> -Jim P.
>>>
>>>
>>
>> --
>> Sincerely,
>>
>> Jason W Kuehl
>> Cell 920-419-8983
>> jason.w.ku...@gmail.com
>>
>
>

Squat space is now being advertised by AS 749 (DoD Network Information Center)

[Compton, Rich A]

Hi, this week it looks like the DoD owned squat space that was previously 
advertised by AS 8008 (a shadow company called Global Resource Systems, see 
https://apnews.com/article/technology-business-government-and-politics-b26ab809d1e9fdb53314f56299399949)
 is now being advertised by AS 749 (DoD Network Information Center).  Does 
anyone have any idea why this change was made?  Is the DoD planning on actually 
legitimately putting services on the space soon instead of using it as a giant 
honeypot?  Or maybe even selling it?

Thanks,
Rich

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

Re: IPv6 woes - RFC

[Jeroen Massar via NANOG]

On 2021-09-10 18:27, Owen DeLong wrote:




On Sep 10, 2021, at 01:39 , Jeroen Massar  wrote:




On 20210909, at 21:55, Owen DeLong via NANOG  wrote:

[..]
Awful lot of red spots even in the top 100.  Hell, even amazon.com
isn't IPv6 yet.  And the long tail is going to be the death of a thousand
cuts for the call center unless you have a way to deal with those sites.


This is my point… That is why I think an announcement of “On X date,
we will begin charging extra for IPv4 services and define Internet Access
to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
big fire under those laggards.


You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ?

yes, a /24 was 0 setup, now now close to 5000 of currency and the monthly 
fee also doubled.
Noting that 20 for an IPv4 IP is effectively quite cheap with current prices 
going towards 50+...

There are thus already a few places that are doing the squish

Greets,
Jeroen



Yes, but it needs to come from a major eyeball ISP to be the motivating
factor that we need here. A minor virtual server host isn’t going to do it.


"minor virtual server host". I think you are underestimating things...

https://bgp.he.net/AS24940 + AS213230

That is not a toy network... but hey, I guess 'everything is bigger' on 
the other side of the big old lake eh.


I am sure, considering the news and rumors, that that pricing change 
made, that it made an impact at a lot of companies, that things are 
changing, and that is a win for IPv6...


But hey, YMMV.

Greets,
 Jeroen

Re: Never push the Big Red Button (New York City subway failure)

[Warren Kumari]

On Fri, Sep 10, 2021 at 4:21 PM Baldur Norddahl 
wrote:

> A nearby datacenter once lost power delayed because someone hit the switch
> to transfer from city power to generator power and then failed to notice.
> The power went out the day after when there was no fuel left.
>

:-)

A story, told to me by a friend...

The utility let them know that they were going to be doing some
maintenance work in the area. No impact expected, but out of an abundance
of caution, they transfer over to generators. After the utility lets them
know that the maintenance work is all finished, they want to switch back.
If the generators are "emergency power", and you need to switch back to
"utility power", obviously the way to do this must be the big red button,
clearly marked as "EMERGENCY POWER OFF", no?!

I suspect it is apocryphal, but it's still entertaining,
W



>
> On Fri, Sep 10, 2021 at 9:24 PM Matthew Huff  wrote:
>
>> Since we are telling power horror stories…
>>
>>
>>
>>
>>
>> How about the call from the night operator that arrived at 10:00pm asking
>> “Is there any reason there is no power in the data center?”
>>
>>
>>
>> Turns out someone had plugged in a new high end workgroup laser printer
>> to the outside wall of the datacenter. The power receptacle was wired into
>> the data center’s UPS and completely smoked the UPS. Luckily the static
>> transfer switched worked, but the three mainframes weren’t’ happy…
>>
>>
>>
>>
>>
>> Or
>>
>>
>>
>> Our building had a major ground fault issue that took years to find and
>> resolve. We got hit with lightning that caused the mainframe to fault and
>> recycle…and two minutes in, we got hit by lightning again. When the system
>> failed to start, we called IBM support. When we explained what happened
>> there was a very long pause…then some mumbling off phone, then the manager
>> got on the line and said someone would be flying out and be onsite within
>> 12 hours. We were down for 3 days, and got fined $250,000 by the insurance
>> regulators since we couldn’t pay claims.
>>
>>
>>
>> *Matthew Huff* | Director of Technical Operations | OTA Management LLC
>>
>>
>>
>> *Office: 914-460-4039*
>>
>> *mh...@ox.com  | **www.ox.com *
>>
>>
>> *...*
>>
>>
>>
>> *From:* Chris Kane 
>> *Sent:* Friday, September 10, 2021 3:16 PM
>> *To:* Christopher Morrow 
>> *Cc:* Matthew Huff ; nanog@nanog.org
>> *Subject:* Re: Never push the Big Red Button (New York City subway
>> failure)
>>
>>
>>
>> True EPO story; maintenance crew carrying new drywall into the data
>> center backed into the EPO that didn't have a cover on it. One of the most
>> eerie sounds in networking...a completely silent data center.
>>
>>
>>
>> -chris
>>
>>
>>
>> On Fri, Sep 10, 2021 at 2:48 PM Christopher Morrow <
>> morrowc.li...@gmail.com> wrote:
>>
>>
>>
>>
>>
>> On Fri, Sep 10, 2021 at 1:49 PM Matthew Huff  wrote:
>>
>> Reminds me of something that happened about 25 years ago when an
>> elementary school visited our data center of the insurance company where I
>> worked. One of our operators strategically positioned himself between the
>> kids and the mainframe, leaned back and hit it's EPO button.
>>
>>
>>
>> Or when your building engineering team cuts themselves a new key for the
>> 'main breaker' for the facility... and tests it at 2pm on a tuesday.
>>
>> Or when that same team cuts a second key (gotta have 2 keys!) and tests
>> that key on the same 'main breaker' ... at 2pm on the following tuesday.
>>
>>
>>
>> 
>>
>>
>>
>> not fakenews, a real story from a large building full of gov't employees
>> and computers and all manner of 'critical infrastructure' for the agency
>> occupying said building.
>>
>>
>>
>> Matthew Huff | Director of Technical Operations | OTA Management LLC
>>
>> Office: 914-460-4039
>> mh...@ox.com | www.ox.com
>>
>> ...
>>
>> -Original Message-
>> From: NANOG  On Behalf Of Sean
>> Donelan
>> Sent: Friday, September 10, 2021 12:38 PM
>> To: nanog@nanog.org
>> Subject: Never push the Big Red Button (New York City subway failure)
>>
>> NEW YORK CITY TRANSIT RAIL CONTROL CENTER POWER
>> OUTAGE ISSUE ON AUGUST 29, 2021
>> Key Findings
>> September 8, 2021
>>
>>
>>
>> https://www.governor.ny.gov/sites/default/files/2021-09/WSP_Key_Findings_Summary-for_release.pdf
>>
>> Key Findings
>> [...]
>>
>> 3. Based on the electrical equipment log readings and the manufacturer’s
>> official assessment, it was determined that the most likely cause of RCC
>> shutdown was the “Emergency Power Off” button being manually activated.
>>
>> Secondary Findings
>>
>> 1. The “Emergency Power Off” button did not have a protective cover at
>> the
>> time of the shutdown or the following WSP investigation.
>>
>> [...]
>> Mitigation 

Re: IPv6 woes - RFC

[John Levine]

It appears that Owen DeLong via NANOG  said:
>This is my point… That is why I think an announcement of “On X date,
>we will begin charging extra for IPv4 services and define Internet Access
>to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
>big fire under those laggards.

Indeed.  They would send postcards to all their customers saying
"Comcast has said they will cut off your access to Netflix on April 1,
Call their president's office at 1-800-xxx- and tell them what you think."

Great move.

R's,
John

Re: Never push the Big Red Button (New York City subway failure)

[Baldur Norddahl]

A nearby datacenter once lost power delayed because someone hit the switch
to transfer from city power to generator power and then failed to notice.
The power went out the day after when there was no fuel left.

On Fri, Sep 10, 2021 at 9:24 PM Matthew Huff  wrote:

> Since we are telling power horror stories…
>
>
>
>
>
> How about the call from the night operator that arrived at 10:00pm asking
> “Is there any reason there is no power in the data center?”
>
>
>
> Turns out someone had plugged in a new high end workgroup laser printer to
> the outside wall of the datacenter. The power receptacle was wired into the
> data center’s UPS and completely smoked the UPS. Luckily the static
> transfer switched worked, but the three mainframes weren’t’ happy…
>
>
>
>
>
> Or
>
>
>
> Our building had a major ground fault issue that took years to find and
> resolve. We got hit with lightning that caused the mainframe to fault and
> recycle…and two minutes in, we got hit by lightning again. When the system
> failed to start, we called IBM support. When we explained what happened
> there was a very long pause…then some mumbling off phone, then the manager
> got on the line and said someone would be flying out and be onsite within
> 12 hours. We were down for 3 days, and got fined $250,000 by the insurance
> regulators since we couldn’t pay claims.
>
>
>
> *Matthew Huff* | Director of Technical Operations | OTA Management LLC
>
>
>
> *Office: 914-460-4039*
>
> *mh...@ox.com  | **www.ox.com *
>
>
> *...*
>
>
>
> *From:* Chris Kane 
> *Sent:* Friday, September 10, 2021 3:16 PM
> *To:* Christopher Morrow 
> *Cc:* Matthew Huff ; nanog@nanog.org
> *Subject:* Re: Never push the Big Red Button (New York City subway
> failure)
>
>
>
> True EPO story; maintenance crew carrying new drywall into the data center
> backed into the EPO that didn't have a cover on it. One of the most
> eerie sounds in networking...a completely silent data center.
>
>
>
> -chris
>
>
>
> On Fri, Sep 10, 2021 at 2:48 PM Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
>
>
>
>
>
> On Fri, Sep 10, 2021 at 1:49 PM Matthew Huff  wrote:
>
> Reminds me of something that happened about 25 years ago when an
> elementary school visited our data center of the insurance company where I
> worked. One of our operators strategically positioned himself between the
> kids and the mainframe, leaned back and hit it's EPO button.
>
>
>
> Or when your building engineering team cuts themselves a new key for the
> 'main breaker' for the facility... and tests it at 2pm on a tuesday.
>
> Or when that same team cuts a second key (gotta have 2 keys!) and tests
> that key on the same 'main breaker' ... at 2pm on the following tuesday.
>
>
>
> 
>
>
>
> not fakenews, a real story from a large building full of gov't employees
> and computers and all manner of 'critical infrastructure' for the agency
> occupying said building.
>
>
>
> Matthew Huff | Director of Technical Operations | OTA Management LLC
>
> Office: 914-460-4039
> mh...@ox.com | www.ox.com
>
> ...
>
> -Original Message-
> From: NANOG  On Behalf Of Sean
> Donelan
> Sent: Friday, September 10, 2021 12:38 PM
> To: nanog@nanog.org
> Subject: Never push the Big Red Button (New York City subway failure)
>
> NEW YORK CITY TRANSIT RAIL CONTROL CENTER POWER
> OUTAGE ISSUE ON AUGUST 29, 2021
> Key Findings
> September 8, 2021
>
>
>
> https://www.governor.ny.gov/sites/default/files/2021-09/WSP_Key_Findings_Summary-for_release.pdf
>
> Key Findings
> [...]
>
> 3. Based on the electrical equipment log readings and the manufacturer’s
> official assessment, it was determined that the most likely cause of RCC
> shutdown was the “Emergency Power Off” button being manually activated.
>
> Secondary Findings
>
> 1. The “Emergency Power Off” button did not have a protective cover at the
> time of the shutdown or the following WSP investigation.
>
> [...]
> Mitigation Steps
>
> 1. Set up the electrical equipment Control and Communication systems
> properly to stay active so that personnel can monitor RCC electrical
> system operations.
>
> [...]
>
>
>
>
> --
>
> Chris Kane
>

Re: Never push the Big Red Button (New York City subway failure)

[Warren Kumari]

On Fri, Sep 10, 2021 at 2:52 PM Christopher Morrow 
wrote:

>
>
> On Fri, Sep 10, 2021 at 1:49 PM Matthew Huff  wrote:
>
>> Reminds me of something that happened about 25 years ago when an
>> elementary school visited our data center of the insurance company where I
>> worked. One of our operators strategically positioned himself between the
>> kids and the mainframe, leaned back and hit it's EPO button.
>>
>>
> Or when your building engineering team cuts themselves a new key for the
> 'main breaker' for the facility... and tests it at 2pm on a tuesday.
> Or when that same team cuts a second key (gotta have 2 keys!) and tests
> that key on the same 'main breaker' ... at 2pm on the following tuesday.
>
> 
>
> not fakenews, a real story from a large building full of gov't employees
> and computers and all manner of 'critical infrastructure' for the agency
> occupying said building.
>


In the early 2000s a friend of mine worked for a company in NYC
that provided stock feeds to large banks and brokerages and similar. They'd
ship a (locked) cabinet full of stuff to their customers, complete with an
Ethernet cable stickin' out the back. Customer would plug this into their
network and, um, do whatever it is stock people do. There was some
horrendously expensive SLA attached, and so they outsourced support to one
of the managed services companies so that they could provide 24x7x2hour
response all over the country.


One day, one of their largest customers, a large bank, also in NYC is down.
This means that the brokerage arm is unable to do any trades, and so is,
um, annoyed. Support rushes over to the customer and "fix it". My friend
doesn't really get a good explanation of how it got fixed, but, meh, it's
working, so all good. A few weeks later, same thing - customer devices
disappear from monitoring, smart-hands/support rush over and fix it, no
useful RFO. This happens a few more times, and everyone is getting
increasingly annoyed.

Eventually my friend arranges it so that he gets paged at the same time as
the support provider. Pager goes off, friend jumps in a cab to the
customer. He arrives at the same time as the smart-hands person, who,
oddly, is clutching 1: an Ethernet face-plate and 2: a punch-down tool.
Somewhat mystified, my friend follows the support person to where the
cabinet is located. Because it's important and special, but not actually
bank owned, it cannot live in their data-center... and so it is located in
the corridor, just outside the server room.

Because of where the Ethernet cable comes out the back of the cabinet, and
where the wall jack is, there is basically no slack. When someone goes in
or out, especially if they are wheeling a cart or carrying a box of
equipment, they bang into the cabinet, which slowly rolls away -- ripping
the wall jack off the wall, and the cable out the back of the jack.
Support's "solution" to this has been to punch down the cable onto a new
wall jack, screw it back onto the wall, wheel the cabinet back into place,
and call it fixed.

My friend screwed down the cabinet feet, so it wasn't resting on the wheels
any more, replaced the 6ft Ethernet with a 15ft, and the issue never
recurred :-P

W




>
> Matthew Huff | Director of Technical Operations | OTA Management LLC
>>
>> Office: 914-460-4039
>> mh...@ox.com | www.ox.com
>>
>> ...
>>
>> -Original Message-
>> From: NANOG  On Behalf Of Sean
>> Donelan
>> Sent: Friday, September 10, 2021 12:38 PM
>> To: nanog@nanog.org
>> Subject: Never push the Big Red Button (New York City subway failure)
>>
>> NEW YORK CITY TRANSIT RAIL CONTROL CENTER POWER
>> OUTAGE ISSUE ON AUGUST 29, 2021
>> Key Findings
>> September 8, 2021
>>
>>
>>
>> https://www.governor.ny.gov/sites/default/files/2021-09/WSP_Key_Findings_Summary-for_release.pdf
>>
>> Key Findings
>> [...]
>>
>> 3. Based on the electrical equipment log readings and the manufacturer’s
>> official assessment, it was determined that the most likely cause of RCC
>> shutdown was the “Emergency Power Off” button being manually activated.
>>
>> Secondary Findings
>>
>> 1. The “Emergency Power Off” button did not have a protective cover at
>> the
>> time of the shutdown or the following WSP investigation.
>>
>> [...]
>> Mitigation Steps
>>
>> 1. Set up the electrical equipment Control and Communication systems
>> properly to stay active so that personnel can monitor RCC electrical
>> system operations.
>>
>> [...]
>>
>

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

Re: Voice Middleware

[james jones]

Owen,

Do you mean this
https://www.voip-info.org/asterisk-how-to-connect-to-metaswitch/?
I am not sure that is what he is looking for, but it could be. It has been
a while for me as well :)

Mike,

Could you give a little more context in what you are trying to do? Are you
looking for something that can manage all those devices via their web APIs?

-James

On Fri, Sep 10, 2021 at 12:39 PM Owen DeLong via NANOG 
wrote:

> I don’t know the current state, but I believe Asterisk was going down that
> road for a while.
>
> Owen
>
>
> On Sep 10, 2021, at 05:26 , Mike Hammett  wrote:
>
> Before we build something from scratch, are there platforms that do the
> heavy lifting of talking to the Metaswitch API, Peerless's API, various LSR
> APIs, etc.?
>
> I mean this for provisioning purposes.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
>

Re: Never push the Big Red Button (New York City subway failure)

[Mikael Abrahamsson via NANOG]

On Fri, 10 Sep 2021, Sean Donelan wrote:

1. The “Emergency Power Off” button did not have a protective cover at the 
time of the shutdown or the following WSP investigation.


Aka "molly-guard".

https://en.wiktionary.org/wiki/molly-guard

--
Mikael Abrahamssonemail: swm...@swm.pp.se

RE: Never push the Big Red Button (New York City subway failure)

[Matthew Huff]

Since we are telling power horror stories…


How about the call from the night operator that arrived at 10:00pm asking “Is 
there any reason there is no power in the data center?”

Turns out someone had plugged in a new high end workgroup laser printer to the 
outside wall of the datacenter. The power receptacle was wired into the data 
center’s UPS and completely smoked the UPS. Luckily the static transfer 
switched worked, but the three mainframes weren’t’ happy…


Or

Our building had a major ground fault issue that took years to find and 
resolve. We got hit with lightning that caused the mainframe to fault and 
recycle…and two minutes in, we got hit by lightning again. When the system 
failed to start, we called IBM support. When we explained what happened there 
was a very long pause…then some mumbling off phone, then the manager got on the 
line and said someone would be flying out and be onsite within 12 hours. We 
were down for 3 days, and got fined $250,000 by the insurance regulators since 
we couldn’t pay claims.

Matthew Huff | Director of Technical Operations | OTA Management LLC

Office: 914-460-4039
mh...@ox.com | www.ox.com
...

From: Chris Kane 
Sent: Friday, September 10, 2021 3:16 PM
To: Christopher Morrow 
Cc: Matthew Huff ; nanog@nanog.org
Subject: Re: Never push the Big Red Button (New York City subway failure)

True EPO story; maintenance crew carrying new drywall into the data center 
backed into the EPO that didn't have a cover on it. One of the most eerie 
sounds in networking...a completely silent data center.

-chris

On Fri, Sep 10, 2021 at 2:48 PM Christopher Morrow 
mailto:morrowc.li...@gmail.com>> wrote:


On Fri, Sep 10, 2021 at 1:49 PM Matthew Huff 
mailto:mh...@ox.com>> wrote:
Reminds me of something that happened about 25 years ago when an elementary 
school visited our data center of the insurance company where I worked. One of 
our operators strategically positioned himself between the kids and the 
mainframe, leaned back and hit it's EPO button.

Or when your building engineering team cuts themselves a new key for the 'main 
breaker' for the facility... and tests it at 2pm on a tuesday.
Or when that same team cuts a second key (gotta have 2 keys!) and tests that 
key on the same 'main breaker' ... at 2pm on the following tuesday.



not fakenews, a real story from a large building full of gov't employees and 
computers and all manner of 'critical infrastructure' for the agency occupying 
said building.

Matthew Huff | Director of Technical Operations | OTA Management LLC

Office: 914-460-4039
mh...@ox.com | www.ox.com
...

-Original Message-
From: NANOG mailto:ox@nanog.org>> On 
Behalf Of Sean Donelan
Sent: Friday, September 10, 2021 12:38 PM
To: nanog@nanog.org
Subject: Never push the Big Red Button (New York City subway failure)

NEW YORK CITY TRANSIT RAIL CONTROL CENTER POWER
OUTAGE ISSUE ON AUGUST 29, 2021
Key Findings
September 8, 2021


https://www.governor.ny.gov/sites/default/files/2021-09/WSP_Key_Findings_Summary-for_release.pdf

Key Findings
[...]

3. Based on the electrical equipment log readings and the manufacturer’s
official assessment, it was determined that the most likely cause of RCC
shutdown was the “Emergency Power Off” button being manually activated.

Secondary Findings

1. The “Emergency Power Off” button did not have a protective cover at the
time of the shutdown or the following WSP investigation.

[...]
Mitigation Steps

1. Set up the electrical equipment Control and Communication systems
properly to stay active so that personnel can monitor RCC electrical
system operations.

[...]


--
Chris Kane

Re: Never push the Big Red Button (New York City subway failure)

[Chris Kane]

True EPO story; maintenance crew carrying new drywall into the data center
backed into the EPO that didn't have a cover on it. One of the most
eerie sounds in networking...a completely silent data center.

-chris

On Fri, Sep 10, 2021 at 2:48 PM Christopher Morrow 
wrote:

>
>
> On Fri, Sep 10, 2021 at 1:49 PM Matthew Huff  wrote:
>
>> Reminds me of something that happened about 25 years ago when an
>> elementary school visited our data center of the insurance company where I
>> worked. One of our operators strategically positioned himself between the
>> kids and the mainframe, leaned back and hit it's EPO button.
>>
>>
> Or when your building engineering team cuts themselves a new key for the
> 'main breaker' for the facility... and tests it at 2pm on a tuesday.
> Or when that same team cuts a second key (gotta have 2 keys!) and tests
> that key on the same 'main breaker' ... at 2pm on the following tuesday.
>
> 
>
> not fakenews, a real story from a large building full of gov't employees
> and computers and all manner of 'critical infrastructure' for the agency
> occupying said building.
>
> Matthew Huff | Director of Technical Operations | OTA Management LLC
>>
>> Office: 914-460-4039
>> mh...@ox.com | www.ox.com
>>
>> ...
>>
>> -Original Message-
>> From: NANOG  On Behalf Of Sean
>> Donelan
>> Sent: Friday, September 10, 2021 12:38 PM
>> To: nanog@nanog.org
>> Subject: Never push the Big Red Button (New York City subway failure)
>>
>> NEW YORK CITY TRANSIT RAIL CONTROL CENTER POWER
>> OUTAGE ISSUE ON AUGUST 29, 2021
>> Key Findings
>> September 8, 2021
>>
>>
>>
>> https://www.governor.ny.gov/sites/default/files/2021-09/WSP_Key_Findings_Summary-for_release.pdf
>>
>> Key Findings
>> [...]
>>
>> 3. Based on the electrical equipment log readings and the manufacturer’s
>> official assessment, it was determined that the most likely cause of RCC
>> shutdown was the “Emergency Power Off” button being manually activated.
>>
>> Secondary Findings
>>
>> 1. The “Emergency Power Off” button did not have a protective cover at
>> the
>> time of the shutdown or the following WSP investigation.
>>
>> [...]
>> Mitigation Steps
>>
>> 1. Set up the electrical equipment Control and Communication systems
>> properly to stay active so that personnel can monitor RCC electrical
>> system operations.
>>
>> [...]
>>
>

-- 
Chris Kane

Re: Never push the Big Red Button (New York City subway failure)

[Christopher Morrow]

On Fri, Sep 10, 2021 at 1:49 PM Matthew Huff  wrote:

> Reminds me of something that happened about 25 years ago when an
> elementary school visited our data center of the insurance company where I
> worked. One of our operators strategically positioned himself between the
> kids and the mainframe, leaned back and hit it's EPO button.
>
>
Or when your building engineering team cuts themselves a new key for the
'main breaker' for the facility... and tests it at 2pm on a tuesday.
Or when that same team cuts a second key (gotta have 2 keys!) and tests
that key on the same 'main breaker' ... at 2pm on the following tuesday.



not fakenews, a real story from a large building full of gov't employees
and computers and all manner of 'critical infrastructure' for the agency
occupying said building.

Matthew Huff | Director of Technical Operations | OTA Management LLC
>
> Office: 914-460-4039
> mh...@ox.com | www.ox.com
>
> ...
>
> -Original Message-
> From: NANOG  On Behalf Of Sean
> Donelan
> Sent: Friday, September 10, 2021 12:38 PM
> To: nanog@nanog.org
> Subject: Never push the Big Red Button (New York City subway failure)
>
> NEW YORK CITY TRANSIT RAIL CONTROL CENTER POWER
> OUTAGE ISSUE ON AUGUST 29, 2021
> Key Findings
> September 8, 2021
>
>
>
> https://www.governor.ny.gov/sites/default/files/2021-09/WSP_Key_Findings_Summary-for_release.pdf
>
> Key Findings
> [...]
>
> 3. Based on the electrical equipment log readings and the manufacturer’s
> official assessment, it was determined that the most likely cause of RCC
> shutdown was the “Emergency Power Off” button being manually activated.
>
> Secondary Findings
>
> 1. The “Emergency Power Off” button did not have a protective cover at the
> time of the shutdown or the following WSP investigation.
>
> [...]
> Mitigation Steps
>
> 1. Set up the electrical equipment Control and Communication systems
> properly to stay active so that personnel can monitor RCC electrical
> system operations.
>
> [...]
>

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 11 Sep, 2021

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  861637
Prefixes after maximum aggregation (per Origin AS):  326121
Deaggregation factor:  2.64
Unique aggregates announced (without unneeded subnets):  414174
Total ASes present in the Internet Routing Table: 71910
Prefixes per ASN: 11.98
Origin-only ASes present in the Internet Routing Table:   61801
Origin ASes announcing only one prefix:   25551
Transit ASes present in the Internet Routing Table:   10109
Transit-only ASes present in the Internet Routing Table:329
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  37
Max AS path prepend of ASN (141827)  33
Prefixes from unregistered ASNs in the Routing Table:   967
Number of instances of unregistered ASNs:   974
Number of 32-bit ASNs allocated by the RIRs:  37182
Number of 32-bit ASNs visible in the Routing Table:   30868
Prefixes from 32-bit ASNs in the Routing Table:  143537
Number of bogon 32-bit ASNs visible in the Routing Table:37
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:470
Number of addresses announced to Internet:   3039121536
Equivalent to 181 /8s, 37 /16s and 80 /24s
Percentage of available address space announced:   82.1
Percentage of allocated address space announced:   82.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  286233

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   231597
Total APNIC prefixes after maximum aggregation:   66091
APNIC Deaggregation factor:3.50
Prefixes being announced from the APNIC address blocks:  227042
Unique aggregates announced from the APNIC address blocks:90918
APNIC Region origin ASes present in the Internet Routing Table:   11927
APNIC Prefixes per ASN:   19.04
APNIC Region origin ASes announcing only one prefix:   3390
APNIC Region transit ASes present in the Internet Routing Table:   1668
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 37
Number of APNIC region 32-bit ASNs visible in the Routing Table:   7082
Number of APNIC addresses announced to Internet:  773837568
Equivalent to 46 /8s, 31 /16s and 211 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-147769
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:251817
Total ARIN prefixes after maximum aggregation:   115198
ARIN Deaggregation factor: 2.19
Prefixes being announced from the ARIN address blocks:   251659
Unique aggregates announced from the ARIN address blocks:119787
ARIN Region origin ASes present in the Internet Routing Table:18899
ARIN Prefixes per ASN:13.32
ARIN 

RE: Never push the Big Red Button (New York City subway failure)

[Matthew Huff]

Reminds me of something that happened about 25 years ago when an elementary 
school visited our data center of the insurance company where I worked. One of 
our operators strategically positioned himself between the kids and the 
mainframe, leaned back and hit it's EPO button.

Matthew Huff | Director of Technical Operations | OTA Management LLC

Office: 914-460-4039
mh...@ox.com | www.ox.com
...

-Original Message-
From: NANOG  On Behalf Of Sean Donelan
Sent: Friday, September 10, 2021 12:38 PM
To: nanog@nanog.org
Subject: Never push the Big Red Button (New York City subway failure)

NEW YORK CITY TRANSIT RAIL CONTROL CENTER POWER
OUTAGE ISSUE ON AUGUST 29, 2021
Key Findings
September 8, 2021


https://www.governor.ny.gov/sites/default/files/2021-09/WSP_Key_Findings_Summary-for_release.pdf

Key Findings
[...]

3. Based on the electrical equipment log readings and the manufacturer’s 
official assessment, it was determined that the most likely cause of RCC 
shutdown was the “Emergency Power Off” button being manually activated.

Secondary Findings

1. The “Emergency Power Off” button did not have a protective cover at the 
time of the shutdown or the following WSP investigation.

[...]
Mitigation Steps

1. Set up the electrical equipment Control and Communication systems 
properly to stay active so that personnel can monitor RCC electrical 
system operations.

[...]

Re: Xfi Advances Security (comcast)

[Owen DeLong via NANOG]

First thing I do with any cable modem is convert it to bridge mode.

The fewer “smarts” in the cable modem doing odd things to my traffic, the 
better.

Owen


> On Sep 10, 2021, at 10:40 , Eric Kuhnke  wrote:
> 
> I know this is not a solution to your problem, but I have found myself more 
> often running the public interface of openvpn systems on port 443. Any 
> sufficiently advanced DPI setup will be able to tell that it's not quite 
> normal https traffic. 
> 
> But 99% of the time it seems to serve the purpose of defeating 
> heavily-restricted "free" wifi in airports, hotels, random guest/amenity wifi 
> stuff, which obviously can't block https/443 to the world these days.
> 
> On Fri, Sep 10, 2021 at 11:08 AM Jason Kuehl  > wrote:
> This is an SSL VPN that is being blocked. This is what failure looks like. 
> Curl is the same.
> 
> Once we disable the Xfi  Advanced Security everyone can connect.
> 
> 
> 
> On Fri, Sep 10, 2021 at 11:01 AM Jim Popovitch via NANOG  > wrote:
> On Fri, 2021-09-10 at 10:31 -0400, Jason Kuehl wrote:
> > For whatever reason Comcast Xfinity is blocking my VPN URL. 
> 
> Not certain that this applies, but Concast Advanced Security (setup in
> your Comcast gateway) only allows outbound VPN connections to UDP ports
> 500, 4500, and 62515 and TCP port 1723.
> 
> -Jim P.
> 
> 
> 
> -- 
> Sincerely,
>  
> Jason W Kuehl
> Cell 920-419-8983
> jason.w.ku...@gmail.com 

Re: Xfi Advances Security (comcast)

[Eric Kuhnke]

I know this is not a solution to your problem, but I have found myself more
often running the public interface of openvpn systems on port 443. Any
sufficiently advanced DPI setup will be able to tell that it's not quite
normal https traffic.

But 99% of the time it seems to serve the purpose of defeating
heavily-restricted "free" wifi in airports, hotels, random guest/amenity
wifi stuff, which obviously can't block https/443 to the world these days.

On Fri, Sep 10, 2021 at 11:08 AM Jason Kuehl 
wrote:

> This is an SSL VPN that is being blocked. This is what failure looks like.
> Curl is the same.
>
> Once we disable the Xfi  Advanced Security everyone can connect.
>
> [image: image.png]
>
> On Fri, Sep 10, 2021 at 11:01 AM Jim Popovitch via NANOG 
> wrote:
>
>> On Fri, 2021-09-10 at 10:31 -0400, Jason Kuehl wrote:
>> > For whatever reason Comcast Xfinity is blocking my VPN URL.
>>
>> Not certain that this applies, but Concast Advanced Security (setup in
>> your Comcast gateway) only allows outbound VPN connections to UDP ports
>> 500, 4500, and 62515 and TCP port 1723.
>>
>> -Jim P.
>>
>>
>
> --
> Sincerely,
>
> Jason W Kuehl
> Cell 920-419-8983
> jason.w.ku...@gmail.com
>

Never push the Big Red Button (New York City subway failure)

[Sean Donelan]

NEW YORK CITY TRANSIT RAIL CONTROL CENTER POWER
OUTAGE ISSUE ON AUGUST 29, 2021
Key Findings
September 8, 2021


https://www.governor.ny.gov/sites/default/files/2021-09/WSP_Key_Findings_Summary-for_release.pdf

Key Findings
[...]

3. Based on the electrical equipment log readings and the manufacturer’s 
official assessment, it was determined that the most likely cause of RCC 
shutdown was the “Emergency Power Off” button being manually activated.


Secondary Findings

1. The “Emergency Power Off” button did not have a protective cover at the 
time of the shutdown or the following WSP investigation.


[...]
Mitigation Steps

1. Set up the electrical equipment Control and Communication systems 
properly to stay active so that personnel can monitor RCC electrical 
system operations.


[...]

Re: Voice Middleware

[Owen DeLong via NANOG]

I don’t know the current state, but I believe Asterisk was going down that road 
for a while.

Owen


> On Sep 10, 2021, at 05:26 , Mike Hammett  wrote:
> 
> Before we build something from scratch, are there platforms that do the heavy 
> lifting of talking to the Metaswitch API, Peerless's API, various LSR APIs, 
> etc.?
> 
> I mean this for provisioning purposes.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com 
> 
> Midwest-IX
> http://www.midwest-ix.com 

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 10, 2021, at 01:39 , Jeroen Massar  wrote:
> 
> 
> 
>> On 20210909, at 21:55, Owen DeLong via NANOG  wrote:
>>> [..]
>>> Awful lot of red spots even in the top 100.  Hell, even amazon.com
>>> isn't IPv6 yet.  And the long tail is going to be the death of a thousand
>>> cuts for the call center unless you have a way to deal with those sites.
>> 
>> This is my point… That is why I think an announcement of “On X date,
>> we will begin charging extra for IPv4 services and define Internet Access
>> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
>> big fire under those laggards.
> 
> You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ?
> 
> yes, a /24 was 0 setup, now now close to 5000 of currency and the monthly 
> fee also doubled.
> Noting that 20 for an IPv4 IP is effectively quite cheap with current prices 
> going towards 50+...
> 
> There are thus already a few places that are doing the squish
> 
> Greets,
> Jeroen
> 

Yes, but it needs to come from a major eyeball ISP to be the motivating
factor that we need here. A minor virtual server host isn’t going to do it.

Owen

Re: Xfi Advances Security (comcast)

[Dovid Bender]

Could it be related to the many FortiNet devices being exploited? About 45k
credentials were dumped two days ago. Many are still working.


On Fri, Sep 10, 2021 at 10:56 AM Chris Boyd  wrote:

>
>
> > On Sep 10, 2021, at 9:31 AM, Jason Kuehl 
> wrote:
> >
> > For whatever reason Comcast Xfinity is blocking my VPN URL. I've started
> the process to unblock, and I'm trying to get a hold of their security team
> to resolve this. I've been bounced around all morning.
> >
> > Does anyone have a contact at Comcast that can whitelist a URL or get me
> to a team that can understand what is going on for the block to happen?
>
> Why is Comcast blocking things? That seems like it’s out of scope for an
> ISP.
>
> —Chris

Re: Xfi Advances Security (comcast)

[Jason Kuehl]

This is an SSL VPN that is being blocked. This is what failure looks like.
Curl is the same.

Once we disable the Xfi  Advanced Security everyone can connect.

[image: image.png]

On Fri, Sep 10, 2021 at 11:01 AM Jim Popovitch via NANOG 
wrote:

> On Fri, 2021-09-10 at 10:31 -0400, Jason Kuehl wrote:
> > For whatever reason Comcast Xfinity is blocking my VPN URL.
>
> Not certain that this applies, but Concast Advanced Security (setup in
> your Comcast gateway) only allows outbound VPN connections to UDP ports
> 500, 4500, and 62515 and TCP port 1723.
>
> -Jim P.
>
>

-- 
Sincerely,

Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com

Re: Xfi Advances Security (comcast)

[Jason Kuehl]

By default, the cable modems from Comcast have Xfi Advanced
security-enabled which is a layer 3 URL blocker.

We can access our URL via that IP fine, but the URL fails.

The fix we're telling users is to 1st allow to unblock the URL in the APP,
then disable the service. Which does fix the issue.

I'm trying to find out why Comcast why they did the block to start with and
how to white list.

On Fri, Sep 10, 2021 at 10:57 AM Chris Boyd  wrote:

>
>
> > On Sep 10, 2021, at 9:31 AM, Jason Kuehl 
> wrote:
> >
> > For whatever reason Comcast Xfinity is blocking my VPN URL. I've started
> the process to unblock, and I'm trying to get a hold of their security team
> to resolve this. I've been bounced around all morning.
> >
> > Does anyone have a contact at Comcast that can whitelist a URL or get me
> to a team that can understand what is going on for the block to happen?
>
> Why is Comcast blocking things? That seems like it’s out of scope for an
> ISP.
>
> —Chris



-- 
Sincerely,

Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com

Re: Xfi Advances Security (comcast)

[Jim Popovitch via NANOG]

On Fri, 2021-09-10 at 10:31 -0400, Jason Kuehl wrote:
> For whatever reason Comcast Xfinity is blocking my VPN URL. 

Not certain that this applies, but Concast Advanced Security (setup in
your Comcast gateway) only allows outbound VPN connections to UDP ports
500, 4500, and 62515 and TCP port 1723.

-Jim P.

Re: Xfi Advances Security (comcast)

[Chris Boyd]

> On Sep 10, 2021, at 9:31 AM, Jason Kuehl  wrote:
> 
> For whatever reason Comcast Xfinity is blocking my VPN URL. I've started the 
> process to unblock, and I'm trying to get a hold of their security team to 
> resolve this. I've been bounced around all morning. 
> 
> Does anyone have a contact at Comcast that can whitelist a URL or get me to a 
> team that can understand what is going on for the block to happen?

Why is Comcast blocking things? That seems like it’s out of scope for an ISP.

—Chris

Xfi Advances Security (comcast)

[Jason Kuehl]

For whatever reason Comcast Xfinity is blocking my VPN URL. I've started
the process to unblock, and I'm trying to get a hold of their security team
to resolve this. I've been bounced around all morning.

Does anyone have a contact at Comcast that can whitelist a URL or get me to
a team that can understand what is going on for the block to happen?

-- 
Sincerely,

Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com

Voice Middleware

[Mike Hammett]

Before we build something from scratch, are there platforms that do the heavy 
lifting of talking to the Metaswitch API, Peerless's API, various LSR APIs, 
etc.? 


I mean this for provisioning purposes. 



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

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

Seeking contact with Russian Lawful Intercept (SORM) implementation experience

[Jon Boone]

Hi folks,

  I’m looking for a contact who has experience with implementing Russian 
SORM-[2,3] compliance infrastructures.

  I recognize this may be the NOG forum to ask in. — if there is a more 
appropriate one, please let me know.

— jb

Re: IPv6 woes - RFC

[Jeroen Massar via NANOG]

> On 20210909, at 21:55, Owen DeLong via NANOG  wrote:
>> [..]
>> Awful lot of red spots even in the top 100.  Hell, even amazon.com
>> isn't IPv6 yet.  And the long tail is going to be the death of a thousand
>> cuts for the call center unless you have a way to deal with those sites.
> 
> This is my point… That is why I think an announcement of “On X date,
> we will begin charging extra for IPv4 services and define Internet Access
> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
> big fire under those laggards.

You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ?

yes, a /24 was 0 setup, now now close to 5000 of currency and the monthly 
fee also doubled.
Noting that 20 for an IPv4 IP is effectively quite cheap with current prices 
going towards 50+...

There are thus already a few places that are doing the squish

Greets,
 Jeroen

Re: IPv6 woes - RFC

[Mark Andrews]

> On 10 Sep 2021, at 17:21, Bjørn Mork  wrote:
> 
> Owen DeLong via NANOG  writes:
> 
>> The addresses aren’t the major cost of providing IPv4 services.
>> 
>> CGN boxes, support calls, increasing size of routing table = buying new 
>> routers, etc.
> 
> You're counting dual-stack costs as if IPv4 was the optional protocol.
> That's a fantasy world.  Time to get out of la-la land now.
> 
> Your edge routers can do CGN for all connected users just fine. Yes,
> there is still a cost both in resources and management, but you'll have
> to weigh that against the cost of doing dual-stack on the same box.  I'm
> not convinced dual-stack wins.
> 
> Don't know what you're thinking of wrt support calls, but dual-stack has
> some failure modes which are difficult to understand for both end users
> and support.  NAT is pretty well understood in comparison.
> 
> Your routing tables won't grow with IPv4 or CGN.  They grow when you add
> IPv6.
> 
>> Increased cost of developers having to work around NAT and NAT
>> becoming ever more complex with multiple layers, etc.
> 
> And this can be avoided by reconfiguring the local network somehow?  Or
> are we talking about an Internet without IPv4?  This is even more
> fantastic than the idea that IPv4 is optional in the local network.
> 
>> All of these are the things driving the ever increasing cost of IPv4
>> services, not just the cost of the addresses.
> 
> Yes, the cost of addresses is not prohibitive, and there is no
> indication it will be.
> 
> The consolidation of hosting services have reduced the need for globally
> routable addresses.  You don't host your own mail server and web server
> anymore, even if you're a large organisation.  Most ISPs haven't yet
> taken advantage of this.  They are still giving globally routable IPv4
> addresses to customers which have no need for that.  These addresses can
> be re-allocated for CGN if there is a need. This is obviously still not
> free, but it does limit the price of fresh IPv4 addresses.
> 
> The other costs you list will not affect an IPv4 only shop at all.
> 
> 
> Bjørn

Or you could deliver IPv6-only to your customers and used to CGN boxes
to deliver IPv4AAS using less than 1/2 the IPv4 address space you need
for a NAT444 solution as +60% of your traffic doesn’t need CGN processing.

464XLAT example

{ Internet IPv4(40% of traffic) + IPv6(60% of traffic) } - [Router w/ NAT64] - 
{ IPv6-only (IPv4 traffic has been translated to IPv6) } - [CPE w/ CLAT] { home 
network IPv4 + IPv6 }

DS-Lite

{ Internet IPv4(40% of traffic) + IPv6(60% of traffic) } - [Router w/ AFTR] - { 
IPv6-only (IPv4 traffic has been encapsulated in IPv6) } - [CPE w/ B4] { home 
network IPv4 + IPv6 }

MAP-T and MAP-E are similar to 464XLAT and DS-Lite respectively.

Yes, you have to learn something new but it costs less that a “pure" IPv4
service.

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

Re: IPv6 woes - RFC

[Bjørn Mork]

Owen DeLong via NANOG  writes:

> The addresses aren’t the major cost of providing IPv4 services.
>
> CGN boxes, support calls, increasing size of routing table = buying new 
> routers, etc.

You're counting dual-stack costs as if IPv4 was the optional protocol.
That's a fantasy world.  Time to get out of la-la land now.

Your edge routers can do CGN for all connected users just fine. Yes,
there is still a cost both in resources and management, but you'll have
to weigh that against the cost of doing dual-stack on the same box.  I'm
not convinced dual-stack wins.

Don't know what you're thinking of wrt support calls, but dual-stack has
some failure modes which are difficult to understand for both end users
and support.  NAT is pretty well understood in comparison.

Your routing tables won't grow with IPv4 or CGN.  They grow when you add
IPv6.

> Increased cost of developers having to work around NAT and NAT
> becoming ever more complex with multiple layers, etc.

And this can be avoided by reconfiguring the local network somehow?  Or
are we talking about an Internet without IPv4?  This is even more
fantastic than the idea that IPv4 is optional in the local network.

> All of these are the things driving the ever increasing cost of IPv4
> services, not just the cost of the addresses.

Yes, the cost of addresses is not prohibitive, and there is no
indication it will be.

The consolidation of hosting services have reduced the need for globally
routable addresses.  You don't host your own mail server and web server
anymore, even if you're a large organisation.  Most ISPs haven't yet
taken advantage of this.  They are still giving globally routable IPv4
addresses to customers which have no need for that.  These addresses can
be re-allocated for CGN if there is a need. This is obviously still not
free, but it does limit the price of fresh IPv4 addresses.

The other costs you list will not affect an IPv4 only shop at all.


Bjørn

Re: IPv6 woes - RFC

[Bjørn Mork]

Owen DeLong via NANOG  writes:

> This is my point… That is why I think an announcement of “On X date,
> we will begin charging extra for IPv4 services and define Internet Access
> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
> big fire under those laggards.
>
> Think about it… Amazon doesn’t want to lose access to Comcast, T-Mobile,
> Verizon Wireless, and/or AT eyeballs any more than those ISPs want
> to deal with the call center consequences if they turn off IPv4 before those
> content providers are ready.

By all means, let's just escalate the peering wars between eyeball
networks and content providers.  That will solve all our problems.



Bjørn