date:20240115

Good thing there are no windows at this “hypothetical” location :)

> On Jan 16, 2024, at 1:51 AM, b...@theworld.com wrote:
> 
> 
> Something worth a thought is that as much as devices don't like being
> too hot they also don't like to have their temperature change too
> quickly. Parts can expand/shrink variably depending on their
> composition.
> 
> A rule of thumb is a few degrees per hour change but YMMV, depends on
> the equipment. Sometimes manufacturer's specs include this.
> 
> Throwing open the windows on a winter day to try to rapidly bring the
> room down to a "normal" temperature may do more harm than good.
> 
> It might be worthwhile figuring out what is reasonable in advance with
> buy-in rather than in a panic because, from personal experience,
> someone will be screaming in your ear JUST OPEN ALL THE WINDOWS
> WHADDYA STUPID?
> 
>> On January 15, 2024 at 09:23 clay...@mnsi.net (Clayton Zekelman) wrote:
>> 
>> 
>> 
>> At 09:08 AM 2024-01-15, Mike Hammett wrote:
>>> Let's say that hypothetically, a datacenter you're in had a cooling
>>> failure and escalated to an average of 120 degrees before
>>> mitigations started having an effect. What are normal QA procedures
>>> on your behalf? What is the facility likely to be doing?
>>> What  should be expected in the aftermath?
>> 
>> One would hope they would have had disaster recovery plans to bring
>> in outside cold air, and have executed on it quickly, rather than
>> hoping the chillers got repaired.
>> 
>> All our owned facilities have large outside air intakes, automatic
>> dampers and air mixing chambers in case of mechanical cooling
>> failure, because cooling systems are often not designed to run well
>> in extreme cold.  All of these can be manually run incase of controls
>> failure, but people tell me I'm a little obsessive over backup plans
>> for backup plans.
>> 
>> You will start to see premature failure of equipment over the coming
>> weeks/months/years.
>> 
>> Coincidentally, we have some gear in a data centre in the Chicago
>> area that is experiencing that sort of issue right now... :-(
>> 
>> 
>> 
> 
> --
>-Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

2024-01-15 Thread Forrest Christian (List Account)

On Mon, Jan 15, 2024, 3:08 PM Abraham Y. Chen  wrote:

> 1)Re: Ur. Pt. 1):The initial deployment of EzIP overlay is only
> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
> OpenWrt. So that none of the on-premises IoTs will sense any changes. I
> don't see how an upgrade of such equipment to IPv6 could be simpler and
> less work. Please elaborate.
>

I started to type a big long reply, but I realized that I'm not really sure
how to convince you any further.

Let me try this statement:  Networks made of relatively modern equipment
are likely able to just have IPv6 turned on.   Your solution requires
software engineering and then a whole bunch of software deployed.   And
only then have the 240/4 turned on.

Whether the middle of the network is IPv4 or IPv6 (the portion that 240/4
would replace) is largely irrelevant to the public IPv4 network and to IPv4
devices in residential settings.   With the right configuration, a
residential user can have IPv4 devices talking across a 100% IPv6 network
to the rest of the IPv4 internet.  This software exists and works today.
 And, as a big advantage, once this is done, IPv6-enabled devices can talk
native IPv6 to the IPv6 internet, bypassing all of the CG-NAT mess.

As has been pointed out, IPv6 is not without its challenges.  But so would
be trying to deploy 240/4.

In addition, to support the 'overlay' portion of your solution a lot of
additional work will need to be done.   Explain how I, as a residential
user on RAN #1, can know about and connect to a service on RAN #2.   None
of that work has been done, and in order for your solution to be useful,
you need to do that work.   By contrast, all of that work is already done
with IPv6, and is working today.

Re: "Hypothetical" Datacenter Overheating

On Tue, 16 Jan 2024 at 08:51,  wrote:

> A rule of thumb is a few degrees per hour change but YMMV, depends on
> the equipment. Sometimes manufacturer's specs include this.

Is this common sense, or do you have reference to this, like paper
showing at what temperature change at what rate occurs what damage?

I regularly bring fine electronics, say iPhone, through significant
temperature gradients, as do most people who have to live in places
where inside and outside can be wildly different temperatures, with no
particular observable effect. iPhone does go into 'thermometer' mode,
when it overheats though.

Manufacturers, say Juniper and Cisco describe humidity, storage and
operating temperatures, but do not define temperature change rate.
Does NEBS have an opinion on this, or is this just a common case of
yours?

-- 
  ++ytti

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

On Mon, 15 Jan 2024 at 21:08, Michael Thomas  wrote:

> An ipv4 free network would be nice, but is hardly needed. There will
> always be a long tail of ipv4 and so what? You deal with it at your

I mean Internet free DFZ, so that everyone is not forced to maintain
two stacks at extra cost, fragility and time. Any protocols at the
inside networks are fine, as long as you're meeting the Internet with
IPv6-only stack. I'm sure there are CLNS, IPX, AppleTalk etc networks
there, but that doesn't impose a cost to everyone wanting to play.

-- 
  ++ytti

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread bzs

Something worth a thought is that as much as devices don't like being
too hot they also don't like to have their temperature change too
quickly. Parts can expand/shrink variably depending on their
composition.

A rule of thumb is a few degrees per hour change but YMMV, depends on
the equipment. Sometimes manufacturer's specs include this.

Throwing open the windows on a winter day to try to rapidly bring the
room down to a "normal" temperature may do more harm than good.

It might be worthwhile figuring out what is reasonable in advance with
buy-in rather than in a panic because, from personal experience,
someone will be screaming in your ear JUST OPEN ALL THE WINDOWS
WHADDYA STUPID?

On January 15, 2024 at 09:23 clay...@mnsi.net (Clayton Zekelman) wrote:
 > 
 > 
 > 
 > At 09:08 AM 2024-01-15, Mike Hammett wrote:
 > >Let's say that hypothetically, a datacenter you're in had a cooling 
 > >failure and escalated to an average of 120 degrees before 
 > >mitigations started having an effect. What are normal QA procedures 
 > >on your behalf? What is the facility likely to be doing? 
 > >What  should be expected in the aftermath?
 > 
 > One would hope they would have had disaster recovery plans to bring 
 > in outside cold air, and have executed on it quickly, rather than 
 > hoping the chillers got repaired.
 > 
 > All our owned facilities have large outside air intakes, automatic 
 > dampers and air mixing chambers in case of mechanical cooling 
 > failure, because cooling systems are often not designed to run well 
 > in extreme cold.  All of these can be manually run incase of controls 
 > failure, but people tell me I'm a little obsessive over backup plans 
 > for backup plans.
 > 
 > You will start to see premature failure of equipment over the coming 
 > weeks/months/years.
 > 
 > Coincidentally, we have some gear in a data centre in the Chicago 
 > area that is experiencing that sort of issue right now... :-(
 > 
 > 
 > 

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

2024-01-15 Thread Forrest Christian (List Account)

On Mon, Jan 15, 2024, 1:21 PM Abraham Y. Chen  wrote:

> If I subscribe to IPv6, can I contact another similar subscriber to
> communicate (voice and data) directly between two homes in private like the
> dial-up modem operations in the PSTN? If so, is it available anywhere right
> now?
>

Yes,  if you have IPv6 service and I have IPv6 service, our IPv6 devices
can talk directly to each other without needing any VPN or similar.  And
yes, this is available today.

Note that just like the PSTN you might not want to do this without
encryption and taking other security/safety steps.   (Like the PSTN, the
internet can be tapped).

>

Re: [External] Re: Diversity in threading, Diversity of MUAs (was Re: How threading works

2024-01-15 Thread Hunter Fuller via NANOG

On Mon, Jan 15, 2024 at 12:37 AM Andy Smith  wrote:
> Over on a technical support list there are actually some prolific
> old time posters asking for subject changes in sprawling threads
> (and citing the list's FAQ…) but also gmail users asking for people
> to *not* do that as it spawns new "conversations" for them. There,
> the gmail users are at odds with ancient mailing list etiquette as
> followed by a dwindling tech priesthood, but the gmailers now form
> more than 30% of the active posting user base of the list.

I don't think the attitudes are at odds.

I use Google Workspace, so it is beneficial to me when someone changes
the subject line *to indicate that the actual subject matter has
changed* - because this causes Google Mail to break it out into a new
thread, which is great, because it keeps the new subject matter apart
from the old. (This is probably why Google threadbreaks when the
subject line changes. If the subject of the conversation changed, then
it's a new conversation.)

When the subject line is changed but we have NOT changed topics, that
is when it becomes confusing to me.

-- 
Hunter Fuller (they)
Router Jockey
VBH M-1C
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

It was always about using 240/4 as shared service provider space, just a
roundabout way of doing it.

You can call a horse a horse, or you can call it "an animal that pulls a
wagon which carries people and items from A to B". At the end of the day,
it's still a horse.

Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 14:00, Brandon Jackson  wrote:

> If I remember correctly, quite a few years ago, "EzIP" was something else
> entirely.
>
> I vaguely remember them talking about having some kind of extended IPv4
> address or to use an extension header or something like that. It was
> something that would essentially require the entire Internet to be reworked
> in order to work. Kind of like this, but even more so because these
> modified bastardized packets would be sent across the DFZ.
>
> And it seems now it's morphed into simply opening up and reusing 240/4
>
>
> Brandon Jackson
> bjack...@napshome.net
>
>
> On Mon, Jan 15, 2024, 19:47 Christopher Hawker 
> wrote:
>
>> From what I gather, "EzIP" is just a fancy name for repurposing the 240/4
>> address space as RFC6598 shared address space for service providers and
>> adding another gateway into a network to make it look like a new
>> technology, nothing more. It does absolutely nothing more than what is
>> already available and in use today. It's a solid NO from me, in case it's
>> not already clear.
>>
>> Regards,
>> Christopher Hawker
>>
>> On Tue, 16 Jan 2024 at 11:16,  wrote:
>>
>>> The reality is your whole concept for EzIP is so impractical and so
>>> unlikely to be implemented by any service provider with half a clue, that
>>> I’m not sure why I would even try to explain to you why a Radio Access
>>> Network is relevant to the Internet.  You obviously have decided you are
>>> smarter than everyone else on NANOG.
>>>
>>> Shane
>>>
>>> On Jan 15, 2024, at 6:46 PM, Abraham Y. Chen  wrote:
>>>
>>> 
>>> Hi, Sronan:
>>>
>>> 1) “Radio Access Network”:
>>>
>>> Thanks for bringing this up. Being an RF engineer by training, I am
>>> aware of this terminology. However, how specific is its claimed applicable
>>> domain?
>>>
>>> 2)I went to search on an acronym site and found a long list of
>>> expressions that abbreviate to RAN. It starts with Royal Australian Navy
>>> and Rainforest Action Network as the third. Then, Return Authorization
>>> Number is the fourth:
>>>
>>> https://www.acronymfinder.com/RAN.html
>>>
>>> 3)In fact, "Regional Area Network" is about twentieth on it! So,
>>> unless there is some kind of Registered Trademark conflict, this probably
>>> is on my low priority to-do list for the time being.
>>> 4) Of course, if you have any alternative to suggest, my ears are
>>> all yours.
>>>
>>> Regards,
>>>
>>> Abe (2024-01-15 18:48)
>>>
>>>
>>>
>>>
>>>
>>> On 2024-01-15 17:14, sro...@ronan-online.com wrote:
>>>
>>> Please don’t use the term RAN, this acronym already has a very specific
>>> definition in the telecom/network space as “Radio Access Network.”
>>>
>>> Shane
>>>
>>> On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen 
>>>  wrote:
>>>
>>> 
>>> Hi, Forrest:
>>>
>>> 1)Re: Ur. Pt. 1):The initial deployment of EzIP overlay is only
>>> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
>>> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
>>> OpenWrt. So that none of the on-premises IoTs will sense any changes. I
>>> don't see how an upgrade of such equipment to IPv6 could be simpler and
>>> less work. Please elaborate.
>>>
>>> 2)Re: Ur. Pt. 2): Since the RAN still appear to be the original
>>> CG-NAT to the Internet through the same IPv4 link to the Internet core,
>>> services from Google, YouTube, etc. will not know something has changed
>>> either.
>>>
>>> 3)" ... someone with enough market power is going to basically say
>>> "enough is enough"  ...  ":
>>>
>>> We need to look at this transition with a "Divide and Conquer"
>>> perspective. That is, the CG-NAT and consequently the RAN are part of IAP
>>> (Internet Access Provider) facility. While Google, YouTube, etc. are ICPs
>>> (Internet Content Providers). Relatively speaking, the IAP is like the
>>> hardware part of a system, while ICP is the software. They are two separate
>>> parts when combined will provide the service that customers want. Normally,
>>> these two parts are separate businesses, although some may be under the
>>> same owner in some situations. The scenario that you are proposing is like
>>> back to the old Bell System days when AT&T decided everything. I am sure
>>> that Internet players will try very hard to avoid being labelled as such.
>>>
>>> Regards,
>>>
>>>
>>> Abe (2024-01-15 00:02)
>>>
>>>
>>> On 2024-01-13 03:30, Forrest Christian (List Account) wrote:
>>>
>>> A couple of points:
>>>
>>> 1) There is less work needed to support IPv6 than your proposed
>>> solution.  I'm not taking about 230/4.  I'm talking about your EzIP
>>> overlay.
>>>
>>> 2) Assume that Google decided that

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

2024-01-15 Thread Brandon Jackson

If I remember correctly, quite a few years ago, "EzIP" was something else
entirely.

I vaguely remember them talking about having some kind of extended IPv4
address or to use an extension header or something like that. It was
something that would essentially require the entire Internet to be reworked
in order to work. Kind of like this, but even more so because these
modified bastardized packets would be sent across the DFZ.

And it seems now it's morphed into simply opening up and reusing 240/4


Brandon Jackson
bjack...@napshome.net


On Mon, Jan 15, 2024, 19:47 Christopher Hawker  wrote:

> From what I gather, "EzIP" is just a fancy name for repurposing the 240/4
> address space as RFC6598 shared address space for service providers and
> adding another gateway into a network to make it look like a new
> technology, nothing more. It does absolutely nothing more than what is
> already available and in use today. It's a solid NO from me, in case it's
> not already clear.
>
> Regards,
> Christopher Hawker
>
> On Tue, 16 Jan 2024 at 11:16,  wrote:
>
>> The reality is your whole concept for EzIP is so impractical and so
>> unlikely to be implemented by any service provider with half a clue, that
>> I’m not sure why I would even try to explain to you why a Radio Access
>> Network is relevant to the Internet.  You obviously have decided you are
>> smarter than everyone else on NANOG.
>>
>> Shane
>>
>> On Jan 15, 2024, at 6:46 PM, Abraham Y. Chen  wrote:
>>
>> 
>> Hi, Sronan:
>>
>> 1) “Radio Access Network”:
>>
>> Thanks for bringing this up. Being an RF engineer by training, I am
>> aware of this terminology. However, how specific is its claimed applicable
>> domain?
>>
>> 2)I went to search on an acronym site and found a long list of
>> expressions that abbreviate to RAN. It starts with Royal Australian Navy
>> and Rainforest Action Network as the third. Then, Return Authorization
>> Number is the fourth:
>>
>> https://www.acronymfinder.com/RAN.html
>>
>> 3)In fact, "Regional Area Network" is about twentieth on it! So,
>> unless there is some kind of Registered Trademark conflict, this probably
>> is on my low priority to-do list for the time being.
>> 4) Of course, if you have any alternative to suggest, my ears are all
>> yours.
>>
>> Regards,
>>
>> Abe (2024-01-15 18:48)
>>
>>
>>
>>
>>
>> On 2024-01-15 17:14, sro...@ronan-online.com wrote:
>>
>> Please don’t use the term RAN, this acronym already has a very specific
>> definition in the telecom/network space as “Radio Access Network.”
>>
>> Shane
>>
>> On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen 
>>  wrote:
>>
>> 
>> Hi, Forrest:
>>
>> 1)Re: Ur. Pt. 1):The initial deployment of EzIP overlay is only
>> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
>> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
>> OpenWrt. So that none of the on-premises IoTs will sense any changes. I
>> don't see how an upgrade of such equipment to IPv6 could be simpler and
>> less work. Please elaborate.
>>
>> 2)Re: Ur. Pt. 2): Since the RAN still appear to be the original
>> CG-NAT to the Internet through the same IPv4 link to the Internet core,
>> services from Google, YouTube, etc. will not know something has changed
>> either.
>>
>> 3)" ... someone with enough market power is going to basically say
>> "enough is enough"  ...  ":
>>
>> We need to look at this transition with a "Divide and Conquer"
>> perspective. That is, the CG-NAT and consequently the RAN are part of IAP
>> (Internet Access Provider) facility. While Google, YouTube, etc. are ICPs
>> (Internet Content Providers). Relatively speaking, the IAP is like the
>> hardware part of a system, while ICP is the software. They are two separate
>> parts when combined will provide the service that customers want. Normally,
>> these two parts are separate businesses, although some may be under the
>> same owner in some situations. The scenario that you are proposing is like
>> back to the old Bell System days when AT&T decided everything. I am sure
>> that Internet players will try very hard to avoid being labelled as such.
>>
>> Regards,
>>
>>
>> Abe (2024-01-15 00:02)
>>
>>
>> On 2024-01-13 03:30, Forrest Christian (List Account) wrote:
>>
>> A couple of points:
>>
>> 1) There is less work needed to support IPv6 than your proposed
>> solution.  I'm not taking about 230/4.  I'm talking about your EzIP
>> overlay.
>>
>> 2) Assume that Google decided that they would no longer support IPv4 for
>> any of their services at a specific date a couple of years in the future.
>> That is,  you either needed an IPv6 address or you couldn't reach Google,
>> youtube, Gmail and the rest of the public services.  I bet that in this
>> scenario every eyeball provider in the country all of a sudden would be
>> extremely motivated to deploy IPv6, even if the IPv4 providers end up
>> natting their IPv4 customers to IPv6.  I really expect something like th

Re: "Hypothetical" Datacenter Overheating

Someone I talked to while on scene today said their area got to 130 and cooked 
two core routers. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Mike Hammett"  
To: "NANOG"  
Sent: Monday, January 15, 2024 8:08:25 AM 
Subject: "Hypothetical" Datacenter Overheating 


Let's say that hypothetically, a datacenter you're in had a cooling failure and 
escalated to an average of 120 degrees before mitigations started having an 
effect. What are normal QA procedures on your behalf? What is the facility 
likely to be doing? What should be expected in the aftermath? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

>From what I gather, "EzIP" is just a fancy name for repurposing the 240/4
address space as RFC6598 shared address space for service providers and
adding another gateway into a network to make it look like a new
technology, nothing more. It does absolutely nothing more than what is
already available and in use today. It's a solid NO from me, in case it's
not already clear.

Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 11:16,  wrote:

> The reality is your whole concept for EzIP is so impractical and so
> unlikely to be implemented by any service provider with half a clue, that
> I’m not sure why I would even try to explain to you why a Radio Access
> Network is relevant to the Internet.  You obviously have decided you are
> smarter than everyone else on NANOG.
>
> Shane
>
> On Jan 15, 2024, at 6:46 PM, Abraham Y. Chen  wrote:
>
> 
> Hi, Sronan:
>
> 1) “Radio Access Network”:
>
> Thanks for bringing this up. Being an RF engineer by training, I am
> aware of this terminology. However, how specific is its claimed applicable
> domain?
>
> 2)I went to search on an acronym site and found a long list of
> expressions that abbreviate to RAN. It starts with Royal Australian Navy
> and Rainforest Action Network as the third. Then, Return Authorization
> Number is the fourth:
>
> https://www.acronymfinder.com/RAN.html
>
> 3)In fact, "Regional Area Network" is about twentieth on it! So,
> unless there is some kind of Registered Trademark conflict, this probably
> is on my low priority to-do list for the time being.
> 4) Of course, if you have any alternative to suggest, my ears are all
> yours.
>
> Regards,
>
> Abe (2024-01-15 18:48)
>
>
>
>
>
> On 2024-01-15 17:14, sro...@ronan-online.com wrote:
>
> Please don’t use the term RAN, this acronym already has a very specific
> definition in the telecom/network space as “Radio Access Network.”
>
> Shane
>
> On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen 
>  wrote:
>
> 
> Hi, Forrest:
>
> 1)Re: Ur. Pt. 1):The initial deployment of EzIP overlay is only
> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
> OpenWrt. So that none of the on-premises IoTs will sense any changes. I
> don't see how an upgrade of such equipment to IPv6 could be simpler and
> less work. Please elaborate.
>
> 2)Re: Ur. Pt. 2): Since the RAN still appear to be the original
> CG-NAT to the Internet through the same IPv4 link to the Internet core,
> services from Google, YouTube, etc. will not know something has changed
> either.
>
> 3)" ... someone with enough market power is going to basically say
> "enough is enough"  ...  ":
>
> We need to look at this transition with a "Divide and Conquer"
> perspective. That is, the CG-NAT and consequently the RAN are part of IAP
> (Internet Access Provider) facility. While Google, YouTube, etc. are ICPs
> (Internet Content Providers). Relatively speaking, the IAP is like the
> hardware part of a system, while ICP is the software. They are two separate
> parts when combined will provide the service that customers want. Normally,
> these two parts are separate businesses, although some may be under the
> same owner in some situations. The scenario that you are proposing is like
> back to the old Bell System days when AT&T decided everything. I am sure
> that Internet players will try very hard to avoid being labelled as such.
>
> Regards,
>
>
> Abe (2024-01-15 00:02)
>
>
> On 2024-01-13 03:30, Forrest Christian (List Account) wrote:
>
> A couple of points:
>
> 1) There is less work needed to support IPv6 than your proposed solution.
> I'm not taking about 230/4.  I'm talking about your EzIP overlay.
>
> 2) Assume that Google decided that they would no longer support IPv4 for
> any of their services at a specific date a couple of years in the future.
> That is,  you either needed an IPv6 address or you couldn't reach Google,
> youtube, Gmail and the rest of the public services.  I bet that in this
> scenario every eyeball provider in the country all of a sudden would be
> extremely motivated to deploy IPv6, even if the IPv4 providers end up
> natting their IPv4 customers to IPv6.  I really expect something like this
> to be the next part of the end game for IPv4.
>
> Or stated differently: at some point someone with enough market power is
> going to basically say "enough is enough" and make the decision for the
> rest of us that IPv4 is effectively done on the public internet.   The
> large tech companies all have a history of sunsetting things when it
> becomes a bigger problem to support than it's worth.  Try getting a modern
> browser that works on 32 bit windows.   Same with encryption protocols,
> Java in the browser,  Shockwave and flash, and on and on.
>
> I see no reason why IPv4 should be any different.
>
> On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen  wrote:
>
>> Hi, Forrest:
>>
>> 0)You put out more than o

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

The reality is your whole concept for EzIP is so impractical and so unlikely to be implemented by any service provider with half a clue, that I’m not sure why I would even try to explain to you why a Radio Access Network is relevant to the Internet. You obviously have decided you are smarter than everyone else on NANOG.ShaneOn Jan 15, 2024, at 6:46 PM, Abraham Y. Chen wrote:

Hi, Sronan:

1) “Radio Access
Network”:

Thanks for bringing
this up. Being an RF engineer by training, I am aware of this
terminology. However, how specific is its claimed applicable
domain?

2) I went to search
on an acronym site and found a long list of expressions that
abbreviate to RAN. It starts with Royal Australian Navy and
Rainforest Action Network as the third. Then, Return
Authorization Number is the fourth:

https://www.acronymfinder.com/RAN.html

3) In fact, "Regional Area Network" is about
twentieth on it! So, unless there is some kind of Registered
Trademark conflict, this probably is on my low priority to-do
list for the time being.
4) Of course, if you have any alternative to
suggest, my ears are all yours.

Regards,

Abe (2024-01-15 18:48)

On 2024-01-15 17:14, sro...@ronan-online.com
wrote:

Please don’t use the term RAN, this acronym already
has a very specific definition in the telecom/network space as
“Radio Access Network.”

Shane

On Jan 15, 2024, at 5:12 PM, Abraham Y.
Chen
wrote:

Hi, Forrest:

1) Re: Ur. Pt.
1): The initial deployment of EzIP overlay is only
applying 240/4 to existing (IPv4 based) CG-NAT facility to
become the overlaying RAN, plus upgrading RG-NATs (Routing
/ Residential NATs) to OpenWrt. So that none of the
on-premises IoTs will sense any changes. I don't see how
an upgrade of such equipment to IPv6 could be simpler and
less work. Please elaborate.

2) Re: Ur. Pt.
2): Since the RAN still appear to be the original
CG-NAT to the Internet through the same IPv4 link to the
Internet core, services from Google, YouTube, etc. will
not know something has changed either.

3) " ...
someone with enough market power is going to basically say
"enough is enough" ... ":

We need to
look at this transition with a "Divide and Conquer"
perspective. That is, the CG-NAT and consequently the RAN
are part of IAP (Internet Access Provider) facility. While
Google, YouTube, etc. are ICPs (Internet Content
Providers). Relatively speaking, the IAP is like the
hardware part of a system, while ICP is the software. They
are two separate parts when combined will provide the
service that customers want. Normally, these two parts are
separate businesses, although some may be under the same
owner in some situations. The scenario that you are
proposing is like back to the old Bell System days when
AT&T decided everything. I am sure that Internet
players will try very hard to avoid being labelled as
such.

Regards,

Abe (2024-01-15
00:02)

On 2024-01-13 03:30, Forrest
Christian (List Account) wrote:

A couple of points:

1) There is less work needed to support
IPv6 than your proposed solution. I'm not taking about
230/4. I'm talking about your EzIP overlay.

2) Assume that Google decided that they
would no longer support IPv4 for any of their services
at a specific date a couple of years in the future.
That is, you either needed an IPv6 address or you
couldn't reach Google, youtube, Gmail and the rest of
the public services. I bet that in this scenario every
eyeball provider in the country all of a sudden would be
extremely motivated to deploy IPv6, even if the IPv4

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block


Hi, Sronan:

1) “Radio Access Network”:

    Thanks for bringing this up. Being an RF engineer by training, I am 
aware of this terminology. However, how specific is its claimed 
applicable domain?


2)    I went to search on an acronym site and found a long list of 
expressions that abbreviate to RAN. It starts with Royal Australian Navy 
and Rainforest Action Network as the third. Then, Return Authorization 
Number is the fourth:


https://www.acronymfinder.com/RAN.html

3)    In fact, "Regional Area Network" is about twentieth on it! So, 
unless there is some kind of Registered Trademark conflict, this 
probably is on my low priority to-do list for the time being.


4)     Of course, if you have any alternative to suggest, my ears are 
all yours.


Regards,

Abe (2024-01-15 18:48)





On 2024-01-15 17:14, sro...@ronan-online.com wrote:
Please don’t use the term RAN, this acronym already has a very 
specific definition in the telecom/network space as “Radio Access 
Network.”


Shane


On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen  wrote:


Hi, Forrest:

1)    Re: Ur. Pt. 1):    The initial deployment of EzIP overlay is 
only applying 240/4 to existing (IPv4 based) CG-NAT facility to 
become the overlaying RAN, plus upgrading RG-NATs (Routing / 
Residential NATs) to OpenWrt. So that none of the on-premises IoTs 
will sense any changes. I don't see how an upgrade of such equipment 
to IPv6 could be simpler and less work. Please elaborate.


2)    Re: Ur. Pt. 2):     Since the RAN still appear to be the 
original CG-NAT to the Internet through the same IPv4 link to the 
Internet core, services from Google, YouTube, etc. will not know 
something has changed either.


3)    " ... someone with enough market power is going to basically 
say "enough is enough"  ...  ":


    We need to look at this transition with a "Divide and Conquer" 
perspective. That is, the CG-NAT and consequently the RAN are part of 
IAP (Internet Access Provider) facility. While Google, YouTube, etc. 
are ICPs (Internet Content Providers). Relatively speaking, the IAP 
is like the hardware part of a system, while ICP is the software. 
They are two separate parts when combined will provide the service 
that customers want. Normally, these two parts are separate 
businesses, although some may be under the same owner in some 
situations. The scenario that you are proposing is like back to the 
old Bell System days when AT&T decided everything. I am sure that 
Internet players will try very hard to avoid being labelled as such.


Regards,


Abe (2024-01-15 00:02)


On 2024-01-13 03:30, Forrest Christian (List Account) wrote:

A couple of points:

1) There is less work needed to support IPv6 than your proposed 
solution.  I'm not taking about 230/4.  I'm talking about your EzIP 
overlay.


2) Assume that Google decided that they would no longer support IPv4 
for any of their services at a specific date a couple of years in 
the future. That is,  you either needed an IPv6 address or you 
couldn't reach Google, youtube, Gmail and the rest of the public 
services.  I bet that in this scenario every eyeball provider in the 
country all of a sudden would be extremely motivated to deploy IPv6, 
even if the IPv4 providers end up natting their IPv4 customers to 
IPv6. I really expect something like this to be the next part of the 
end game for IPv4.


Or stated differently: at some point someone with enough market 
power is going to basically say "enough is enough" and make the 
decision for the rest of us that IPv4 is effectively done on the 
public internet.   The large tech companies all have a history of 
sunsetting things when it becomes a bigger problem to support than 
it's worth.  Try getting a modern browser that works on 32 bit 
windows.   Same with encryption protocols, Java in the browser,  
Shockwave and flash, and on and on.


I see no reason why IPv4 should be any different.

On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen  wrote:

Hi, Forrest:

0)    You put out more than one topic, all at one time. Allow me
to address each briefly.

1)   "  The existence of that CG-NAT box is a thorn in every
provider's side and every provider that has one wants to make it
go away as quickly as possible.   ":

    The feeling and desire are undeniable facts. However, the
existing configuration was evolved from various considerations
through a long time. There is a tremendous inertia accumulated
on it. There is no magic bullet to get rid of it quickly. We
must study carefully to evolve it further incrementally.
Otherwise, an even bigger headache or disaster will happen.

2) "  The quickest and most straightforward way to eliminate the
need for any CG-NAT is to move to a bigger address space.  ":

    The obvious answer was IPv6. However, its performance after
near two decades of deployment has not been convincing. EzIP is
an alternative, requiring hardly any development, to addres

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

If "EzIP" is about using 240/4 as CGNAT space, let's call it what it is,
not rename something that already exists and attempt to claim it as a new
idea.

It is completely unnecessary to use 240/4 as CGNAT space. Here are a few
reasons why:

   1. There are 4,194,304 IPv4 addresses in a /10 prefix. Allowing for a
   /24 from this to be used for CGNAT gateways, load balancing, etc. this
   still allows for 4,194,048 usable addresses for CPE. When performing NAT,
   you would need to allocate each subscriber approximately 1000 ports for NAT
   to work successfully. The entire /10 (less the /24) would require the
   equivalent of a /16 public IPv4 prefix to use the entire 100.64/10 space in
   one region. To put this into comparison, you would use the entire 100.64/10
   space in a city the size of New York or Los Angeles allowing for one
   internet service per 4 or 2 people respectively. It's not practical.
   2. Multiple CGNAT regions that are at capacity would not have a need for
   uniquely routable IP space between them. It's heavily designed for traffic
   from the user to the wider internet, not for inter-region routing. Carriers
   already have systems in place where subscribers can request a public
   address if they need it (such as working from home with advanced corporate
   networks, etc).

100.64/10 is not public IP space, because it is not usable in the DFZ. I
don't believe there is any confusion or ambiguity about this space because
if you do a Whois lookup on 100.64.0.0/10 at any one of the five RIRs, it
reflects that it is IANA shared address space for service providers.
Footnote 6 on the page you referenced reads "100.64.0.0/10 reserved for
Shared Address Space". It has not been delegated to ARIN. Rather clear as
to its use case.

I don't think you quite grasp the concept that OpenWRT is not compatible
with devices that do not support it. It would only work on routers for
which it is compatible and it would not be appropriate to expect every
device vendor to support it. To add-on to this, why would vendors need to
enable 240/4 CGNAT support when their customers don't have a need for it?

You've provided a link to a D-Link managed switch, not a router. Just
because it can support L2 routing, doesn't make it a router.

I'm all for discussing ideas and suggestions and working towards proper
IPv6 deployment. It certainly appears to be the case that the community
does not support your proposed "EzIP" solution. If you are recommending
that 240/4 space be used for CGNAT space under RFC6598, then call it as it
is instead of inventing new terminology.

Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 03:27, Abraham Y. Chen  wrote:

> Hi, Christopher:
>
> 1)" Hang on... So EzIP is now about using 240/4 as CGNAT space? Wait,
> I'm lost...   ":
>
> Correct. This is one way to visualize the EzIP deployment. This
> configuration is so far the most concise manner to describe the the EzIP
> building block, RAN (Regional Area Network). The nice thing about this
> approach is that everything exists and is already working daily in each
> CG-NAT cluster. All needed to expand its capability is a larger netblock.
> Since 240/4 is fundamentally not an outlier in the overall IPv4 address
> pool, except being classified as "Reserved" for a long time, enabling it to
> work in a CG-NAT should not be any big challenge.
> 2)"   ... There is no such thing as "semi-private" space in the world
> of CGNAT, ... ":
>
> Correct. However, not distinguishing 100.64/10 netblock from the
> common public and private parts of the IPv4 space made it vague as which
> function does it provide. That is, in terms of re-usability for each
> isolated geographical area, it is like another RFC1918 private netblock. On
> the other hand, CG-NAT is clearly used in geographically public areas. So,
> 100.64/10 should be classified as "public". In addition, 100.64/10 is
> listed according to "IANA IPv4 Address Space Registry" as part of the 100/8
> netblock under ARIN, but now used by everyone worldwide. To avoid similar
> ambiguity that leads to confusions, we decided to call 240/4 as
> "semi-public" to more explicitly convey the concept. (Actually, we
> initially called 240/4 "semi-private" thinking that it could be the fourth
> RFC1918 netblock, until we realized that the RFC6589 environment was a much
> better fit.)
>
> 3)" Your "solution" to residential gateways not supporting the use of
> 240/4 space being upgraded to OpenWrt won't work, because not all CPE
> supports OpenWrt.   ":
>
> OpenWrt is just an open source RG code that can replace that in
> commercial RGs that have been supporting CPEs. Like the EzIP concept, the
> OpenWrt upgrade of RG-NAT is an enhancement to the existing RG
> functionality. Thus, OpenWrt enabled RGs can operate with the combination
> of public (including RFC6589) with 240/4 netblocks on the upstream (WAN)
> side, and private (RFC1918) with 240/4 netblocks on the downstream (LAN)
> sid

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread Karl Auer

On Mon, 2024-01-15 at 08:08 -0600, Mike Hammett wrote:
> Let's say that hypothetically, a datacenter you're in had a cooling
> failure and escalated to an average of 120 degrees

Major double-take there for this non-US reader, until I realised you
just had to mean Fahrenheit.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread Lamar Owen

On Mon, Jan 15, 2024 at 7:14 AM  wrote:
>> I’m more interested in how you lose six chillers all at once.
>Extreme cold. If the transfer temperature is too low, they can reach a
>state where the refrigerant liquifies too soon, damaging the
compressor.
>Regards,
>Bill Herrin

Our 70-ton Tranes here have kicked out on 'freeze warning' before; there's a 
strainer in the water loop at the evaporator that can clog, restricting flow 
enough to allow freezing to occur if the chiller is actively cooling.  It's so 
strange to have an overheating data center in subzero (F) temps.  The flow 
sensor in the water loop can sometimes get too cold and not register the flow 
as well.

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread William Herrin

On Mon, Jan 15, 2024 at 7:14 AM  wrote:
> I’m more interested in how you lose six chillers all at once.

Extreme cold. If the transfer temperature is too low, they can reach a
state where the refrigerant liquifies too soon, damaging the
compressor.

Regards,
Bill Herrin


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

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

You most certainly can, it's called a VPN. One side initiates a connection
to the other.

;)

Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 07:21, Abraham Y. Chen  wrote:

> Hi, Forrest:
>
> 1)I have a question:
>
> If I subscribe to IPv6, can I contact another similar subscriber to
> communicate (voice and data) directly between two homes in private like the
> dial-up modem operations in the PSTN? If so, is it available anywhere right
> now?
>
> Regards,
>
>
> Abe (2024-01-15 15:20)
>
>
> Let me start with I think we're largely on the same page here.
>
> The transition I see happening next is that the consumer traffic largely
> moves to IPv6 with no CG-NAT.  That is, if you're at home or on your phone
> watching video or doing social media or using whatever app is all the rage
> it's going to be over IPv6.
>
> My point was largely that I believe that at some point the big consumer
> (not business) focused companies are going to realize they can use market
> forces to encourage the remaining IPv4-only eyeball networks to transition
> to support IPv6 connections from their customers.  I don't know if the
> timeframe is next year or 20 years from now,  but I do know the tech
> companies are very good at looking at the costs of maintaining backwards
> compatibility with old tech and figuring out ways to shed those costs when
> they no longer make sense.  If they can utilize various forms of pressure
> to make this happen quicker, I fully expect them to do so.
>
> Inside a business network,  or even at home,  it wouldn't surprise me if
> we're both long gone before IPv4 is eradicated.   I know there is going to
> be a lot of IPv4 in my network for years to come just because of product
> lifecycles.
>
> As far as "CG-NAT-like" technologies go (meaning NAT in a provider's
> network), they're unfortunately going to be with us for a long time since
> customers seem to want to be able to reach everything regardless of the
> IPv4 or IPv6 status of the customer or endpoint.   I also expect that most
> service providers with business customers are going to be carrying both
> IPv4 and IPv6 for a long time, not to mention doing a fair bit of
> translation in both directions.
>
> I won't go deeply into the whole IPv4 vs IPv6 discussion for a business
> customer's "public address" because the topic is far too nuanced for an
> email to cover them accurately.   Suffice it to say that I don't disagree
> that business today largely wants IPv4, but some seem to be becoming aware
> of what IPv6 can do and are looking to have both options available to them,
> at least outside the firewall.
>
> On Sat, Jan 13, 2024, 2:04 AM Brett O'Hara  wrote:
>
>> Ok you've triggered me on your point 2.  I'll address the elephant in the
>> room.
>>
>> IPv4 is never ever going away.
>>
>> Right now consumer services are mostly (mobile, wireless, landline, wide
>> generalization) are IPv6 capable.  Most consumer applications are ipv6
>> capable, Google, Facebook, etc.There is light at the very end of the tunnel
>> that suggests that one day we won't have to deploy CGNAT444 for our
>> consumers to get to content, we may only have to do NAT64 for them to get
>> to the remaining Ipv4 Internet.  We're still working hard on removing our
>> reliance on genuine ipv4 ranges to satisfy our customer needs, It's still a
>> long way off, but it's coming.
>>
>> Here's the current problem.  Enterprise doesn't need ipv6 or want ipv6.
>> You might be able to get away with giving CGNAT to your consumers, but your
>> enterprise customer will not accept this. How will they terminate their
>> remote users?  How will they do B2B with out inbound NAT?  Yes, there are
>> solutions, but if you don't need to, why?  They pay good money, why can't
>> they have real ipv4?  All their internal networks are IPv4 rfc1918.  They
>> are happy with NAT.  Their application service providers are ipv4
>> only. Looking at the services I access for work things like SAP,
>> SerivceNow, Office386, Sharepoint, Okta, Dayforce, Xero, and I'm sure many
>> more, none can not be accessed on ipv6 alone..  Their internal network
>> lifecycle is 10+ years.  They have no interest in trying new things or
>> making new technology work without a solid financial reason and there is
>> none for them implementing ipv6.   And guess where all the IP addresses
>> we're getting back from our consumers are going?  Straight to our good
>> margin enterprise customers and their application service providers.
>> Consumer CGNAT isn't solving problems, it's creating more.
>>
>> The end of IPv4 isn't nigh, it's just privileged only.
>>
>> PS When you solve that problem in 50 years time, I'll be one of those old
>> fogey's keeping an IPv4 service alive as an example of "the old Internet"
>> for those young whippersnappers to be amazed by.
>>
>> Regards,
>>Brett
>>
>>
>
> 
> Virus-free.ww

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

Please don’t use the term RAN, this acronym already has a very specific definition in the telecom/network space as “Radio Access Network.”ShaneOn Jan 15, 2024, at 5:12 PM, Abraham Y. Chen  wrote:

  

  
  
Hi, Forrest:

  
1)    Re: Ur. Pt. 1):   
The initial deployment of EzIP overlay is only applying 240/4 to
existing (IPv4 based) CG-NAT facility to become the overlaying
RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
OpenWrt. So that none of the on-premises IoTs will sense any
changes. I don't see how an upgrade of such equipment to IPv6
could be simpler and less work. Please elaborate.

  
2)    Re: Ur. Pt. 2):
    Since the RAN still appear to be the original CG-NAT to the
Internet through the same IPv4 link to the Internet core,
services from Google, YouTube, etc. will not know something has
changed either.

  
3)    " ... someone with
enough market power is going to basically say "enough is
enough"  ...  ": 

  
    We need to look at
this transition with a "Divide and Conquer" perspective. That
is, the CG-NAT and consequently the RAN are part of IAP
(Internet Access Provider) facility. While Google, YouTube, etc.
are ICPs (Internet Content Providers). Relatively speaking, the
IAP is like the hardware part of a system, while ICP is the
software. They are two separate parts when combined will provide
the service that customers want. Normally, these two parts are
separate businesses, although some may be under the same owner
in some situations. The scenario that you are proposing is like
back to the old Bell System days when AT&T decided
everything. I am sure that Internet players will try very hard
to avoid being labelled as such.

  
Regards,

  

  
Abe (2024-01-15 00:02)

  


On 2024-01-13 03:30, Forrest Christian
  (List Account) wrote:


  
  
A couple of points: 


1) There is less work needed to support IPv6
  than your proposed solution.  I'm not taking about 230/4.  I'm
  talking about your EzIP overlay. 


2) Assume that Google decided that they would no
  longer support IPv4 for any of their services at a specific
  date a couple of years in the future.  That is,  you either
  needed an IPv6 address or you couldn't reach Google, youtube,
  Gmail and the rest of the public services.  I bet that in this
  scenario every eyeball provider in the country all of a sudden
  would be extremely motivated to deploy IPv6, even if the IPv4
  providers end up natting their IPv4 customers to IPv6.  I
  really expect something like this to be the next part of the
  end game for IPv4.  


Or stated differently: at some point someone
  with enough market power is going to basically say "enough is
  enough" and make the decision for the rest of us that IPv4 is
  effectively done on the public internet.   The large tech
  companies all have a history of sunsetting things when it
  becomes a bigger problem to support than it's worth.  Try
  getting a modern browser that works on 32 bit windows.   Same
  with encryption protocols, Java in the browser,  Shockwave and
  flash, and on and on. 


I see no reason why IPv4 should be any
  different.  

  
On Fri, Jan 12, 2024, 3:42
  PM Abraham Y. Chen 
  wrote:


  
Hi, Forrest:
0)    You put out more than one topic,
all at one time. Allow me to address each briefly.
1)   "  The existence of that CG-NAT
box is a thorn in every provider's side and every
provider that has one wants to make it go away as
quickly as possible.   ":
    The feeling and desire are
undeniable facts. However, the existing
configuration was evolved from various
considerations through a long time. There is a
tremendous inertia accumulated on it. There is no
magic bullet to get rid of it quickly. We must study carefully to evolve it
further incrementally. Otherwise, an even bigger
headache or disaster will happen.
  
2)    "  The
quickest and most straightforward way to eliminate
the need for any CG-NAT is to move to a bigger
addres

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread Martin Hannigan

On Mon, Jan 15, 2024 at 4:10 PM Jay Hennigan  wrote:

> On 1/15/24 10:37, Pennington, Scott wrote:
> > yes but it has been -8 in Chicago plenty of times before this.
> >   Very interested in root cause...
>
> Absolutely. My point was that claiming "Global warming" isn't going to
> fly as an excuse.
>

+1

Is their design N+1?

https://www.equinix.com/data-centers/americas-colocation/united-states-colocation/chicago-data-centers/ch1

We're not smashing temp records in Chicago. At least it doesn't seem so
when you look across historical data:

https://www.weather.gov/lot/Chicago_Temperature_Records

HTH,

-M<

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block


Hi, Forrest:

1)    Re: Ur. Pt. 1): The initial deployment of EzIP overlay is only 
applying 240/4 to existing (IPv4 based) CG-NAT facility to become the 
overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to 
OpenWrt. So that none of the on-premises IoTs will sense any changes. I 
don't see how an upgrade of such equipment to IPv6 could be simpler and 
less work. Please elaborate.


2)    Re: Ur. Pt. 2):     Since the RAN still appear to be the original 
CG-NAT to the Internet through the same IPv4 link to the Internet core, 
services from Google, YouTube, etc. will not know something has changed 
either.


3)    " ... someone with enough market power is going to basically say 
"enough is enough"  ...  ":


    We need to look at this transition with a "Divide and Conquer" 
perspective. That is, the CG-NAT and consequently the RAN are part of 
IAP (Internet Access Provider) facility. While Google, YouTube, etc. are 
ICPs (Internet Content Providers). Relatively speaking, the IAP is like 
the hardware part of a system, while ICP is the software. They are two 
separate parts when combined will provide the service that customers 
want. Normally, these two parts are separate businesses, although some 
may be under the same owner in some situations. The scenario that you 
are proposing is like back to the old Bell System days when AT&T decided 
everything. I am sure that Internet players will try very hard to avoid 
being labelled as such.


Regards,


Abe (2024-01-15 00:02)


On 2024-01-13 03:30, Forrest Christian (List Account) wrote:

A couple of points:

1) There is less work needed to support IPv6 than your proposed 
solution.  I'm not taking about 230/4.  I'm talking about your EzIP 
overlay.


2) Assume that Google decided that they would no longer support IPv4 
for any of their services at a specific date a couple of years in the 
future.  That is,  you either needed an IPv6 address or you couldn't 
reach Google, youtube, Gmail and the rest of the public services.  I 
bet that in this scenario every eyeball provider in the country all of 
a sudden would be extremely motivated to deploy IPv6, even if the IPv4 
providers end up natting their IPv4 customers to IPv6.  I really 
expect something like this to be the next part of the end game for IPv4.


Or stated differently: at some point someone with enough market power 
is going to basically say "enough is enough" and make the decision for 
the rest of us that IPv4 is effectively done on the public internet.  
 The large tech companies all have a history of sunsetting things when 
it becomes a bigger problem to support than it's worth.  Try getting a 
modern browser that works on 32 bit windows.   Same with encryption 
protocols, Java in the browser,  Shockwave and flash, and on and on.


I see no reason why IPv4 should be any different.

On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen  wrote:

Hi, Forrest:

0)    You put out more than one topic, all at one time. Allow me
to address each briefly.

1)   "  The existence of that CG-NAT box is a thorn in every
provider's side and every provider that has one wants to make it
go away as quickly as possible.   ":

    The feeling and desire are undeniable facts. However, the
existing configuration was evolved from various considerations
through a long time. There is a tremendous inertia accumulated on
it. There is no magic bullet to get rid of it quickly. We must
study carefully to evolve it further incrementally. Otherwise, an
even bigger headache or disaster will happen.

2) "  The quickest and most straightforward way to eliminate the
need for any CG-NAT is to move to a bigger address space.  ":

    The obvious answer was IPv6. However, its performance after
near two decades of deployment has not been convincing. EzIP is an
alternative, requiring hardly any development, to address this
need immediately.

3) "  Until the cost (or pain) to stay on IPv4 is greater than the
cost to move,  we're going to see continued resistance to doing
so.   ":

    This strategy is easily said than done. It reminds me of my
system planning work for the old AT&T. At that time, Bell
Operating Companies(BOCs) could be coerced to upgrade their
facility by just gradually raising the cost of owning the old
equipment by assuming fewer would be be used, while the newer
version would cost less because growing number of deployments.
Looking at resultant financial forecast, the BOC decisions were
easy. Originally trained as a hardware radio engineer, I was
totally stunned. But, it worked well under the regulated monopoly
environment.

    Fast forward by half a century, the Internet promotes
distributed approaches. Few things can be controlled by limited
couple parties. The decision of go or no-go is made by parties in
the field who have their own respective considerations.
Accum

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block


Hi, Warren:

1)    "  not intended to be endorsement…":

    Fully agreed.

2)    "Implying that it is is disingenuous…   ":

    Again, I fully agree.

3)    Note that I only stated "It opened our eyes about what were the 
implications of EzIP ...   ". It was an education moment that was more 
than we could expect.



Regards,


Abe (2024-01-15 17:04)




On 2024-01-13 19:50, Warren Kumari wrote:





On Sat, Jan 13, 2024 at 9:48 AM, Tom Beecher  wrote:

Vint told you the same thing other people have been telling you
for years. You don't seem to name drop anyone else. Weird.



Indeed — Vint made an observation, but this was not intended to be 
endorsement…


Implying that it is is disingenuous…

W


Respectfully, you have no credibility in this area. I happened to
notice this gem re-reading your draft last night,

A.1.1. T1a Initiates a Session Request towards T4a

T1a sends a session request to SPR4 that serves T4a by a plain IP
packet with header as in Figure 5, to RG1. There is no TCP port
number in this IP header yet.


That's a curious statement there at the end. Let's continue though.

A.1.2. RG1 Forwards the Packet to SPR1

  RG1, allowing be masqueraded by T1a, relays the packet toward SPR1
by assigning the TCP Source port number, 3N, to T1a, with a header 
as
in Figure 6,. Note that the suffix "N" denotes the actual TCP port
number assigned by the RG1's RG-NAT. This could assume multiple
values, each represents a separate communications session that T1a 
is
engaged in. A corresponding entry is created in the RG1 state table
for handling the reply packet from the Destination site. Since T4a's
TCP port number is not known yet, it is filled with all 1's.

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1 |Version|IHL (6)|Type of Service|   Total Length (24)   
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2 |Identification |Flags| Fragment Offset 
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3 | Time to Live  |Protocol   |Header Checksum
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4 |  Source Host Number (240.0.0.0)   
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  5 |   Destination Host Number (69.41.190.148) 
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  6 |   Source Port (3N)|   Destination Port (All 1's)  
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Figure 6  TCP/IP Header: From RG1 to SPR1


Wait a second.. what is a 'TCP/IP header'?

A.1.5. T4a Replies to SPR4

T4a interchanges the Source and Destination identifications in the
incoming TCP/IP packet to create a header as in Figure 9, for the
reply packet to SPR4.

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1 |Version|IHL (6)|Type of Service|   Total Length (24)   
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2 |Identification |Flags| Fragment Offset 
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3 | Time to Live  |Protocol   |Header Checksum
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4 |  Source Host Number (240.0.0.10)  
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  5 |   Destination Host Number (69.41.190.110) 
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  6 |  Source Port (10C)| Destination Port (0C) 
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Figure 9  TCP/IP Header: From T4a to SPR4


Oh my.. you actually meant it.

The draft authors don't appear to understand that TCP headers and
IP headers **are not the same thing**.

I would suggest reviewing RFC 791 ( IPv4 ) , and RFC 793 / 9293 (
TCP, original and

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block


Hi, Forrest:

1)    I have a question:

    If I subscribe to IPv6, can I contact another similar subscriber to 
communicate (voice and data) directly between two homes in private like 
the dial-up modem operations in the PSTN? If so, is it available 
anywhere right now?


Regards,


Abe (2024-01-15 15:20)



Let me start with I think we're largely on the same page here.

The transition I see happening next is that the consumer traffic 
largely moves to IPv6 with no CG-NAT.  That is, if you're at home or 
on your phone watching video or doing social media or using whatever 
app is all the rage it's going to be over IPv6.


My point was largely that I believe that at some point the big 
consumer (not business) focused companies are going to realize they 
can use market forces to encourage the remaining IPv4-only eyeball 
networks to transition to support IPv6 connections from their 
customers.  I don't know if the timeframe is next year or 20 years 
from now,  but I do know the tech companies are very good at looking 
at the costs of maintaining backwards compatibility with old tech and 
figuring out ways to shed those costs when they no longer make sense. 
If they can utilize various forms of pressure to make this happen 
quicker, I fully expect them to do so.


Inside a business network,  or even at home,  it wouldn't surprise me 
if we're both long gone before IPv4 is eradicated.   I know there is 
going to be a lot of IPv4 in my network for years to come just because 
of product lifecycles.


As far as "CG-NAT-like" technologies go (meaning NAT in a provider's 
network), they're unfortunately going to be with us for a long time 
since customers seem to want to be able to reach everything regardless 
of the IPv4 or IPv6 status of the customer or endpoint.   I also 
expect that most service providers with business customers are going 
to be carrying both IPv4 and IPv6 for a long time, not to mention 
doing a fair bit of translation in both directions.


I won't go deeply into the whole IPv4 vs IPv6 discussion for a 
business customer's "public address" because the topic is far too 
nuanced for an email to cover them accurately.   Suffice it to say 
that I don't disagree that business today largely wants IPv4, but some 
seem to be becoming aware of what IPv6 can do and are looking to have 
both options available to them, at least outside the firewall.


On Sat, Jan 13, 2024, 2:04 AM Brett O'Hara  wrote:

Ok you've triggered me on your point 2.  I'll address the elephant
in the room.

IPv4 is never ever going away.

Right now consumer services are mostly (mobile, wireless,
landline, wide generalization) are IPv6 capable.  Most consumer
applications are ipv6 capable, Google, Facebook, etc.There is
light at the very end of the tunnel that suggests that one day we
won't have to deploy CGNAT444 for our consumers to get to content,
we may only have to do NAT64 for them to get to the remaining Ipv4
Internet.  We're still working hard on removing our reliance on
genuine ipv4 ranges to satisfy our customer needs, It's still a
long way off, but it's coming.

Here's the current problem.  Enterprise doesn't need ipv6 or want
ipv6.  You might be able to get away with giving CGNAT to your
consumers, but your enterprise customer will not accept this. How
will they terminate their remote users?  How will they do B2B with
out inbound NAT?  Yes, there are solutions, but if you don't need
to, why?  They pay good money, why can't they have real ipv4?  All
their internal networks are IPv4 rfc1918.  They are happy with
NAT.  Their application service providers are ipv4 only. Looking
at the services I access for work things like SAP, SerivceNow,
Office386, Sharepoint, Okta, Dayforce, Xero, and I'm sure many
more, none can not be accessed on ipv6 alone..  Their internal
network lifecycle is 10+ years.  They have no interest in trying
new things or making new technology work without a solid financial
reason and there is none for them implementing ipv6.   And guess
where all the IP addresses we're getting back from our consumers
are going?  Straight to our good margin enterprise customers and
their application service providers.  Consumer CGNAT isn't solving
problems, it's creating more.

The end of IPv4 isn't nigh, it's just privileged only.

PS When you solve that problem in 50 years time, I'll be one of
those old fogey's keeping an IPv4 service alive as an example of
"the old Internet" for those young whippersnappers to be amazed by.

Regards,
   Brett



--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: Searching for technical contact at Aptum AS13768

2024-01-15 Thread Tom Samplonius



  I have good success with nsc.global@  

  The last email I’ve received from them was Dec 12, 2023, and they typically 
respond in two days or less.


Tom


> On Jan 15, 2024, at 11:49 AM, Eric Dugas via NANOG  wrote:
> 
> Hello,
> 
> I'm searching for a technical contact, either Ops or Eng at Aptum AS13768 to 
> remove stale route objects created by their NOC from IRR(s).
> 
> Contacting their nsc.global@ group yielded no response at all.
> 
> Thanks
> Eric

Searching for technical contact at Aptum AS13768

2024-01-15 Thread Eric Dugas via NANOG

Hello,

I'm searching for a technical contact, either Ops or Eng at Aptum AS13768
to remove stale route objects created by their NOC from IRR(s).

Contacting their nsc.global@ group yielded no response at all.

Thanks
Eric

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

2024-01-15 Thread Jay Hennigan


On 1/15/24 09:37, Abraham Y. Chen wrote:

2)    Allow me to share with you an almost parallel event in the PSTN, 
to illustrate how tough is to achieve the replacement of a working 
service, even under an environment with very strict backward 
compatibility disicpline:


     A.    The Decadic (rotary) Dialing (DD) technique worked well on 
the telephone loop to a certain limit of distance for many years that 
enabled the automatic telephone switching systems. But, it could not go 
beyond the CO (Central Office).


     B.    So, Bell Labs studied the use of DTMF (Dual Tone 
Multi-Frequency) or commonly known as Touch-Tone as trademarked in US, 
etc. The work started in mid 1940s.


Actually, Bell had a multifrequency interoffice signaling system long 
before Touch-Tone was introduced to the public. Many of us old-timers 
were *very* familiar with this, much to the discontent of the Bell System.


     F.    Initially, AT&T offered the DTMF service for free (well, 
covered by the rental of the new phone) to encourage that adoption. 
Then, they raised the monthly service rate for lines still requiring DD 
receiver hoping to gracefully forcing the subscribes to wean from using 
DD phones.


In the early days of deployment, DTMF was not free. It was typically $1 
more per month. IIRC, there was at one time an upcharge for 12-button 
vs. 10-button Touch-Tone pads. I have never seen a tariff with an 
upcharge for pulse dialing.


     G.    Guess what, the inertia of the huge DD phones out there in 
the field accumulated through near one century made the strategy 
impossible. That is, many subscribers would rather to pay one extra 
dollar or so a month to enjoy having the old DD phone around, either to 
avoid paying a new DTMF phone or just for the antique look of the DD 
phone. This also created a nightmare of three types (DD, DTMF and 
combined) line cards in the CO.


With step-by-step, XY, or panel offices the DTMF receiver was an add-on 
that buffered the digits and outpulsed them at rotary dial speed. Pulse 
dialing always worked. Crossbar was also an add-on but with a crossbar 
marker the delay of converting to pulse was avoided. By the time ESS 
came around both pulse and DTMF were built in.


Again, when and where was there ever an upcharge for pulse dialing?

     H.    As this went on, a version of phone with DTMF dial pad but 
sending out DD pulses appeared on the open market (thanks to the 
deregulation / break up the Bell System). Such novelty phones really 
gave phone companies a hard time about the transition plan.


The purpose of these phones was actually the opposite. It allowed a 
"modern" keypad-equipped phone to function on older lines not equipped 
with a Touch-Tone receiver. In GTE territory with Strowger switching, 
the digits from DTMF phones were buffered in the CO and outpulsed as 
rotary dialing. Bang out the number with Touch-Tone and you could hear 
the tick-tick of the digits being sent while you waited.


These days people get upset with post-dial delay of more than a couple 
of seconds. It used to be substantially more, especially with 
interoffice calls.


     I.    In the meantime, IC technology advanced to have single chip 
capable of both dialing techniques (even further integrated other 
traditional line card functions onto the same chip) making the 
transition plan moot.


TTBOMK, every common BORSCHT chip accepts both.

     J    Nowadays, almost every line card type chip handles DTMF as 
advertised. But, if you try a DD phone on it, chances are, it works anyway!


Yes, because TTBOMK, telco central offices have always accepted pulse 
dialing and still do. SIP ATAs, on the other hand, mostly don't, with 
the exception of some older Grandstream units.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

2024-01-15 Thread Michael Thomas




On 1/15/24 12:26 AM, Saku Ytti wrote:

On Mon, 15 Jan 2024 at 10:05, jordi.palet--- via NANOG  wrote:


In actual customer deployments I see the same levels, even up to 85% of IPv6 
traffic. It basically depends on the usage of the caches and the % of 
residential vs corporate customers.

You think you are contributing to the IPv6 cause, by explaining how
positive the situation is. But in reality you are damaging it greatly,
because you're not communicating that we are not on a path to IPv4
free Internet. If we had been on such a path, we would have been IPv4
free for more than a decade. And unless we admit we are not on that
path, we will not work to get on that path.

An ipv4 free network would be nice, but is hardly needed. There will 
always be a long tail of ipv4 and so what? You deal with it at your 
borders as a piece of non-recurring engineering and that is that. The 
mobile operators model seems to be working pretty well for them and 
seems likely that it is an opex cost down for them since they don't have 
to run two networks internally nor deal with the cost of ipv4 subnets 
(or at least not as much? not sure how it exactly works). Worrying about 
whether ipv4 will ever go away misses the point, imo.


Mike

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread Mel Beckman

My sarcasm generator is clearly set incorrectly :)

 -mel

> On Jan 15, 2024, at 10:33 AM, Jay Hennigan  wrote:
> 
> On 1/15/24 07:21, Mel Beckman wrote:
>> Easy. Climate change. Lol!
> 
> It was -8°F in Chicago yesterday.
> 
 On Jan 15, 2024, at 7:17 AM, sro...@ronan-online.com wrote:
>>> 
>>> 
>>> I’m more interested in how you lose six chillers all at once.
> 
> 
> -- 
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

2024-01-15 Thread Michael Thomas




On 1/15/24 12:56 AM, jordi.palet--- via NANOG wrote:
No, I’m not saying that. I’m saying "in actual deployments", which 
doesn’t mean that everyone is deploying, we are missing many ISPs, we 
are missing many enterprises.


I don't think what's going on internally with enterprise needs to change 
much if they just gatewayed to a v6 upstream instead of v4 at the border 
if they were given that option. The problem has always been with ISP's 
and routers. When v6 first started to percolate (early 90's) i looked at 
it for my embedded OS and the projects that used it and didn't figure it 
would take much effort to implement it. So for hosts i really don't 
think that was a roadblock. But if hosts don't have something upstream 
to sink v6 traffic and especially to access the public internet there's 
not much incentive to implement it or deploy it. ISP's used the excuse 
that routers didn't implement it which was definitely a huge problem but 
as it turns out it was still an excuse since a lot has changed in the 
last 20 years and still rollout continues at a glacial pace.


I think one of the more encouraging trends are ISP's and enterprises 
switching over to v6 internally as a cost saving measure to not run a 
dual network. Aren't Comcast and Facebook examples?


It's sort of disturbing that there are still people on this list that 
want to relitigate something that happened 30 years ago. that reeks of 
religion not tech. By all means, set up CGNAT's in a pique.


Mike

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread Jay Hennigan


On 1/15/24 10:37, Pennington, Scott wrote:
yes but it has been -8 in Chicago plenty of times before this.  
  Very interested in root cause...


Absolutely. My point was that claiming "Global warming" isn't going to 
fly as an excuse.




*From:* NANOG  on 
behalf of Jay Hennigan 

*Sent:* Monday, January 15, 2024 1:31 PM
*To:* nanog@nanog.org 
*Subject:* Re: "Hypothetical" Datacenter Overheating
On 1/15/24 07:21, Mel Beckman wrote:

Easy. Climate change. Lol!


It was -8°F in Chicago yesterday.


On Jan 15, 2024, at 7:17 AM, sro...@ronan-online.com wrote:


I’m more interested in how you lose six chillers all at once.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread Jay Hennigan


On 1/15/24 07:21, Mel Beckman wrote:

Easy. Climate change. Lol!


It was -8°F in Chicago yesterday.


On Jan 15, 2024, at 7:17 AM, sro...@ronan-online.com wrote:


I’m more interested in how you lose six chillers all at once.



--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block


Hi, Christopher"

1)    "  IPv6 is designed to replace IPv4.  ":

    Correct. But, this is not like Ten Commandments that God gave to 
his children. Even such had not worked out in most cases. In real life, 
technical backward compatibility is the only known approach to achieve 
graceful replacement of the old. Failing to observe such discipline, one 
should not blame others for the disappointment in the transition. I am 
an outsider to the Internet development history. But, the overall 
appearance at this moment is that somehow IPv6 design failed to properly 
execute the backward compatibility requirement. So, IPv6 replacing IPv4 
is not given.


2)    Allow me to share with you an almost parallel event in the PSTN, 
to illustrate how tough is to achieve the replacement of a working 
service, even under an environment with very strict backward 
compatibility disicpline:


    A.    The Decadic (rotary) Dialing (DD) technique worked well on 
the telephone loop to a certain limit of distance for many years that 
enabled the automatic telephone switching systems. But, it could not go 
beyond the CO (Central Office).


    B.    So, Bell Labs studied the use of DTMF (Dual Tone 
Multi-Frequency) or commonly known as Touch-Tone as trademarked in US, 
etc. The work started in mid 1940s.


    c.    By late 1960s, working demos became available. During the 
mid-1970s, it was deployed across the Bell System (and beyond upon 
requests from other countries).


    D.    With end-to-end signally capability of the DTMF signalling, a 
lot of services such as remote purchase, airline status checking , 
etc.,grew drastically.


    E.    However, DTMF was a complete technology from Decadic Dialing 
and most phones in the field were still the latter type. COs had to 
install dual function line cards on the loop that subscriber liked to 
enjoy the DTMF capability. Obviously, the dual function line cards 
costed more than that of the basic DD version.


    F.    Initially, AT&T offered the DTMF service for free (well, 
covered by the rental of the new phone) to encourage that adoption. 
Then, they raised the monthly service rate for lines still requiring DD 
receiver hoping to gracefully forcing the subscribes to wean from using 
DD phones.


    G.    Guess what, the inertia of the huge DD phones out there in 
the field accumulated through near one century made the strategy 
impossible. That is, many subscribers would rather to pay one extra 
dollar or so a month to enjoy having the old DD phone around, either to 
avoid paying a new DTMF phone or just for the antique look of the DD 
phone. This also created a nightmare of three types (DD, DTMF and 
combined) line cards in the CO.


    H.    As this went on, a version of phone with DTMF dial pad but 
sending out DD pulses appeared on the open market (thanks to the 
deregulation / break up the Bell System). Such novelty phones really 
gave phone companies a hard time about the transition plan.


    I.    In the meantime, IC technology advanced to have single chip 
capable of both dialing techniques (even further integrated other 
traditional line card functions onto the same chip) making the 
transition plan moot.


    J    Nowadays, almost every line card type chip handles DTMF as 
advertised. But, if you try a DD phone on it, chances are, it works anyway!


    K. You may see some parallelism between the above and the current 
IPv4 / IPv6 transition issues.



Regards,


Abe (2024-01-15 12:37)




On 2024-01-15 00:15, Christopher Hawker wrote:
To my knowledge IPv6 is designed to replace IPv4. Anyone, feel free to 
correct me if I'm wrong. There are just short of 4.3 billion IPv4 
addresses, where the number of IPv6 addresses is 39 digits long.


Regards,
Christopher Hawker

On Mon, 15 Jan 2024 at 15:18, Abraham Y. Chen  wrote:

Hi, Randy:

1)   " ... unfortunately i already had grey hair in the '90s and
was in the room for all this, ...  ":

    My apologies! For an uninitiated, I misread your message as if
IPv6 was originally designed with a plan to assure smooth
transition from IPv4.

Regards,


Abe (2024-01-14 23:17)


On 2024-01-12 17:45, Randy Bush wrote:

Perhaps you are too young to realize that the original IPv6 plan was
not designed to be backward compatible to IPv4, and Dual-Stack was
developed (through some iterations) to bridge the transition between
IPv4 and IPv6? You may want to spend a few moments to read some
history on this.

ROFL!!!  if there is anything you can do to make me that young, you
could have a very lucrative career outside of the internet.

hint: unfortunately i already had grey hair in the '90s and was in the
room for all this, and spent a few decades managing to get some of the
worst stupidities (TLA, NLA, ...) pulled out of the spec.  at iij, we
rolled ipv6 on the backbone in 1997.

randy

Re: Contact at GoDaddy domains

2024-01-15 Thread Daniel Marks via NANOG

Sending a letter to their legal department has always worked to get any issue solved for us, that’s pretty much the only success we’ve ever had with escalations before we promptly move the domain as far away from them as possible.Sent from my iPhoneOn Jan 15, 2024, at 11:08, Greg Joosse - MySupport IT  wrote:Hoping someone has a contact at GoDaddy (Domains) as I have a big client with a clientHold 30 day suspension and their support doesn't seem to know what this means.Have spend 7hrs and have got nowhere. Failing this, is it possible to transfer a domain with this status?Cheers,Greg


This electronic message together with any attachments is for exclusive and confidential use of the intended recipient(s).  If you are not the intended recipient, any use, disclosure or copying of this material is unauthorised and prohibited. If you have received this message in error, please notify i...@mysupport.com.au by return e-mail immediately and delete the message from your computer without making any copies.

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


Hi, Christopher:

1)    " Hang on... So EzIP is now about using 240/4 as CGNAT space? 
Wait, I'm lost...   ":


    Correct. This is one way to visualize the EzIP deployment. This 
configuration is so far the most concise manner to describe the the EzIP 
building block, RAN (Regional Area Network). The nice thing about this 
approach is that everything exists and is already working daily in each 
CG-NAT cluster. All needed to expand its capability is a larger 
netblock. Since 240/4 is fundamentally not an outlier in the overall 
IPv4 address pool, except being classified as "Reserved" for a long 
time, enabling it to work in a CG-NAT should not be any big challenge.


2)    "   ... There is no such thing as "semi-private" space in the 
world of CGNAT, ... ":


    Correct. However, not distinguishing 100.64/10 netblock from the 
common public and private parts of the IPv4 space made it vague as which 
function does it provide. That is, in terms of re-usability for each 
isolated geographical area, it is like another RFC1918 private netblock. 
On the other hand, CG-NAT is clearly used in geographically public 
areas. So, 100.64/10 should be classified as "public". In addition, 
100.64/10 is listed according to "IANA IPv4 Address Space Registry" as 
part of the 100/8 netblock under ARIN, but now used by everyone 
worldwide. To avoid similar ambiguity that leads to confusions, we 
decided to call 240/4 as "semi-public" to more explicitly convey the 
concept. (Actually, we initially called 240/4 "semi-private" thinking 
that it could be the fourth RFC1918 netblock, until we realized that the 
RFC6589 environment was a much better fit.)


3)    " Your "solution" to residential gateways not supporting the use 
of 240/4 space being upgraded to OpenWrt won't work, because not all CPE 
supports OpenWrt.   ":


    OpenWrt is just an open source RG code that can replace that in 
commercial RGs that have been supporting CPEs. Like the EzIP concept, 
the OpenWrt upgrade of RG-NAT is an enhancement to the existing RG 
functionality. Thus, OpenWrt enabled RGs can operate with the 
combination of public (including RFC6589) with 240/4 netblocks on the 
upstream (WAN) side, and private (RFC1918) with 240/4 netblocks on the 
downstream (LAN) side. So, there is no compatibility change that a CPE 
(on-premises IoT) can sense. This critical characteristics was the 
result of an OpenWrt core code upgrade in 2019 contributed by Dave Taht 
of "IPv4 Unicast Extensions Project". Before that, EzIP was just a 
theoretically feasible scheme.


4)    In addition, OpenWrt at least works with one network router by 
D-Link (see URL below). This means that, with both WAN and LAN sides of 
a router supporting 240/4, a beginner's reference RAN can be built and 
experimented with it:


https://us.dlink.com/en/products/dgs-1210-28-28-port-gigabit-smart-managed-switch

5)    " Instead of attempting to use a larger prefix for CGNAT, IPv6 is 
definitely the easier solution to implement as the vast majority of 
vendors already support v6. ":


    Since the general consensus is that for moving ahead, we will rely 
on Dual-Stack to bridge IPv6 and IPv4 worlds enabling them to coexist 
for the foreseeable future, it would more expedient for the community as 
a whole, if we could focus on technical discussions for each camp 
respectively, while minimizing invitation messages from the other side. 
I hope you do agree.


Regards,


Abe (2024-01-15 11:27)



On 2024-01-15 00:09, Christopher Hawker wrote:
Hang on... So EzIP is now about using 240/4 as CGNAT space? Wait, I'm 
lost...


With CGNAT, there is either public IP space in front of the gateway, 
or private space behind it. There is no such thing as "semi-private" 
space in the world of CGNAT, as devices with public IPs can't directly 
access devices behind a CGNAT gateway with a 100.64/10 address. It's 
either a public address, or a private address (not to be confused with 
an RFC1918 private address).


Let's talk hypothetically for a minute and assume that 240/4 is used 
as CGNAT space. Your "solution" to residential gateways not supporting 
the use of 240/4 space being upgraded to OpenWRT won't work, because 
not all CPE supports OpenWRT.


Instead of attempting to use a larger prefix for CGNAT, IPv6 is 
definitely the easier solution to implement as the vast majority of 
vendors already support v6.


Regards,
Christopher Hawker

On Mon, 15 Jan 2024 at 15:06, Abraham Y. Chen  wrote:

Hi, Mike:

1)   "... only private use. ...":

    The EzIP deployment plan is to use 240/4 netblock as
"Semi-Public" addresses for the existing CG-NAT facility. With
many RG-NATs (Routing / Residential Gateway -NATs) already capable
of being 240/4 clients thru the upgrade to OpenWrt, no IoT on any
private premises will sense any change.

Regards,


Abe (2024-01-14 23:04)


On 2024-01-12 15:16, Mike Hammett wrote:

I'm not talking about global, public use, only private u

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

2024-01-15 Thread Brian Knight via NANOG


On 2024-01-13 04:03, Brett O'Hara wrote:

They have no interest in trying new things or making new technology 
work without a solid financial reason and there is none for them 
implementing ipv6.


When I left $DAYJOB-1 almost 2 years ago, they had just finished 
increasing fees on IPv4 blocks (larger than /29) that had already been 
assigned to customers.


This wasn't on new assignments only. It was applied to all Internet 
customers with /28 and larger assignments that were already assigned and 
working at the time of the increase.


I know $DAYJOB-1 weren't alone in the NSP industry.

Also, one very large cloud provider I use for personal projects is 
charging additional fees for IPv4 starting this year. My cost for (3) 
IPv4 addresses went from zero to $10.80/mo/ip, jacking up my bill about 
20%. These were IPs assigned to my services 6-7 years ago.


There is a financial reason looming. I grant you that, at the moment, it 
may still be low enough to be considered "cost of doing business" for 
nearly all enterprises. But it's exerting force like a glacier does; 
slowly, irregularly, yet inexorably; so it can be difficult to see.


-Brian

Contact at GoDaddy domains

2024-01-15 Thread Greg Joosse - MySupport IT

Hoping someone has a contact at GoDaddy (Domains) as I have a big client
with a clientHold 30 day suspension and their support doesn't seem to know
what this means.

Have spend 7hrs and have got nowhere. Failing this, is it possible to
transfer a domain with this status?

Cheers,

Greg

-- 
This electronic message together with any attachments is for exclusive and 
confidential use of the intended recipient(s).  If you are not the intended 
recipient, any use, disclosure or copying of this material is unauthorised 
and prohibited. If you have received this message in error, please notify 
*i...@mysupport.com.au * by return e-mail 
immediately and delete the message from your computer without making any 
copies.

Re: "Hypothetical" Datacenter Overheating

Exactly. Perhaps they weren’t all online to begin with…On Jan 15, 2024, at 10:18 AM, Mike Hammett  wrote:and none in the other two facilities you operate in that same building had any failures.-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISPFrom: sro...@ronan-online.comTo: "Mike Hammett" Cc: "NANOG" Sent: Monday, January 15, 2024 9:14:49 AMSubject: Re: "Hypothetical" Datacenter OverheatingI’m more interested in how you lose six chillers all at once.ShaneOn Jan 15, 2024, at 9:11 AM, Mike Hammett  wrote:Let's say that hypothetically, a datacenter you're in had a cooling failure and escalated to an average of 120 degrees before mitigations started having an effect. What are normal QA procedures on your behalf? What is the facility likely to be doing? What  should be expected in the aftermath?-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread Mel Beckman

Easy. Climate change. Lol!

 -mel

On Jan 15, 2024, at 7:17 AM, sro...@ronan-online.com wrote:


I’m more interested in how you lose six chillers all at once.

Shane

On Jan 15, 2024, at 9:11 AM, Mike Hammett  wrote:


Let's say that hypothetically, a datacenter you're in had a cooling failure and 
escalated to an average of 120 degrees before mitigations started having an 
effect. What are normal QA procedures on your behalf? What is the facility 
likely to be doing? What  should be expected in the aftermath?



-
Mike Hammett
Intelligent Computing Solutions
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
Midwest Internet Exchange
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
The Brothers WISP
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png]

Re: "Hypothetical" Datacenter Overheating

and none in the other two facilities you operate in that same building had any 
failures. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: sro...@ronan-online.com 
To: "Mike Hammett"  
Cc: "NANOG"  
Sent: Monday, January 15, 2024 9:14:49 AM 
Subject: Re: "Hypothetical" Datacenter Overheating 



I’m more interested in how you lose six chillers all at once. 


Shane 



On Jan 15, 2024, at 9:11 AM, Mike Hammett  wrote: 







Let's say that hypothetically, a datacenter you're in had a cooling failure and 
escalated to an average of 120 degrees before mitigations started having an 
effect. What are normal QA procedures on your behalf? What is the facility 
likely to be doing? What should be expected in the aftermath? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP

Re: "Hypothetical" Datacenter Overheating

I’m more interested in how you lose six chillers all at once.ShaneOn Jan 15, 2024, at 9:11 AM, Mike Hammett  wrote:Let's say that hypothetically, a datacenter you're in had a cooling failure and escalated to an average of 120 degrees before mitigations started having an effect. What are normal QA procedures on your behalf? What is the facility likely to be doing? What  should be expected in the aftermath?-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread Jason Canady

Our Zayo circuit just came up 30 minutes ago and it routes through 350 E 
Cermak.  Chillers were all messed up.  No hypothetical there.  :-) It 
was down for over 16 hours!

On 1/15/24 10:04 AM, Bryan Holloway wrote:

I think we're beyond "hypothetical" at this point, Mike ... ;)

On 1/15/24 15:49, Mike Hammett wrote:

Coincidence indeed   ;-)

-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

*From: *"Clayton Zekelman" 
*To: *"Mike Hammett" , "NANOG" 
*Sent: *Monday, January 15, 2024 8:23:37 AM
*Subject: *Re: "Hypothetical" Datacenter Overheating

At 09:08 AM 2024-01-15, Mike Hammett wrote:
 >Let's say that hypothetically, a datacenter you're in had a cooling
 >failure and escalated to an average of 120 degrees before
 >mitigations started having an effect. What are normal QA procedures
 >on your behalf? What is the facility likely to be doing?
 >What  should be expected in the aftermath?

One would hope they would have had disaster recovery plans to bring
in outside cold air, and have executed on it quickly, rather than
hoping the chillers got repaired.

All our owned facilities have large outside air intakes, automatic
dampers and air mixing chambers in case of mechanical cooling
failure, because cooling systems are often not designed to run well
in extreme cold.  All of these can be manually run incase of controls
failure, but people tell me I'm a little obsessive over backup plans
for backup plans.

You will start to see premature failure of equipment over the coming
weeks/months/years.

Coincidentally, we have some gear in a data centre in the Chicago
area that is experiencing that sort of issue right now... :-(

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread Bryan Holloway

I think we're beyond "hypothetical" at this point, Mike ... ;)

On 1/15/24 15:49, Mike Hammett wrote:

Coincidence indeed   ;-)

-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

*From: *"Clayton Zekelman" 
*To: *"Mike Hammett" , "NANOG" 
*Sent: *Monday, January 15, 2024 8:23:37 AM
*Subject: *Re: "Hypothetical" Datacenter Overheating

At 09:08 AM 2024-01-15, Mike Hammett wrote:
 >Let's say that hypothetically, a datacenter you're in had a cooling
 >failure and escalated to an average of 120 degrees before
 >mitigations started having an effect. What are normal QA procedures
 >on your behalf? What is the facility likely to be doing?
 >What  should be expected in the aftermath?

One would hope they would have had disaster recovery plans to bring
in outside cold air, and have executed on it quickly, rather than
hoping the chillers got repaired.

All our owned facilities have large outside air intakes, automatic
dampers and air mixing chambers in case of mechanical cooling
failure, because cooling systems are often not designed to run well
in extreme cold.  All of these can be manually run incase of controls
failure, but people tell me I'm a little obsessive over backup plans
for backup plans.

You will start to see premature failure of equipment over the coming
weeks/months/years.

Coincidentally, we have some gear in a data centre in the Chicago
area that is experiencing that sort of issue right now... :-(

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread William Herrin

On Mon, Jan 15, 2024 at 6:08 AM Mike Hammett  wrote:
> Let's say that hypothetically, a datacenter you're in had a cooling failure
> and escalated to an average of 120 degrees before mitigations started
> having an effect. What  should be expected in the aftermath?

Hi Mike,

A decade or so ago I maintained a computer room with a single air
conditioner because the boss wouldn't go for n+1. It failed in exactly
this manner several times. After the overheat was detected by the
monitoring system, it would be brought under control with a
combination of spot cooler and powering down to a minimal
configuration. But of course it takes time to get people there and set
up the mitigations, during which the heat continues to rise.

The main thing I noticed was a modest uptick in spinning drive
failures for the couple months that followed. If there was any other
consequence it was at a rate where I'd have had to be carefully
measuring before and after to detect it.

Regards,
Bill Herrin

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

Re: "Hypothetical" Datacenter Overheating

Coincidence indeed ;-) 

- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Clayton Zekelman"  
To: "Mike Hammett" , "NANOG"  
Sent: Monday, January 15, 2024 8:23:37 AM 
Subject: Re: "Hypothetical" Datacenter Overheating 

At 09:08 AM 2024-01-15, Mike Hammett wrote: 
>Let's say that hypothetically, a datacenter you're in had a cooling 
>failure and escalated to an average of 120 degrees before 
>mitigations started having an effect. What are normal QA procedures 
>on your behalf? What is the facility likely to be doing? 
>What should be expected in the aftermath? 

One would hope they would have had disaster recovery plans to bring 
in outside cold air, and have executed on it quickly, rather than 
hoping the chillers got repaired. 

All our owned facilities have large outside air intakes, automatic 
dampers and air mixing chambers in case of mechanical cooling 
failure, because cooling systems are often not designed to run well 
in extreme cold. All of these can be manually run incase of controls 
failure, but people tell me I'm a little obsessive over backup plans 
for backup plans. 

You will start to see premature failure of equipment over the coming 
weeks/months/years. 

Coincidentally, we have some gear in a data centre in the Chicago 
area that is experiencing that sort of issue right now... :-(

Re: "Hypothetical" Datacenter Overheating

2024-01-15 Thread Clayton Zekelman






At 09:08 AM 2024-01-15, Mike Hammett wrote:
Let's say that hypothetically, a datacenter you're in had a cooling 
failure and escalated to an average of 120 degrees before 
mitigations started having an effect. What are normal QA procedures 
on your behalf? What is the facility likely to be doing? 
What  should be expected in the aftermath?


One would hope they would have had disaster recovery plans to bring 
in outside cold air, and have executed on it quickly, rather than 
hoping the chillers got repaired.


All our owned facilities have large outside air intakes, automatic 
dampers and air mixing chambers in case of mechanical cooling 
failure, because cooling systems are often not designed to run well 
in extreme cold.  All of these can be manually run incase of controls 
failure, but people tell me I'm a little obsessive over backup plans 
for backup plans.


You will start to see premature failure of equipment over the coming 
weeks/months/years.


Coincidentally, we have some gear in a data centre in the Chicago 
area that is experiencing that sort of issue right now... :-(

"Hypothetical" Datacenter Overheating

Let's say that hypothetically, a datacenter you're in had a cooling failure and 
escalated to an average of 120 degrees before mitigations started having an 
effect. What are normal QA procedures on your behalf? What is the facility 
likely to be doing? What should be expected in the aftermath? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block


Hi, Tom:

1)    "  Vint told you the same thing other people have been telling you 
for years. You don't seem to name drop anyone else. Weird.   ":


    As far as we are aware of, Vint was the first and only person who 
branded EzIP as an "overlay" network. Please identify who else said the 
same. Such characterization opened our eyes, so that we carried on. I 
did not dare to consider it was an endorsement as some colleagues are 
now implying.


2)   "  Wait a second.. what is a 'TCP/IP header'?   ":

    Thanks for pointing this out. We made a conscious decision to 
include only the relevant element of the TCP/IP header in the EzIP 
header diagrams because the need to keep its size down to avoid 
occupying too much paper space when repeating the diagram through 
various steps between two ends, with minor change at each step.



Regards,


Abe (2024-01-15 08:07)




On 2024-01-13 09:48, Tom Beecher wrote:
Vint told you the same thing other people have been telling you for 
years. You don't seem to name drop anyone else. Weird.


Respectfully, you have no credibility in this area. I happened to 
notice this gem re-reading your draft last night,


A.1.1. T1a Initiates a Session Request towards T4a

T1a sends a session request to SPR4 that serves T4a by a plain IP
packet with header as in Figure 5, to RG1. There is no TCP port
number in this IP header yet.


That's a curious statement there at the end. Let's continue though.

A.1.2. RG1 Forwards the Packet to SPR1

  RG1, allowing be masqueraded by T1a, relays the packet toward SPR1
by assigning the TCP Source port number, 3N, to T1a, with a header as
in Figure 6,. Note that the suffix "N" denotes the actual TCP port
number assigned by the RG1's RG-NAT. This could assume multiple
values, each represents a separate communications session that T1a is
engaged in. A corresponding entry is created in the RG1 state table
for handling the reply packet from the Destination site. Since T4a's
TCP port number is not known yet, it is filled with all 1's.

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1 |Version|IHL (6)|Type of Service|   Total Length (24)   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2 |Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3 | Time to Live  |Protocol   |Header Checksum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4 |  Source Host Number (240.0.0.0)   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  5 |   Destination Host Number (69.41.190.148) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  6 |   Source Port (3N)|   Destination Port (All 1's)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Figure 6  TCP/IP Header: From RG1 to SPR1


Wait a second.. what is a 'TCP/IP header'?

A.1.5. T4a Replies to SPR4

T4a interchanges the Source and Destination identifications in the
incoming TCP/IP packet to create a header as in Figure 9, for the
reply packet to SPR4.

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1 |Version|IHL (6)|Type of Service|   Total Length (24)   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2 |Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3 | Time to Live  |Protocol   |Header Checksum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4 |  Source Host Number (240.0.0.10)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  5 |   Destination Host Number (69.41.190.110) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  6 |  Source Port (10C)| Destination Port (0C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Figure 9  TCP/IP Header: From T4a to SPR4


Oh my.. you actually meant it.

The draft authors don't appear to understand that TCP headers and IP 
headers **are not the same thing**.


I would sugg

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

I strongly disagree that IPv6 is very much an afterthought.

A perfect example is that in Australia, our largest mobile network provider
Telstra, has completely moved to IPv6 single-stack on their mobile network
for pre-paid and post-paid customers. Russell Langton made the announcement
in February 2020 that Telstra was making the transition and they have since
completed this transition. T-Mobile US also went single-stack back in 2014.
India, with a population of 1.43 billion people (accounting for 17% of the
world's population, sits at 81.24% capable, 80.71% preferred.

With a global rate of 36.49% IPv6 capable and 35.61% IPv6 preferred, we
still have a long way to go however our current achievements to-date should
be commended.

Regards,
Christopher Hawker

Links:
https://lists.ausnog.net/pipermail/ausnog/2020-February/043869.html
https://www.internetsociety.org/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/
https://stats.labs.apnic.net/ipv6

On Mon, 15 Jan 2024 at 20:09, Saku Ytti  wrote:

> On Mon, 15 Jan 2024 at 10:59, jordi.palet--- via NANOG 
> wrote:
>
> > No, I’m not saying that. I’m saying "in actual deployments", which
> doesn’t mean that everyone is deploying, we are missing many ISPs, we are
> missing many enterprises.
>
> Because of low entropy of A-B pairs in bps volume, seeing massive
> amounts of IPv6 in IPv6 enabled networks is not indicative of IPv6
> success. I don't disagree with your assertion, I just think it's
> damaging, because readers without context will form an idea that
> things are going smoothly.  We should rightly be in panic mode and
> forget all the IPv4 extension crap and start thinking how do we ensure
> IPv6 happens and how do we ensure we get back to single stack
> Internet.
>
> IPv6 is very much an afterthought, a 2nd class citizen today. You can
> deploy new features and software without IPv6, and it's fine. IPv6 can
> be broken, and it's not an all-hands-on-deck problem, no one is
> calling.
>
> --
>   ++ytti
>

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

On Mon, 15 Jan 2024 at 10:59, jordi.palet--- via NANOG  wrote:

> No, I’m not saying that. I’m saying "in actual deployments", which doesn’t 
> mean that everyone is deploying, we are missing many ISPs, we are missing 
> many enterprises.

Because of low entropy of A-B pairs in bps volume, seeing massive
amounts of IPv6 in IPv6 enabled networks is not indicative of IPv6
success. I don't disagree with your assertion, I just think it's
damaging, because readers without context will form an idea that
things are going smoothly.  We should rightly be in panic mode and
forget all the IPv4 extension crap and start thinking how do we ensure
IPv6 happens and how do we ensure we get back to single stack
Internet.

IPv6 is very much an afterthought, a 2nd class citizen today. You can
deploy new features and software without IPv6, and it's fine. IPv6 can
be broken, and it's not an all-hands-on-deck problem, no one is
calling.

-- 
  ++ytti

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

2024-01-15 Thread jordi.palet--- via NANOG

No, I’m not saying that. I’m saying "in actual deployments", which doesn’t mean 
that everyone is deploying, we are missing many ISPs, we are missing many 
enterprises.

Saludos,
Jordi

@jordipalet

> El 15 ene 2024, a las 9:26, Saku Ytti  escribió:
> 
> On Mon, 15 Jan 2024 at 10:05, jordi.palet--- via NANOG  
> wrote:
> 
>> In actual customer deployments I see the same levels, even up to 85% of IPv6 
>> traffic. It basically depends on the usage of the caches and the % of 
>> residential vs corporate customers.
> 
> You think you are contributing to the IPv6 cause, by explaining how
> positive the situation is. But in reality you are damaging it greatly,
> because you're not communicating that we are not on a path to IPv4
> free Internet. If we had been on such a path, we would have been IPv4
> free for more than a decade. And unless we admit we are not on that
> path, we will not work to get on that path.
> 
> -- 
>  ++ytti

**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block