Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Dave Taht]

On Wed, Mar 9, 2022 at 9:11 AM Tim Howe  wrote:
>
> On Wed, 9 Mar 2022 11:22:49 -0500
> Tom Beecher  wrote:
>
> > > It doesn't take any OS upgrades for "getting everything to work on
> > > IPv6".  All the OS's and routers have supported IPv6 for more than a
> > > decade.
> > >
> >
> > There are lots of vendors, both inside and outside the networking space,
> > that have consistently released products with non-existant or broken IPv6
> > implementations. That includes smaller startups, as well as very big
> > names. An affirmative choice is often made to make sure v4 works , get the
> > thing out the door, and deal with v6 later, or if a big client complains.
>
> This a thousand times.  Don't believe the claims of IPv6
> support until you have fully tested it.  Almost no vendor is including
> any IPv6 testing in their QA process and nobody is including it in any
> of their support staff training.  Their labs may not even have v6
> capability.  Some of our biggest vendors who have supposedly supported
> v6 for over a decade have rudimentary, show-stopping bugs.  The support
> staff at these vendors have often never even seen a customer using v6,
> and they have no idea what it looks like on their own gear.

I have worked really hard to make sure ipv6 "just works" (still) in
the upcoming openwrt 22.03 release, treating it as *my* primary ip
stack, at least.

But I spent most of my time fixing a string of fq-codel & ATF wifi
regressions on the mt76 chips and (especially) not on testing the
various encapsulations, and am out of time.

If y'all care about ipv6, please lean in, test, and file bugs on these
last release candidates before it goes final?

https://downloads.openwrt.org/releases/22.03.0-rc6/targets/

The network you save may be your own.
>
> A subset of these vendors will listen to you and fix the
> problems.  Give them your support and loyalty.  I want to name names so
> bad...
>
> --TimH



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

Re: Making Use of 240/4 NetBlock Re: 202203210957.AYC

[Abraham Y. Chen]

Dear John:

1)    "  ... everyone, said it's a foolish idea ... ":     Oh, 
"everyone", really? Are you sure? Please name a couple who expressed 
their judgments based on */facts/*. Otherwise, you may be fooling 
everyone with rumors to perpetuate a myth.


2)    By the way, through constructive criticism, we learned to 
characterize our EzIP as an */overlay/* network. With this very concise 
definition, EzIP is now ready to face real bullets. You may want to 
follow discussions about our work more closely.




Regards,

Abe (2022-03-21 15:36)




--
NANOG Digest, Vol 170, Issue 23
Message: 5
Date: 20 Mar 2022 13:58:18 -0400
From: "John Levine"
To:nanog@nanog.org
Cc:ayc...@avinta.com
Subject: Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC
Message-ID:<20220320175819.7c27c3976...@ary.qy>
Content-Type: text/plain; charset=utf-8

It appears that Abraham Y. Chen  said:


??? C.??? Recently, we were made aware of the Int-Area activities.
Attempts to reach the Group Chairs have not received any responses.

??? D.??? I just received an Int-Area Digest Vol 199, Issue 14
requesting IETF to reactivate the IPv4 support.


For people who don't follow the IETF lists, here's a summary of
the responses.  Mr. Chen thought it was a good idea, everyone
else, and I mean everyone, said it's a foolish idea and not
worth pursuing.

R's,
John


--


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

Re: Making Use of 240/4 NetBlock Re: 202203210955.AYC

[Abraham Y. Chen]

Hi, Randy:

Great analogy.


Regards,


Abe (2022-03-21 15:30)


--
NANOG Digest, Vol 170, Issue 23
Message: 12
Date: Mon, 21 Mar 2022 03:08:55 -0700
From: Randy Bush
To: Joe Maimon
Cc: North American Network Operators' Group
Subject: Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC
Message-ID:
Content-Type: text/plain; charset=US-ASCII


Is this is how the IETF ivory tower residents likes to try and
suppress debate


the ietf is an echo chamber; and if you are not in it, you do not
count.

https://archive.psg.com/051000.sigcomm-ivtf.pdf

randy


End of NANOG Digest, Vol 170, Issue 23
**


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

Re: Making Use of 240/4 NetBlock Re: 202203210953.AYC

[Abraham Y. Chen]

Hi, Joe:

1)    "... how the IETF ivory tower residents likes to try and suppress 
debate, ...  ":   Interesting metaphor. Along this line, I wonder 
whether those bouncers on the draw bridge realize that technology has 
advanced to the point that there are other ways to get around the road 
block, such as taking over the country side to leave the ivory tower in 
isolation, or parachuting to bypass the draw bridge?



Regards,


Abe (2022-03-21 12:34)



--
NANOG Digest, Vol 170, Issue 23
Message: 11
Date: Mon, 21 Mar 2022 05:31:50 -0400
From: Joe Maimon
To: John Levine,nanog@nanog.org
Cc:ayc...@avinta.com
Subject: Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC
Message-ID:<62384606.2030...@jmaimon.com>
Content-Type: text/plain; charset=UTF-8; format=flowed



John Levine wrote:


It appears that Abraham Y. Chen  said:

  C.Recently, we were made aware of the Int-Area activities.
Attempts to reach the Group Chairs have not received any responses.

  D.I just received an Int-Area Digest Vol 199, Issue 14
requesting IETF to reactivate the IPv4 support.

For people who don't follow the IETF lists, here's a summary of
the responses.  Mr. Chen thought it was a good idea, everyone
else, and I mean everyone, said it's a foolish idea and not
worth pursuing.

R's,
John


*ahem*
Is this is how the IETF ivory tower residents likes to try and suppress
debate, by relegating all group think dissenters as white noise
nobodies? And if they have succeeded in doing such on their own forums,
its more telling about their own process problems than anything else.

I sincerely hope I am mistaken in your characterization of the many fine
individuals who have repeatedly gone on record in support of maintaining
IPv4 responsibly until such time as it is properly obsoleted.

While I can understand being considered a nobody, other more notable
definitely not nobodies have even on this tired topics' nth thread made
themselves heard and some fairly clearly.

History will continue to show that the IETF pursued the path of pain for
the internet.

Joe




--


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

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Randy Bush]

> Is this is how the IETF ivory tower residents likes to try and
> suppress debate

the ietf is an echo chamber; and if you are not in it, you do not
count.

https://archive.psg.com/051000.sigcomm-ivtf.pdf

randy

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Joe Maimon]

John Levine wrote:

It appears that Abraham Y. Chen  said:

 C.Recently, we were made aware of the Int-Area activities.
Attempts to reach the Group Chairs have not received any responses.

 D.I just received an Int-Area Digest Vol 199, Issue 14
requesting IETF to reactivate the IPv4 support.

For people who don't follow the IETF lists, here's a summary of
the responses.  Mr. Chen thought it was a good idea, everyone
else, and I mean everyone, said it's a foolish idea and not
worth pursuing.

R's,
John


*ahem*
Is this is how the IETF ivory tower residents likes to try and suppress 
debate, by relegating all group think dissenters as white noise 
nobodies? And if they have succeeded in doing such on their own forums, 
its more telling about their own process problems than anything else.


I sincerely hope I am mistaken in your characterization of the many fine 
individuals who have repeatedly gone on record in support of maintaining 
IPv4 responsibly until such time as it is properly obsoleted.


While I can understand being considered a nobody, other more notable 
definitely not nobodies have even on this tired topics' nth thread made 
themselves heard and some fairly clearly.


History will continue to show that the IETF pursued the path of pain for 
the internet.


Joe

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Greg Skinner via NANOG]

I was referring to the relative number of responses to the most recent Schoen 
IPv4 maintenance draft at the link you gave (quoted by me), as compared to the 
responses here on the NANOG list.  Sorry if that wasn’t clear.

I would argue that Schoen and the co-authors of that draft have spent time 
researching the problem and past discussions.  For example, see the discussion 
on the internet-history list about the history of 0/8 
.

—gregbo

> On Mar 20, 2022, at 11:26 AM, Tom Beecher  wrote:
> 
> I wouldn’t assume that the small number of responses indicates a lack of 
> interest.  It’s possible that people haven’t commented because they’ve seen 
> this topic play itself out over the years, and although they have opinions, 
> they don’t feel compelled to post them there.  (Interestingly enough, some 
> have posted them here.)  Another possibility is that they’re waiting until 
> the draft is presented later this week before expressing their opinions.
> 
> There are quite a few responses. All expressed zero interest.
> 
> This is a pretty common pattern. Someone comes up with an idea, spends zero 
> time researching the history of the problem or previous discussions,and 
> submits it to the IETF. People point out that it's been discussed before,and 
> they aren't interested,but the submitter stamps their feet because nobody is 
> LISTENING to them. 
> 
> On Sun, Mar 20, 2022 at 1:14 PM Greg Skinner via NANOG  > wrote:
> 
> 
> > On Mar 15, 2022, at 7:04 PM, Mark Andrews  > > wrote:
> > 
> > 
> > Firstly nobody uses mailing list digests as references.  Secondly anyone 
> > can post to the mailing list, you just need to subscribe.  If you read the 
> > thread you can see there is no interest in this.
> > 
> > https://mailarchive.ietf.org/arch/msg/int-area/iZnR1Dkomu4D8AfHTI2xR_npJ8Y/ 
> > 
> > 
> 
> I wouldn’t assume that the small number of responses indicates a lack of 
> interest.  It’s possible that people haven’t commented because they’ve seen 
> this topic play itself out over the years, and although they have opinions, 
> they don’t feel compelled to post them there.  (Interestingly enough, some 
> have posted them here.)  Another possibility is that they’re waiting until 
> the draft is presented later this week before expressing their opinions.
> 
> —gregbo
> 
> 

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Tom Beecher]

>
> I wouldn’t assume that the small number of responses indicates a lack of
> interest.  It’s possible that people haven’t commented because they’ve seen
> this topic play itself out over the years, and although they have opinions,
> they don’t feel compelled to post them there.  (Interestingly enough, some
> have posted them here.)  Another possibility is that they’re waiting until
> the draft is presented later this week before expressing their opinions.
>

There are quite a few responses. All expressed zero interest.

This is a pretty common pattern. Someone comes up with an idea, spends zero
time researching the history of the problem or previous discussions,and
submits it to the IETF. People point out that it's been
discussed before,and they aren't interested,but the submitter stamps their
feet because nobody is LISTENING to them.

On Sun, Mar 20, 2022 at 1:14 PM Greg Skinner via NANOG 
wrote:

>
>
> > On Mar 15, 2022, at 7:04 PM, Mark Andrews  wrote:
> >
> >
> > Firstly nobody uses mailing list digests as references.  Secondly anyone
> can post to the mailing list, you just need to subscribe.  If you read the
> thread you can see there is no interest in this.
> >
> >
> https://mailarchive.ietf.org/arch/msg/int-area/iZnR1Dkomu4D8AfHTI2xR_npJ8Y/
> >
>
> I wouldn’t assume that the small number of responses indicates a lack of
> interest.  It’s possible that people haven’t commented because they’ve seen
> this topic play itself out over the years, and although they have opinions,
> they don’t feel compelled to post them there.  (Interestingly enough, some
> have posted them here.)  Another possibility is that they’re waiting until
> the draft is presented later this week before expressing their opinions.
>
> —gregbo
>
>
>

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[John Levine]

It appears that Abraham Y. Chen  said:
>     C.    Recently, we were made aware of the Int-Area activities. 
>Attempts to reach the Group Chairs have not received any responses.
>
>     D.    I just received an Int-Area Digest Vol 199, Issue 14 
>requesting IETF to reactivate the IPv4 support.

For people who don't follow the IETF lists, here's a summary of
the responses.  Mr. Chen thought it was a good idea, everyone
else, and I mean everyone, said it's a foolish idea and not
worth pursuing.

R's,
John

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Greg Skinner via NANOG]

> On Mar 15, 2022, at 7:04 PM, Mark Andrews  wrote:
> 
> 
> Firstly nobody uses mailing list digests as references.  Secondly anyone can 
> post to the mailing list, you just need to subscribe.  If you read the thread 
> you can see there is no interest in this.
> 
> https://mailarchive.ietf.org/arch/msg/int-area/iZnR1Dkomu4D8AfHTI2xR_npJ8Y/
> 

I wouldn’t assume that the small number of responses indicates a lack of 
interest.  It’s possible that people haven’t commented because they’ve seen 
this topic play itself out over the years, and although they have opinions, 
they don’t feel compelled to post them there.  (Interestingly enough, some have 
posted them here.)  Another possibility is that they’re waiting until the draft 
is presented later this week before expressing their opinions.

—gregbo

Re: CC: s to Non List Members (Was Re: Making Use of 240/4 NetBlock) Re: 2022031711315.AYC

[Abraham Y. Chen]

Hi, Tom:

1)    " ... it has serious deficiencies. ... ":    Could you please be 
specific? Branding something without qualifying information is 
unprofessional.


Regards,


Abe (2022-03-17 13:18)


--
NANOG Digest, Vol 170, Issue 19


Message: 2
Date: Wed, 16 Mar 2022 08:28:36 -0400
From: Tom Beecher
To: Greg Skinner
Cc:b...@theworld.com,  "North American Network Operators' Group"

Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re:
202203071610.AYC Re: Making Use of 240/4 NetBlock)
Message-ID:

Content-Type: text/plain; charset="utf-8"

No quibble about the discussion happening on a NOG list, not at all.

But frankly unless the proposal is even starting to move forward in the
IETF process such that a standards change is possible, it's just noise. ( I
don't predict that the draft being discussed ever gets that far anyways ;
it has serious deficiencies.)

On Sat, Mar 12, 2022 at 6:53 PM Greg Skinner via NANOG
wrote:


I agree.  iMO, this 240/4 issue is another one of those tussles in
cyberspace
<https://david.choffnes.com/classes/cs4700fa14/papers/tussle.pdf>.   But
I don?t fault IETF people or anyone else who pursues technical solutions to
these types of problems as long as they are open and honest about the
limitations of these solutions.

Also, IMO, the value of having a discussion about this issue here (and
other NOG forums) is to get the perspective of people who (generally
speaking) deal more immediately with the problems the broader ?online"
population has with IETF-based technology.

?gregbo

On Mar 8, 2022, at 9:25 PM,b...@theworld.com  wrote:


I'm beginning to wonder if the internet will survive the ipv6 adoption
debates.

Here's the real problem which you all can promptly ignore:

The IETF et al are full of bright technical people who can design
protocols, packet formats, etc.

But many of the major problems facing the internet are not, at their
core, engineering problems.

They're in the realm of social, legal, marketing, politics, int'l
policy, governance, law enforcement, commerce, economics, sociology,
psychology, etc. which TBH as bright as many of the engineers et al
are these problems are way beyond their ken, occasional polymath
excepted.

But first you have to admit you have a problem, and limitations.

Shouting at the rafters about address space depletion etc while waving
RFCs may not quite do it.

Similar can be said about spam, malware attacks, phishing, etc.

Yet another cryptographic protocol probably won't save the day but as
the expression goes when all you have is a hammer the whole world
looks like a nail.

--
-Barry Shein

Software Tool & Die| bzs at 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*



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

Re: Making Use of 240/4 NetBlock Re: 202203171153.AYC

[Abraham Y. Chen]

Hi, Tom:

1)    "  I've read the draft. ...   ":    Then, you still overlooked the 
essence of the keyword "overlay":


    A.    The EzIP project started with the goal of getting enough IP 
addresses for end-to-end communication according to the old fashioned 
definition in telecommunications, such as PSTN. Upon correlated the 
three private netblocks to the reusable PBX numbering convention and 
discovered the availability of the 240/4 netblock, we enlisted the 
Option Word for carrying such additional information to accomplish this 
goal.


    B.    Next, we realized that since 240/4 is so big, we can deploy 
it over a much larger area than a commonly known private premises. The 
concept of RAN (Regional Area Network) was born. Since the existing 
Internet routers will drop any 240/4 addressed packets, RANs can deploy 
on their own, without interference in either direction. With each RAN 
served from one IPv4 public address, the entire RAN can be viewed as an 
isolated island or a piece of land floating in the air and tethered to 
the Internet core via one umbilical cord.


    C.    This configuration frees up the need for updating any current 
Internet equipment while growing by expanding from one IPv4 address. 
That is, the RAN deployment can be done via SPRs (Semi-Public Routers) 
as needed. All of these introductory activities do not need to use the 
Option Word, at all. This phase of the deployment can use the 
degenerated EzIP header mentioned in the Draft which is actually the 
conventional basic IPv4 header (without Option Word).


    D.    Only when direct communication between IoTs residing in 
separate RANs is desired, IoTs capable of the full EzIP header will be 
used. (These are not wide spread requirement, but case-by-case for elite 
users.) Since the number of umbilical cords is finite, interconnecting 
RANs for this purpose can be achieved by deploying SPRs where is needed. 
Of course, if existing routers are wiling to support (by "trimming down" 
the existing code), the deployment will go much faster. But, it is not 
necessary.


2)    The above is why "overlay" network can be used to characterize the 
EzIP architecture. One interesting online graphics that we recently came 
across depicts this configuration very nicely (see URL below). One can 
visualize that each continent, country, and even all the way down a 
Region or an island is floated above the earth core (the Internet) and 
tethered to it via an umbilical cord (IPv4 address). With this 
architecture, everything in the RAN can start fresh, yet supported by 
the core all the time. The involvement of the latter is optional. This 
relationship is the same as national versus international telephony 
networks in the PSTN world. In other words, the current Internet proper 
will serve just the current type of interconnections among RANs, if no 
update is made to its routers.


https://dotconnectafrica.org/icann-wins-by-technical-knockout-dca-blocked-from-being-heard-on-its-merit/ 



Hope I am not boring you by being too wordy.

Regards,




Abe (2022-03-17 12:20)


--

NANOG Digest, Vol 170, Issue 19

Message: 9 Date: Wed, 16 Mar 2022 11:38:51 -0400 From: Tom Beecher 
 To: "Abraham Y. Chen"  Cc: Mark 
Andrews , NANOG  Subject: Re: Making Use 
of 240/4 NetBlock Re: 202203161019.AYC Message-ID: 
 
Content-Type: text/plain; charset="utf-8"



2)Re: Ur. Pt. 2) " So replace every CPE device, including ...   ":
It is evident that  you even did not glance at the EzIP Draft Abstract
before commenting, but just relying on your recollection of the past 240/4
efforts. Please spend a minute or two on reading the EzIP Abstract. In
particular, please look for a keyword "overlay". Hint, this was not our
invention. It was a concise characterization by an authoritative Internet
figure. So, we imported it into our latest IETF draft update. Hopefully,
this keyword will steer your opinion on EzIP.


I've read the draft. Your proposal appears to rely on a specific value in
the IP option header to create your overlay. While that sounds good on
paper, it's operationally been best practice for at least the last decade
(maybe longer) to drop any packet with an IP option set that you don't
explicitly want because a significant number of routers kick every
packet with options to CPU, so any substantive traffic flow with options
set could knock devices over.  I can't speak to the current state of router
processing, but I'd bet dollars to donuts most of those filters are still
in place.

So, assuming your proposal were to eventually become an adopted standard,
before it could reliably work across the general internet :

- Any device that still treated 240/4 differently would need to be updated
to treat it like anything else.
- Any existing filters that dropped packets with*any*  IP option set would
have to be modified to permit the ones you defin

Re: CC: s to Non List Members (Re: Making Use of 240/4 NetBlock Re: 202203171135.AYC

[Abraham Y. Chen]

Hi, Greg:

1)    " ... The IETF has changed its position on several (IMO) key 
issues during its existence. ...  ":    Well said! In fact, I believe 
(from one of the APNIC blogs recounting the Internet history) that 
CG-NAT was one of those "bastards" who turned to be accepted as a prince 
whom everyone is defending him now, without realizing that an 
enhancement is at the front door steps again.


Regards,


Abe (2022-03-17 11:50)


--
NANOG Digest, Vol 170, Issue 19


Message: 34
Date: Wed, 16 Mar 2022 15:32:45 -0700
From: Greg Skinner
To: Tom Beecher
Cc:b...@theworld.com, North American Network Operators' Group

Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re:
202203071610.AYC Re: Making Use of 240/4 NetBlock)
Message-ID:<109db49c-2471-4fe2-ac68-e4eeafe1c...@icloud.com>
Content-Type: text/plain; charset="utf-8"

I have qualms about these drafts also.  However, even if the IETF does not move 
forward with any of them (not even to adopt them as WG items), that doesn?t 
mean they never will.  Times change.  Circumstances change.  The IETF has 
changed its position on several (IMO) key issues during its existence.  Perhaps 
this will be one of those times.

Incidentally, if you take a look at this post from Theodore 
Ts?o<https://mailarchive.ietf.org/arch/msg/ietf/IGKkL8IM1IptV4Q3Z3pko6OC1Xs/>   he?s 
pretty much saying the same thing that Barry Shein said, that the IETF isn?t as good at 
policy as it is in producing protocol standards.  (The thread it?s from started from a 
response to the publication of RFC2008<https://www.rfc-editor.org/rfc/rfc2008.txt>  
as a Best Current Practice, in spite of ?vigorous opposition?.)

The other thing I wanted to say is for anyone who doesn?t know a lot about the 
IETF workings, the contributions of some of the authors of the Schoen drafts 
are recognized and respected in the IETF Transport Area.  They?re not new to 
this stuff.  They have ?clue?.  They do due diligence.  They produce running 
code, and (IMO) are seeking rough consensus.  I believe that in the IETF of, 
say, a quarter century ago, their drafts would have progressed further through 
the standards process.  For various reasons, today?s IETF is different, but 
could still change its minds.  I believe the authors of the Schoen drafts are 
capable of drumming up support for their ideas even if they don?t (immediately) 
become IETF drafts, and that the IETF might change its position on their ideas, 
as a result of such support.

?gregbo


On Mar 16, 2022, at 5:28 AM, Tom Beecher  wrote:

No quibble about the discussion happening on a NOG list, not at all.

But frankly unless the proposal is even starting to move forward in the IETF 
process such that a standards change is possible, it's just noise. ( I don't 
predict that the draft being discussed ever gets that far anyways ; it has 
serious deficiencies.)

On Sat, Mar 12, 2022 at 6:53 PM Greg Skinner via NANOG mailto:nanog@nanog.org>> wrote:
I agree.  iMO, this 240/4 issue is another one of those tussles in 
cyberspace<https://david.choffnes.com/classes/cs4700fa14/papers/tussle.pdf>.   
But I don?t fault IETF people or anyone else who pursues technical solutions to these 
types of problems as long as they are open and honest about the limitations of these 
solutions.

Also, IMO, the value of having a discussion about this issue here (and other NOG 
forums) is to get the perspective of people who (generally speaking) deal more 
immediately with the problems the broader ?online" population has with 
IETF-based technology.

?gregbo


On Mar 8, 2022, at 9:25 PM,b...@theworld.com  <mailto:b...@theworld.com>  wrote:


I'm beginning to wonder if the internet will survive the ipv6 adoption
debates.

Here's the real problem which you all can promptly ignore:

The IETF et al are full of bright technical people who can design
protocols, packet formats, etc.

But many of the major problems facing the internet are not, at their
core, engineering problems.

They're in the realm of social, legal, marketing, politics, int'l
policy, governance, law enforcement, commerce, economics, sociology,
psychology, etc. which TBH as bright as many of the engineers et al
are these problems are way beyond their ken, occasional polymath
excepted.

But first you have to admit you have a problem, and limitations.

Shouting at the rafters about address space depletion etc while waving
RFCs may not quite do it.

Similar can be said about spam, malware attacks, phishing, etc.

Yet another cryptographic protocol probably won't save the day but as
the expression goes when all you have is a hammer the whole world
looks like a nail.

--
-Barry Shein

Software Tool & Die| bzs at TheWorld.com<http://theworld.com/>  
|http://www.TheWorld.com  <http://www.theworld.com/>
Purveyors to the Trade | Voice: +1 617-S

Re: Not Making Use of 240/4 NetBlock Re: 202203171125.AYC

[Abraham Y. Chen]

Hi, Mark:

1)    " ... known defective products ...   ": Could you please define 
what do you mean? And, what "products" do you have in mind? Otherwise, 
this sounds like a scare tactic without a foundation.



Regards,


Abe (2022-03-17 11:32)


--

NANOG Digest, Vol 170, Issue 19

Message: 35
Date: Thu, 17 Mar 2022 09:48:04 +1100
From: Mark Andrews
To: Owen DeLong
Cc: Sylvain Baya,b...@theworld.com, Niels Bakker
,nanog@nanog.org
Subject: Re: Not Making Use of 240/4 NetBlock
Message-ID:<1c6b1ad8-399e-4b3c-b3ad-a5c846f62...@isc.org>
Content-Type: text/plain; charset=utf-8

It?s a business problem for the RIR?s. Selling / leasing known defective 
products is against lots of consumer law.
-- Mark Andrews


On 17 Mar 2022, at 03:43, Owen DeLong  wrote:

?


On Mar 15, 2022, at 19:23 , Mark Andrews  wrote:




On 16 Mar 2022, at 02:54, Owen DeLong via NANOG  wrote:

Having spent nearly 15 years on the ARIN Advisory Council, I think I?m able
to claim some detailed knowledge on the subject.

In general, the RIRs themselves maintain neutrality about such things, looking 
to their
respective communities for input on what to do. However, so long as the IETF and
has not designated the space Unicast Address Space to be delegated to the
RIRs for allocation/assignment, IANA will not delegate it to the RIRs and the 
RIRs
won?t, therefore, delegate it to users.

If you really want to see this happen (and I still argue that the amount of 
effort already wasted
discussing this idea vastly exceeds what would be needed towards IPv6 to get 
beyond
caring about it), then the first step must be to convince the IETF to designate 
the
space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the RIRs.

Once that happens, the rest of the allocation process is basically automatic. 
From a policy
perspective at the RIR level, it will be no different than say 4/8 or 1/8.

Actually it would be fundamentally different to 4/8 or 1/8.  You are looking at 
firmware upgrades
rather than dealing with squatters and out-of-date ACLs both of which are 
self-inflicted by one
of the parties.  Routers and end devices that don?t know how to hand 240/4 are 
no self inflicted
injuries.  Issuing 4/8 or 1/8 worked for parties that had been following the 
rules.  With 240/4
there where no rules to follow which results in RIR?s leasing known defective 
addresses.

I was speaking from an RIR allocation perspective, NOT talking about the 
technological hurdles
to implementation.

I was specifically responding to someone?s question about how the RIRs would be 
impacted by
this if it were to come to pass.

I addressed your concern in the following paragraph as an aside, however.


Now, convincing vendors to update their firmware, software, etc. is another 
matter
and entirely outside of the control of the RIRs. Merchant compliance with IETF 
standards
is generally considered useful, but it is entirely voluntary and even in the 
best of
circumstances doesn?t every happen instantaneously and almost always involves
some stumbles along the way.

Owen



On Mar 15, 2022, at 02:54 , Sylvain Baya  wrote:

Dear NANOG-ers,
Hope this email finds you in good health!
Please see my comments below, inline...

Le mardi 15 mars 2022,  a ?crit :


Hi Barry,
Thanks for your email, brother!


But the RIRs are the ones fielding requests for IPv4 space, and have
some notion of how policy implementation might work in practice, so
should have a lot of useful input.


...of course, it appears that RIRs have the opportunity
to add their useful inputs, as Impact Analysis Report
(IAR); during the Policy Development Process (PDP)
initiated by the*appropriate*  [1] Internet community.
They explain it themselves here [2].
__
[1]:<https://tools.ietf.org/html/rfc7020>
[2]:<https://www.nro.net/accountability/rir-accountability/q-and-a/>

Shalom,
--sb.


On March 14, 2022 at 00:45niels=na...@bakker.net  (Niels Bakker) wrote:

*b...@theworld.com  (b...@theworld.com) [Mon 14 Mar 2022, 00:31 CET]:

Personally I'd rather hear from the RIRs regarding the value or not
of making more IPv4 space such as 240/4 available. They're on the
front lines of this.

You've got your policy development process diagram upside down. The
community decides what the RIRs implement. They're not in touch with
merchant silicon manufacturers.


-- Niels.

--
   -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*


--
Best Regards !
__
baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure>
Subscribe to Mailing List:<https://lists.cmnog.cm/mailman/listinfo/cmnog/>
__
#?LASAINTEBIBLE?|#?Romains15?:33?Que LE ?#?DIEU? de ?#?Paix? soit avec vous 
tous! ?#?Amen?!?
?#?MaPri?re? est que tu naisses de nouveau. #Chr?tiennement?
?Comme une

Re: Making Use of 240/4 NetBlock Re: 202203162242.AYC

[Abraham Y. Chen]

Hi, Fred:

1)    " ... you will need to replace the existing DNS and DHCP 
systems...  ":    I am glad that you have touched the next level of 
considerations. Operating an RAN with one 240/4 netblock, there will be 
more than enough IP addresses to assign to all client premises. So, the 
EzIP deployment will operate with static IP address disciplines, 
negating the fundamental reasons to have DNS and DHCP. That is, 
transition to running the electronic equivalent of telephony White and 
Yellow Pages would be what EzIP deployment should rely upon.


2)    " ... hear the relevant organizations saying that it changes their 
networking model, ... similar to what has happened with the IPv6 
deployment.  ":    Do they recognize that implementing EzIP address plan 
on CG-NAT changes no network model? So, the perturbation is far less 
than deploying IPv6.


Regards,


Abe (2022-03-16 22:59)


On 2022-03-16 12:03, Fred Baker wrote:

On Mar 16, 2022, at 7:50 AM, Abraham Y. Chen  wrote:

2)Re: Ur. Pt. 2) " So replace every CPE device, including ...   ": It 
is evident that  you even did not glance at the EzIP Draft Abstract before commenting, 
but just relying on your recollection of the past 240/4 efforts.

I did read it. Correct my understanding.

Your proposal is to replace the IP addressing model and IP (yes, you're using 
options, but the architecture changed). Do so do, you will need to replace the 
existing DNS and DHCP systems with a PABX-like model - you need to find a way 
to let systems address each other. It also replaces firewalls with a model that 
prevents communication with devices that don't know the PABX port numbers.

Frankly, I can already hear the relevant organizations saying that it changes 
their networking model, and it starts a process similar to what has happened 
with the IPv6 deployment.




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

Re: Not Making Use of 240/4 NetBlock

[Mark Andrews]

It’s a business problem for the RIR’s. Selling / leasing known defective 
products is against lots of consumer law. 
-- 
Mark Andrews

> On 17 Mar 2022, at 03:43, Owen DeLong  wrote:
> 
> 
> 
>>> On Mar 15, 2022, at 19:23 , Mark Andrews  wrote:
>>> 
>>> 
>>> 
 On 16 Mar 2022, at 02:54, Owen DeLong via NANOG  wrote:
>>> 
>>> Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able
>>> to claim some detailed knowledge on the subject.
>>> 
>>> In general, the RIRs themselves maintain neutrality about such things, 
>>> looking to their
>>> respective communities for input on what to do. However, so long as the 
>>> IETF and
>>> has not designated the space Unicast Address Space to be delegated to the
>>> RIRs for allocation/assignment, IANA will not delegate it to the RIRs and 
>>> the RIRs
>>> won’t, therefore, delegate it to users.
>>> 
>>> If you really want to see this happen (and I still argue that the amount of 
>>> effort already wasted
>>> discussing this idea vastly exceeds what would be needed towards IPv6 to 
>>> get beyond
>>> caring about it), then the first step must be to convince the IETF to 
>>> designate the
>>> space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the 
>>> RIRs.
>>> 
>>> Once that happens, the rest of the allocation process is basically 
>>> automatic. From a policy
>>> perspective at the RIR level, it will be no different than say 4/8 or 1/8.
>> 
>> Actually it would be fundamentally different to 4/8 or 1/8.  You are looking 
>> at firmware upgrades
>> rather than dealing with squatters and out-of-date ACLs both of which are 
>> self-inflicted by one
>> of the parties.  Routers and end devices that don’t know how to hand 240/4 
>> are no self inflicted
>> injuries.  Issuing 4/8 or 1/8 worked for parties that had been following the 
>> rules.  With 240/4
>> there where no rules to follow which results in RIR’s leasing known 
>> defective addresses.
> 
> I was speaking from an RIR allocation perspective, NOT talking about the 
> technological hurdles
> to implementation.
> 
> I was specifically responding to someone’s question about how the RIRs would 
> be impacted by
> this if it were to come to pass.
> 
> I addressed your concern in the following paragraph as an aside, however.
> 
>> 
>>> Now, convincing vendors to update their firmware, software, etc. is another 
>>> matter
>>> and entirely outside of the control of the RIRs. Merchant compliance with 
>>> IETF standards
>>> is generally considered useful, but it is entirely voluntary and even in 
>>> the best of
>>> circumstances doesn’t every happen instantaneously and almost always 
>>> involves
>>> some stumbles along the way.
>>> 
>>> Owen
>>> 
>>> 
 On Mar 15, 2022, at 02:54 , Sylvain Baya  wrote:
 
 Dear NANOG-ers,
 Hope this email finds you in good health!
 Please see my comments below, inline...
 
 Le mardi 15 mars 2022,  a écrit :
 
 
 Hi Barry,
 Thanks for your email, brother!
 
 
 But the RIRs are the ones fielding requests for IPv4 space, and have
 some notion of how policy implementation might work in practice, so
 should have a lot of useful input.
 
 
 ...of course, it appears that RIRs have the opportunity
 to add their useful inputs, as Impact Analysis Report
 (IAR); during the Policy Development Process (PDP)
 initiated by the *appropriate* [1] Internet community.
 They explain it themselves here [2].
 __
 [1]: 
 [2]: 
 
 Shalom,
 --sb.
 
 
 On March 14, 2022 at 00:45 niels=na...@bakker.net (Niels Bakker) wrote:
> * b...@theworld.com (b...@theworld.com) [Mon 14 Mar 2022, 00:31 CET]:
>> Personally I'd rather hear from the RIRs regarding the value or not 
>> of making more IPv4 space such as 240/4 available. They're on the 
>> front lines of this.
> 
> You've got your policy development process diagram upside down. The 
> community decides what the RIRs implement. They're not in touch with 
> merchant silicon manufacturers.
> 
> 
>-- Niels.
 
 -- 
   -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*
 
 
 -- 
 Best Regards !
 __
 baya.sylvain[AT cmNOG DOT cm]|
 Subscribe to Mailing List: 
 __
 #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec 
 vous tous! ‪#‎Amen‬!»
 ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
 «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire 
 après TOI, ô 

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Greg Skinner via NANOG]

I have qualms about these drafts also.  However, even if the IETF does not move 
forward with any of them (not even to adopt them as WG items), that doesn’t 
mean they never will.  Times change.  Circumstances change.  The IETF has 
changed its position on several (IMO) key issues during its existence.  Perhaps 
this will be one of those times.

Incidentally, if you take a look at this post from Theodore Ts’o 
  he’s 
pretty much saying the same thing that Barry Shein said, that the IETF isn’t as 
good at policy as it is in producing protocol standards.  (The thread it’s from 
started from a response to the publication of RFC2008 
 as a Best Current Practice, in 
spite of “vigorous opposition”.)

The other thing I wanted to say is for anyone who doesn’t know a lot about the 
IETF workings, the contributions of some of the authors of the Schoen drafts 
are recognized and respected in the IETF Transport Area.  They’re not new to 
this stuff.  They have “clue”.  They do due diligence.  They produce running 
code, and (IMO) are seeking rough consensus.  I believe that in the IETF of, 
say, a quarter century ago, their drafts would have progressed further through 
the standards process.  For various reasons, today’s IETF is different, but 
could still change its minds.  I believe the authors of the Schoen drafts are 
capable of drumming up support for their ideas even if they don’t (immediately) 
become IETF drafts, and that the IETF might change its position on their ideas, 
as a result of such support.

—gregbo

> On Mar 16, 2022, at 5:28 AM, Tom Beecher  wrote:
> 
> No quibble about the discussion happening on a NOG list, not at all. 
> 
> But frankly unless the proposal is even starting to move forward in the IETF 
> process such that a standards change is possible, it's just noise. ( I don't 
> predict that the draft being discussed ever gets that far anyways ; it has 
> serious deficiencies.) 
> 
> On Sat, Mar 12, 2022 at 6:53 PM Greg Skinner via NANOG  > wrote:
> I agree.  iMO, this 240/4 issue is another one of those tussles in cyberspace 
> .   But I 
> don’t fault IETF people or anyone else who pursues technical solutions to 
> these types of problems as long as they are open and honest about the 
> limitations of these solutions.
> 
> Also, IMO, the value of having a discussion about this issue here (and other 
> NOG forums) is to get the perspective of people who (generally speaking) deal 
> more immediately with the problems the broader “online" population has with 
> IETF-based technology.
> 
> —gregbo
> 
>> On Mar 8, 2022, at 9:25 PM, b...@theworld.com  
>> wrote:
>> 
>> 
>> I'm beginning to wonder if the internet will survive the ipv6 adoption
>> debates.
>> 
>> Here's the real problem which you all can promptly ignore:
>> 
>> The IETF et al are full of bright technical people who can design
>> protocols, packet formats, etc.
>> 
>> But many of the major problems facing the internet are not, at their
>> core, engineering problems.
>> 
>> They're in the realm of social, legal, marketing, politics, int'l
>> policy, governance, law enforcement, commerce, economics, sociology,
>> psychology, etc. which TBH as bright as many of the engineers et al
>> are these problems are way beyond their ken, occasional polymath
>> excepted.
>> 
>> But first you have to admit you have a problem, and limitations.
>> 
>> Shouting at the rafters about address space depletion etc while waving
>> RFCs may not quite do it.
>> 
>> Similar can be said about spam, malware attacks, phishing, etc.
>> 
>> Yet another cryptographic protocol probably won't save the day but as
>> the expression goes when all you have is a hammer the whole world
>> looks like a nail.
>> 
>> -- 
>>-Barry Shein
>> 
>> Software Tool & Die| bzs at 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: Not Making Use of 240/4 NetBlock

[Owen DeLong via NANOG]

> On Mar 15, 2022, at 19:23 , Mark Andrews  wrote:
> 
> 
> 
>> On 16 Mar 2022, at 02:54, Owen DeLong via NANOG  wrote:
>> 
>> Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able
>> to claim some detailed knowledge on the subject.
>> 
>> In general, the RIRs themselves maintain neutrality about such things, 
>> looking to their
>> respective communities for input on what to do. However, so long as the IETF 
>> and
>> has not designated the space Unicast Address Space to be delegated to the
>> RIRs for allocation/assignment, IANA will not delegate it to the RIRs and 
>> the RIRs
>> won’t, therefore, delegate it to users.
>> 
>> If you really want to see this happen (and I still argue that the amount of 
>> effort already wasted
>> discussing this idea vastly exceeds what would be needed towards IPv6 to get 
>> beyond
>> caring about it), then the first step must be to convince the IETF to 
>> designate the
>> space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the 
>> RIRs.
>> 
>> Once that happens, the rest of the allocation process is basically 
>> automatic. From a policy
>> perspective at the RIR level, it will be no different than say 4/8 or 1/8.
> 
> Actually it would be fundamentally different to 4/8 or 1/8.  You are looking 
> at firmware upgrades
> rather than dealing with squatters and out-of-date ACLs both of which are 
> self-inflicted by one
> of the parties.  Routers and end devices that don’t know how to hand 240/4 
> are no self inflicted
> injuries.  Issuing 4/8 or 1/8 worked for parties that had been following the 
> rules.  With 240/4
> there where no rules to follow which results in RIR’s leasing known defective 
> addresses.

I was speaking from an RIR allocation perspective, NOT talking about the 
technological hurdles
to implementation.

I was specifically responding to someone’s question about how the RIRs would be 
impacted by
this if it were to come to pass.

I addressed your concern in the following paragraph as an aside, however.

> 
>> Now, convincing vendors to update their firmware, software, etc. is another 
>> matter
>> and entirely outside of the control of the RIRs. Merchant compliance with 
>> IETF standards
>> is generally considered useful, but it is entirely voluntary and even in the 
>> best of
>> circumstances doesn’t every happen instantaneously and almost always involves
>> some stumbles along the way.
>> 
>> Owen
>> 
>> 
>>> On Mar 15, 2022, at 02:54 , Sylvain Baya  wrote:
>>> 
>>> Dear NANOG-ers,
>>> Hope this email finds you in good health!
>>> Please see my comments below, inline...
>>> 
>>> Le mardi 15 mars 2022,  a écrit :
>>> 
>>> 
>>> Hi Barry,
>>> Thanks for your email, brother!
>>> 
>>> 
>>> But the RIRs are the ones fielding requests for IPv4 space, and have
>>> some notion of how policy implementation might work in practice, so
>>> should have a lot of useful input.
>>> 
>>> 
>>> ...of course, it appears that RIRs have the opportunity
>>> to add their useful inputs, as Impact Analysis Report
>>> (IAR); during the Policy Development Process (PDP)
>>> initiated by the *appropriate* [1] Internet community.
>>> They explain it themselves here [2].
>>> __
>>> [1]: 
>>> [2]: 
>>> 
>>> Shalom,
>>> --sb.
>>> 
>>> 
>>> On March 14, 2022 at 00:45 niels=na...@bakker.net (Niels Bakker) wrote:
 * b...@theworld.com (b...@theworld.com) [Mon 14 Mar 2022, 00:31 CET]:
> Personally I'd rather hear from the RIRs regarding the value or not 
> of making more IPv4 space such as 240/4 available. They're on the 
> front lines of this.
 
 You've got your policy development process diagram upside down. The 
 community decides what the RIRs implement. They're not in touch with 
 merchant silicon manufacturers.
 
 
 -- Niels.
>>> 
>>> -- 
>>>-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*
>>> 
>>> 
>>> -- 
>>> Best Regards !
>>> __
>>> baya.sylvain[AT cmNOG DOT cm]|
>>> Subscribe to Mailing List: 
>>> __
>>> #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous 
>>> tous! ‪#‎Amen‬!»
>>> ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
>>> «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire 
>>> après TOI, ô DIEU!»(#Psaumes42:2)
>>> 
>>> 
>> 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

Re: Making Use of 240/4 NetBlock Re: 202203161019.AYC

[Tom Beecher]

>
> 2)Re: Ur. Pt. 2) " So replace every CPE device, including ...   ":
> It is evident that  you even did not glance at the EzIP Draft Abstract
> before commenting, but just relying on your recollection of the past 240/4
> efforts. Please spend a minute or two on reading the EzIP Abstract. In
> particular, please look for a keyword "overlay". Hint, this was not our
> invention. It was a concise characterization by an authoritative Internet
> figure. So, we imported it into our latest IETF draft update. Hopefully,
> this keyword will steer your opinion on EzIP.


I've read the draft. Your proposal appears to rely on a specific value in
the IP option header to create your overlay. While that sounds good on
paper, it's operationally been best practice for at least the last decade
(maybe longer) to drop any packet with an IP option set that you don't
explicitly want because a significant number of routers kick every
packet with options to CPU, so any substantive traffic flow with options
set could knock devices over.  I can't speak to the current state of router
processing, but I'd bet dollars to donuts most of those filters are still
in place.

So, assuming your proposal were to eventually become an adopted standard,
before it could reliably work across the general internet :

- Any device that still treated 240/4 differently would need to be updated
to treat it like anything else.
- Any existing filters that dropped packets with *any* IP option set would
have to be modified to permit the ones you define for EzIP
- At least some router software would have to have IP option handling
adjusted in some way. ( At one point in the past, one big router vendor
only allowed you to configure an ip-options filter based on the IANA
defined values, not others. )

This is a LOT of work and time for an overlay.

On Wed, Mar 16, 2022 at 10:51 AM Abraham Y. Chen  wrote:

> Hi, Mark:
>
> 1)Re: Ur. Pt. 1)  " ISE != IETF. ...   ":On a public forum like
> NANOG, it is much more expeditious to provide forward guidance than
> reciting past failures, especially those of a third party due to improper
> system setup.
>
> 2)Re: Ur. Pt. 2) " So replace every CPE device, including ...   ":
> It is evident that  you even did not glance at the EzIP Draft Abstract
> before commenting, but just relying on your recollection of the past 240/4
> efforts. Please spend a minute or two on reading the EzIP Abstract. In
> particular, please look for a keyword "overlay". Hint, this was not our
> invention. It was a concise characterization by an authoritative Internet
> figure. So, we imported it into our latest IETF draft update. Hopefully,
> this keyword will steer your opinion on EzIP.
>
> Regards,
>
>
> Abe (2022-03-16 10:49)
>
>
> --
>
> NANOG Digest, Vol 170, Issue 18
>
> Message: 42
> Date: Wed, 16 Mar 2022 13:04:01 +1100
> From: Mark Andrews  
> To: "Abraham Y. Chen"  
> Cc: Tom Beecher  , "Chen, Abraham Y."
>, NANOG  
> 
> Subject: Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC
> Message-ID:  
> 
> Content-Type: text/plain; charset=utf-8
>
>
>
>
> On 16 Mar 2022, at 07:27, Abraham Y. Chen  
>  wrote:
>
> Hi, Tom:
>
> 1)"  better to have that conversation via the appropriate IETF 
> channels. ":Thanks for the recommendation. I would appreciate 
> very much if you could guide us to the specific contact. Before we attempt to 
> do so, however, it would be prudent to report the history of our team's 
> experience:
>
> A.The first IETF Draft on EzIP Project started from 2016-12 as 
> instructed by the ISE (Independent Submission Editor). Although, at that time 
> Working Group SunSet4 had been in session for awhile. But, we were not aware 
> of, nor being informed about such.
>
> ISE != IETF. There is no responsible AD assigned so this is not classed as 
> IETF work.  For ISE work to become IETF work you need to convince a AD to 
> sponsor the work.
> https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/
>
> B.In Summer of 2018, we discovered that SunSet4 had Concluded. We 
> contacted the person in charge of keeping an eye on possible future IPv4 
> activities, but did not receive any instruction to revise our course.
>
> C.Recently, we were made aware of the Int-Area activities. Attempts 
> to reach the Group Chairs have not received any responses.
>
> D.I just received an Int-Area Digest Vol 199, Issue 14 requesting 
> IETF to reactivate the IPv4 support.
>
> Firstly nobody uses mailing list digests as references.  Secondly anyone can 
> post to the mailing list, you just need to sub

Re: Making Use of 240/4 NetBlock Re: 202203161019.AYC

[Abraham Y. Chen]

Hi, Mark:

1)    Re: Ur. Pt. 1)  " ISE != IETF. ...   ":    On a public forum like 
NANOG, it is much more expeditious to provide forward guidance than 
reciting past failures, especially those of a third party due to 
improper system setup.


2)    Re: Ur. Pt. 2) " So replace every CPE device, including ...   ": 
    It is evident that  you even did not glance at the EzIP Draft 
Abstract before commenting, but just relying on your recollection of the 
past 240/4 efforts. Please spend a minute or two on reading the EzIP 
Abstract. In particular, please look for a keyword "overlay". Hint, this 
was not our invention. It was a concise characterization by an 
authoritative Internet figure. So, we imported it into our latest IETF 
draft update. Hopefully, this keyword will steer your opinion on EzIP.


Regards,


Abe (2022-03-16 10:49)


--
NANOG Digest, Vol 170, Issue 18
Message: 42 Date: Wed, 16 Mar 2022 13:04:01 +1100 From: Mark Andrews 
 To: "Abraham Y. Chen"  Cc: Tom 
Beecher , "Chen, Abraham Y." , 
NANOG  Subject: Re: Making Use of 240/4 NetBlock Re: 
202203151549.AYC Message-ID: 
 Content-Type: text/plain; 
charset=utf-8



On 16 Mar 2022, at 07:27, Abraham Y. Chen  wrote:

Hi, Tom:

1)"  better to have that conversation via the appropriate IETF channels. 
":Thanks for the recommendation. I would appreciate very much if you 
could guide us to the specific contact. Before we attempt to do so, however, it would be 
prudent to report the history of our team's experience:

 A.The first IETF Draft on EzIP Project started from 2016-12 as 
instructed by the ISE (Independent Submission Editor). Although, at that time 
Working Group SunSet4 had been in session for awhile. But, we were not aware 
of, nor being informed about such.


ISE != IETF. There is no responsible AD assigned so this is not classed as IETF 
work.  For ISE work to become IETF work you need to convince a AD to sponsor 
the work.

https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/


 B.In Summer of 2018, we discovered that SunSet4 had Concluded. We 
contacted the person in charge of keeping an eye on possible future IPv4 
activities, but did not receive any instruction to revise our course.

 C.Recently, we were made aware of the Int-Area activities. Attempts to 
reach the Group Chairs have not received any responses.

 D.I just received an Int-Area Digest Vol 199, Issue 14 requesting IETF 
to reactivate the IPv4 support.


Firstly nobody uses mailing list digests as references.  Secondly anyone can 
post to the mailing list, you just need to subscribe.  If you read the thread 
you can see there is no interest in this.

https://mailarchive.ietf.org/arch/msg/int-area/iZnR1Dkomu4D8AfHTI2xR_npJ8Y/


 Hope you can help us to close the loose ends.

2)In the meantime, we realized that the simplest implementation of the EzIP proposal 
is to replace the 100.64/10 netblock used by CG-NAT with the 240/4 netblock. Next, taking 
advantage of the much larger address pool to begin practicing static address assignment 
related disciplines, a "packetized PSTN" is realized. From such a base, the 
EzIP powered CG-NAT behaving as an overlay network in parallel to the existing Internet 
for providing the same services, many of the drawbacks in the latter are mitigated! So, 
we decided to discuss the EzIP proposal directly with the NANOG colleagues, because the 
EzIP deployment can actually be rather stealthy.


So replace every CPE device, including the ones you don?t own, to support 240/4 
then later replace every CPE device again or replace every CPE device with one 
that supports the IPv4aaS you have chosen to use and switch to IPv6-only 
between the ISP and the CPE and get IPv6 delivered to your customers.  Lots of 
ISP?s have already gone to DS-Lite or 464XLAT, to name two IPv4aaS methods, to 
provide their clients access to the legacy IPv4 internet over IPv6-only links.  
Note nothing prevents there being a mixture of dual stack and IPv6-only clients 
on the same access network hardware.

Remember even using these addresses as a replacement for 100.64/10 requires 
every device behind the CPE to also support 240/4 or any traffic emitted from 
these addresses is subject to be discarded.


I look forward to your thoughts.

Regards,


Abe (2022-03-15 16:26)



On 2022-03-14 14:48, Tom Beecher wrote:

If you want to garner discussion or support for your draft RFC, it's probably 
better to have that conversation via the appropriate IETF channels.

On Mon, Mar 14, 2022 at 2:43 PM Abraham Y. Chen  wrote:
Hi, Fred:

0)Thank you for a set of references.

1)We cited only one IETF Draft (Wilson, et al.) among them, because it was 
the first and only one that clearly stated its limitation (Section 2. Caveats 
of Use). More importantly, it was written by three top APNIC officials.

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Tom Beecher]

No quibble about the discussion happening on a NOG list, not at all.

But frankly unless the proposal is even starting to move forward in the
IETF process such that a standards change is possible, it's just noise. ( I
don't predict that the draft being discussed ever gets that far anyways ;
it has serious deficiencies.)

On Sat, Mar 12, 2022 at 6:53 PM Greg Skinner via NANOG 
wrote:

> I agree.  iMO, this 240/4 issue is another one of those tussles in
> cyberspace
> .   But
> I don’t fault IETF people or anyone else who pursues technical solutions to
> these types of problems as long as they are open and honest about the
> limitations of these solutions.
>
> Also, IMO, the value of having a discussion about this issue here (and
> other NOG forums) is to get the perspective of people who (generally
> speaking) deal more immediately with the problems the broader “online"
> population has with IETF-based technology.
>
> —gregbo
>
> On Mar 8, 2022, at 9:25 PM, b...@theworld.com wrote:
>
>
> I'm beginning to wonder if the internet will survive the ipv6 adoption
> debates.
>
> Here's the real problem which you all can promptly ignore:
>
> The IETF et al are full of bright technical people who can design
> protocols, packet formats, etc.
>
> But many of the major problems facing the internet are not, at their
> core, engineering problems.
>
> They're in the realm of social, legal, marketing, politics, int'l
> policy, governance, law enforcement, commerce, economics, sociology,
> psychology, etc. which TBH as bright as many of the engineers et al
> are these problems are way beyond their ken, occasional polymath
> excepted.
>
> But first you have to admit you have a problem, and limitations.
>
> Shouting at the rafters about address space depletion etc while waving
> RFCs may not quite do it.
>
> Similar can be said about spam, malware attacks, phishing, etc.
>
> Yet another cryptographic protocol probably won't save the day but as
> the expression goes when all you have is a hammer the whole world
> looks like a nail.
>
> --
>-Barry Shein
>
> Software Tool & Die| bzs at 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: Not Making Use of 240/4 NetBlock

[bzs]

I think I basically understand the policy and allocation processes.

What I was looking for was some characterization of the current trends
for IPv4 requests, particularly how urgent and worthy they might be
and the amount of space being sought.

RIRs will receive those requests. The rest of us don't see them.

There is also the secondary market which is related but perhaps not
the RIRs' concern or place to characterize though I'd imagine they
have some information based on transfer requests.

That might give us some insight based on actual requests, queues, etc.

Put another way, are those trying to get 240/4, 127/16, etc, space
released for allocation actually solving a real problem beyond some
broad hand wave of "more (IPv4 space) is always better"?

On March 15, 2022 at 08:54 nanog@nanog.org (Owen DeLong via NANOG) wrote:
 > Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able
 > to claim some detailed knowledge on the subject.
 > 
 > In general, the RIRs themselves maintain neutrality about such things, 
 > looking
 > to their
 > respective communities for input on what to do. However, so long as the IETF
 > and
 > has not designated the space Unicast Address Space to be delegated to the
 > RIRs for allocation/assignment, IANA will not delegate it to the RIRs and the
 > RIRs
 > won’t, therefore, delegate it to users.
 > 
 > If you really want to see this happen (and I still argue that the amount of
 > effort already wasted
 > discussing this idea vastly exceeds what would be needed towards IPv6 to get
 > beyond
 > caring about it), then the first step must be to convince the IETF to 
 > designate
 > the
 > space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the
 > RIRs.
 > 
 > Once that happens, the rest of the allocation process is basically automatic.
 > From a policy
 > perspective at the RIR level, it will be no different than say 4/8 or 1/8.
 > 
 > Now, convincing vendors to update their firmware, software, etc. is another
 > matter
 > and entirely outside of the control of the RIRs. Merchant compliance with 
 > IETF
 > standards
 > is generally considered useful, but it is entirely voluntary and even in the
 > best of
 > circumstances doesn’t every happen instantaneously and almost always involves
 > some stumbles along the way.
 > 
 > Owen
 > 
 > 
 > 
 > On Mar 15, 2022, at 02:54 , Sylvain Baya  wrote:
 > 
 > Dear NANOG-ers,
 > Hope this email finds you in good health!
 > Please see my comments below, inline...
 > 
 > Le mardi 15 mars 2022,  a écrit :
 > 
 > 
 > 
 > 
 > Hi Barry,
 > Thanks for your email, brother!
 > 
 >  
 > 
 > But the RIRs are the ones fielding requests for IPv4 space, and have
 > some notion of how policy implementation might work in practice, so
 > should have a lot of useful input.
 > 
 > 
 > 
 > ...of course, it appears that RIRs have the opportunity
 >  to add their useful inputs, as Impact Analysis Report
 >  (IAR); during the Policy Development Process (PDP)
 >  initiated by the *appropriate* [1] Internet community.
 > They explain it themselves here [2].
 > __
 > [1]: 
 > [2]: 
 > 
 > Shalom,
 > --sb.
 > 
 >  
 > 
 > On March 14, 2022 at 00:45 niels=na...@bakker.net (Niels Bakker) 
 > wrote:
 >  > * b...@theworld.com (b...@theworld.com) [Mon 14 Mar 2022, 00:31 
 > CET]:
 >  > >Personally I'd rather hear from the RIRs regarding the value or 
 > not
 >  > >of making more IPv4 space such as 240/4 available. They're on the
 >  > >front lines of this.
 >  >
 >  > You've got your policy development process diagram upside down. 
 > The
 >  > community decides what the RIRs implement. They're not in touch 
 > with
 >  > merchant silicon manufacturers.
 >  >
 >  >
 >  >  -- Niels.
 > 
 > --
 > -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*
 > 
 > 
 > 
 > --
 > 
 > Best Regards !
 > __
 > baya.sylvain[AT cmNOG DOT cm]|
 > Subscribe to Mailing List: 
 > 
 > __
 > #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec 
 > vous
 > tous! ‪#‎Amen‬!»
 > ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
 > «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire
 > après TOI, ô DIEU!»(#Psaumes42:2)
 > 
 > 
 > 

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to 

Re: Not Making Use of 240/4 NetBlock

[Mark Andrews]

> On 16 Mar 2022, at 02:54, Owen DeLong via NANOG  wrote:
> 
> Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able
> to claim some detailed knowledge on the subject.
> 
> In general, the RIRs themselves maintain neutrality about such things, 
> looking to their
> respective communities for input on what to do. However, so long as the IETF 
> and
> has not designated the space Unicast Address Space to be delegated to the
> RIRs for allocation/assignment, IANA will not delegate it to the RIRs and the 
> RIRs
> won’t, therefore, delegate it to users.
> 
> If you really want to see this happen (and I still argue that the amount of 
> effort already wasted
> discussing this idea vastly exceeds what would be needed towards IPv6 to get 
> beyond
> caring about it), then the first step must be to convince the IETF to 
> designate the
> space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the 
> RIRs.
> 
> Once that happens, the rest of the allocation process is basically automatic. 
> From a policy
> perspective at the RIR level, it will be no different than say 4/8 or 1/8.

Actually it would be fundamentally different to 4/8 or 1/8.  You are looking at 
firmware upgrades
rather than dealing with squatters and out-of-date ACLs both of which are 
self-inflicted by one
of the parties.  Routers and end devices that don’t know how to hand 240/4 are 
no self inflicted
injuries.  Issuing 4/8 or 1/8 worked for parties that had been following the 
rules.  With 240/4
there where no rules to follow which results in RIR’s leasing known defective 
addresses.

> Now, convincing vendors to update their firmware, software, etc. is another 
> matter
> and entirely outside of the control of the RIRs. Merchant compliance with 
> IETF standards
> is generally considered useful, but it is entirely voluntary and even in the 
> best of
> circumstances doesn’t every happen instantaneously and almost always involves
> some stumbles along the way.
> 
> Owen
> 
> 
>> On Mar 15, 2022, at 02:54 , Sylvain Baya  wrote:
>> 
>> Dear NANOG-ers,
>> Hope this email finds you in good health!
>> Please see my comments below, inline...
>> 
>> Le mardi 15 mars 2022,  a écrit :
>> 
>> 
>> Hi Barry,
>> Thanks for your email, brother!
>> 
>>  
>> But the RIRs are the ones fielding requests for IPv4 space, and have
>> some notion of how policy implementation might work in practice, so
>> should have a lot of useful input.
>> 
>> 
>> ...of course, it appears that RIRs have the opportunity
>>  to add their useful inputs, as Impact Analysis Report
>>  (IAR); during the Policy Development Process (PDP)
>>  initiated by the *appropriate* [1] Internet community.
>> They explain it themselves here [2].
>> __
>> [1]: 
>> [2]: 
>> 
>> Shalom,
>> --sb.
>> 
>>  
>> On March 14, 2022 at 00:45 niels=na...@bakker.net (Niels Bakker) wrote:
>>  > * b...@theworld.com (b...@theworld.com) [Mon 14 Mar 2022, 00:31 CET]:
>>  > >Personally I'd rather hear from the RIRs regarding the value or not 
>>  > >of making more IPv4 space such as 240/4 available. They're on the 
>>  > >front lines of this.
>>  > 
>>  > You've got your policy development process diagram upside down. The 
>>  > community decides what the RIRs implement. They're not in touch with 
>>  > merchant silicon manufacturers.
>>  > 
>>  > 
>>  >  -- Niels.
>> 
>> -- 
>> -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*
>> 
>> 
>> -- 
>> Best Regards !
>> __
>> baya.sylvain[AT cmNOG DOT cm]|
>> Subscribe to Mailing List: 
>> __
>> #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous 
>> tous! ‪#‎Amen‬!»
>> ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
>> «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire 
>> après TOI, ô DIEU!»(#Psaumes42:2)
>> 
>> 
> 

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

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Mark Andrews]

s,
>> 
>> Regards,
>> 
>> 
>> 
>> Abe (2022-03-14 14:39)
>> 
>> 
>> 
>> 
>> 
>> --
>> NANOG Digest, Vol 170, Issue 15
>> Message: 17
>> Date: Sun, 13 Mar 2022 21:26:11 -0700
>> From: Fred Baker 
>> 
>> 
>> To: "Abraham Y. Chen" 
>> 
>> , William Herrin
>>  
>> 
>> 
>> Cc: NANOG 
>> 
>> 
>> Subject: Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock
>> Message-ID: 
>> <79746dec-8c8b-4d6d-b1d6-cb0a0003a...@gmail.com>
>> 
>> Content-Type: text/plain;charset=us-ascii
>> 
>> On Mar 12, 2022, at 8:15 AM, Abraham Y. Chen 
>> 
>>  wrote:
>> 
>>> 2)On the other hand, there was a recent APNIC blog that specifically 
>>> reminded us of a fairly formal request for re-designating the 240/4 
>>> netblock back in 2008 (second grey background box). To me, this means 
>>> whether to change the 240/4 status is not an issue. The question is whether 
>>> we can identify an application that can maximize its impact.
>>> 
>>> 
>>> https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/
>>>   
>>> 
>> I think there might be value in reviewing the discussion of the related 
>> Internet Drafts
>> 
>> 
>> https://datatracker.ietf.org/doc/html/draft-deshpande-intarea-ipaddress-reclassification-03
>> https://mailarchive.ietf.org/arch/search/?q=draft-deshpande-intarea-ipaddress-reclassification
>> 
>> 
>> 
>> https://datatracker.ietf.org/doc/html/draft-wilson-class-e-02
>> https://mailarchive.ietf.org/arch/search/?q=draft-wilson-class-e
>> 
>> 
>> 
>> https://datatracker.ietf.org/doc/html/draft-fuller-240space-02
>> https://mailarchive.ietf.org/arch/search/?q=draft-fuller-240space
>> 
>> 
>> The walkaway I had from these discussions was that while changing the 
>> definition of the address space would allow RIRs to sell more IPv4 address 
>> space for a few weeks (such as happened to APNIC when the last /8's were 
>> handed out), there were not enough addresses in the identified pools to 
>> solve the address shortage. So it was in the end a fool's errand. If you 
>> want to have address space to address the current shortage, you need an 
>> addressing architecture with more addresses. 
>> 
>> I was there for those discussions, and I'm not sure how to put it more 
>> simply.
>> 
>> --
>> 
>> 
>>  Virus-free. www.avast.com
> 
> 

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

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Abraham Y. Chen]

Hi, Tom:

1)    "  better to have that conversation via the appropriate IETF 
channels. ": Thanks for the recommendation. I would appreciate very much 
if you could guide us to the specific contact. Before we attempt to do 
so, however, it would be prudent to report the history of our team's 
experience:


    A.    The first IETF Draft on EzIP Project started from 2016-12 as 
instructed by the ISE (Independent Submission Editor). Although, at that 
time Working Group SunSet4 had been in session for awhile. But, we were 
not aware of, nor being informed about such.


    B.    In Summer of 2018, we discovered that SunSet4 had Concluded. 
We contacted the person in charge of keeping an eye on possible future 
IPv4 activities, but did not receive any instruction to revise our course.


    C.    Recently, we were made aware of the Int-Area activities. 
Attempts to reach the Group Chairs have not received any responses.


    D.    I just received an Int-Area Digest Vol 199, Issue 14 
requesting IETF to reactivate the IPv4 support.


    Hope you can help us to close the loose ends.

2)    In the meantime, we realized that the simplest implementation of 
the EzIP proposal is to replace the 100.64/10 netblock used by CG-NAT 
with the 240/4 netblock. Next, taking advantage of the much larger 
address pool to begin practicing static address assignment related 
disciplines, a "packetized PSTN" is realized. From such a base, the EzIP 
powered CG-NAT behaving as an overlay network in parallel to the 
existing Internet for providing the same services, many of the drawbacks 
in the latter are mitigated! So, we decided to discuss the EzIP proposal 
directly with the NANOG colleagues, because the EzIP deployment can 
actually be rather stealthy.


I look forward to your thoughts.

Regards,


Abe (2022-03-15 16:26)



On 2022-03-14 14:48, Tom Beecher wrote:
If you want to garner discussion or support for your draft RFC, it's 
probably better to have that conversation via the appropriate IETF 
channels.


On Mon, Mar 14, 2022 at 2:43 PM Abraham Y. Chen  wrote:

Hi, Fred:

0)    Thank you for a set of references.

1)    We cited only one IETF Draft (Wilson, et al.) among them,
because it was the first and only one that clearly stated its
limitation (Section 2. Caveats of Use). More importantly, it was
written by three top APNIC officials. Later efforts on this topic
have not introduced (based on my reading) any more essence to the
topic.

2)    "...  I was there for those discussions, and I'm not sure
how to put it more simply   ":    With your knowledge of the
past, you are uniquely qualified to critique on our work. However,
it would be more expedient for everyone, if you could first read
through at least the Abstract and the Conclusions of the EzIP IETF
Draft, before commenting. This is because EzIP proposal is based
on the same general idea as the references you cited, but with a
slight extra step that produced a series of surprising results. In
particular, we took the "Caveats" above to our hearts before
proceeding. So, please put such issues behind you while reviewing
our work. Thanks,

Regards,


Abe (2022-03-14 14:39)



-- NANOG Digest, Vol 170, Issue 15
Message: 17 Date: Sun, 13 Mar 2022 21:26:11 -0700 From: Fred Baker
 <mailto:fredbaker.i...@gmail.com> To:
"Abraham Y. Chen"  <mailto:ayc...@avinta.com>,
William Herrin  <mailto:b...@herrin.us> Cc: NANOG
 <mailto:nanog@nanog.org> Subject: Re:
202203071610.AYC Re: Making Use of 240/4 NetBlock Message-ID:
<79746dec-8c8b-4d6d-b1d6-cb0a0003a...@gmail.com>
<mailto:79746dec-8c8b-4d6d-b1d6-cb0a0003a...@gmail.com>
Content-Type: text/plain; charset=us-ascii On Mar 12, 2022, at
8:15 AM, Abraham Y. Chen 
<mailto:ayc...@avinta.com> wrote:


2)On the other hand, there was a recent APNIC blog that specifically 
reminded us of a fairly formal request for re-designating the 240/4 netblock 
back in 2008 (second grey background box). To me, this means whether to change 
the 240/4 status is not an issue. The question is whether we can identify an 
application that can maximize its impact.

 https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/   


I think there might be value in reviewing the discussion of the related 
Internet Drafts


https://datatracker.ietf.org/doc/html/draft-deshpande-intarea-ipaddress-reclassification-03

https://mailarchive.ietf.org/arch/search/?q=draft-deshpande-intarea-ipaddress-reclassification

https://datatracker.ietf.org/doc/html/draft-wilson-class-e-02
https://mailarchive.ietf.org/arch/search/?q=draft-wilson-class-e

https://datatracker.ietf.org/doc/html/draft-fuller-240space-02
https://mailarchive.ietf.org/arch/search/?q=draft-fuller-240

Re: Not Making Use of 240/4 NetBlock

[Owen DeLong via NANOG]

Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able
to claim some detailed knowledge on the subject.

In general, the RIRs themselves maintain neutrality about such things, looking 
to their
respective communities for input on what to do. However, so long as the IETF and
has not designated the space Unicast Address Space to be delegated to the
RIRs for allocation/assignment, IANA will not delegate it to the RIRs and the 
RIRs
won’t, therefore, delegate it to users.

If you really want to see this happen (and I still argue that the amount of 
effort already wasted
discussing this idea vastly exceeds what would be needed towards IPv6 to get 
beyond
caring about it), then the first step must be to convince the IETF to designate 
the
space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the RIRs.

Once that happens, the rest of the allocation process is basically automatic. 
From a policy
perspective at the RIR level, it will be no different than say 4/8 or 1/8.

Now, convincing vendors to update their firmware, software, etc. is another 
matter
and entirely outside of the control of the RIRs. Merchant compliance with IETF 
standards
is generally considered useful, but it is entirely voluntary and even in the 
best of
circumstances doesn’t every happen instantaneously and almost always involves
some stumbles along the way.

Owen


> On Mar 15, 2022, at 02:54 , Sylvain Baya  wrote:
> 
> Dear NANOG-ers,
> Hope this email finds you in good health!
> Please see my comments below, inline...
> 
> Le mardi 15 mars 2022, mailto:b...@theworld.com>> a écrit 
> :
> 
> 
> Hi Barry,
> Thanks for your email, brother!
> 
>  
> But the RIRs are the ones fielding requests for IPv4 space, and have
> some notion of how policy implementation might work in practice, so
> should have a lot of useful input.
> 
> 
> ...of course, it appears that RIRs have the opportunity
>  to add their useful inputs, as Impact Analysis Report
>  (IAR); during the Policy Development Process (PDP)
>  initiated by the *appropriate* [1] Internet community.
> They explain it themselves here [2].
> __
> [1]:  >
> [2]:  >
> 
> Shalom,
> --sb.
> 
>  
> On March 14, 2022 at 00:45 niels=na...@bakker.net  
> (Niels Bakker) wrote:
>  > * b...@theworld.com  (b...@theworld.com 
> ) [Mon 14 Mar 2022, 00:31 CET]:
>  > >Personally I'd rather hear from the RIRs regarding the value or not 
>  > >of making more IPv4 space such as 240/4 available. They're on the 
>  > >front lines of this.
>  > 
>  > You've got your policy development process diagram upside down. The 
>  > community decides what the RIRs implement. They're not in touch with 
>  > merchant silicon manufacturers.
>  > 
>  > 
>  >  -- Niels.
> 
> -- 
> -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*
> 
> 
> -- 
> Best Regards !
> __
> baya.sylvain[AT cmNOG DOT cm]| >
> Subscribe to Mailing List:  >
> __
> #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous 
> tous! ‪#‎Amen‬!»
> ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
> «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire 
> après TOI, ô DIEU!»(#Psaumes42:2)
> 
> 

Not Making Use of 240/4 NetBlock

[Sylvain Baya]

Dear NANOG-ers,
Hope this email finds you in good health!
Please see my comments below, inline...

Le mardi 15 mars 2022,  a écrit :

>
>
Hi Barry,
Thanks for your email, brother!



> But the RIRs are the ones fielding requests for IPv4 space, and have
> some notion of how policy implementation might work in practice, so
> should have a lot of useful input.
>
>
...of course, it appears that RIRs have the opportunity
 to add their useful inputs, as Impact Analysis Report
 (IAR); during the Policy Development Process (PDP)
 initiated by the *appropriate* [1] Internet community.
They explain it themselves here [2].
__
[1]: 
[2]: 

Shalom,
--sb.



> On March 14, 2022 at 00:45 niels=na...@bakker.net (Niels Bakker) wrote:
>  > * b...@theworld.com (b...@theworld.com) [Mon 14 Mar 2022, 00:31 CET]:
>  > >Personally I'd rather hear from the RIRs regarding the value or not
>  > >of making more IPv4 space such as 240/4 available. They're on the
>  > >front lines of this.
>  >
>  > You've got your policy development process diagram upside down. The
>  > community decides what the RIRs implement. They're not in touch with
>  > merchant silicon manufacturers.
>  >
>  >
>  >  -- Niels.
>
> --
> -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*
>


-- 

Best Regards !
__
baya.sylvain[AT cmNOG DOT cm]|
Subscribe to Mailing List: 
__
#‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous
tous! ‪#‎Amen‬!»
‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
«Comme une biche soupire après des courants d’eau, ainsi mon âme soupire
après TOI, ô DIEU!»(#Psaumes42:2)

Re: Not Making Use of 240/4 NetBlock

[bzs]

But the RIRs are the ones fielding requests for IPv4 space, and have
some notion of how policy implementation might work in practice, so
should have a lot of useful input.

On March 14, 2022 at 00:45 niels=na...@bakker.net (Niels Bakker) wrote:
 > * b...@theworld.com (b...@theworld.com) [Mon 14 Mar 2022, 00:31 CET]:
 > >Personally I'd rather hear from the RIRs regarding the value or not 
 > >of making more IPv4 space such as 240/4 available. They're on the 
 > >front lines of this.
 > 
 > You've got your policy development process diagram upside down. The 
 > community decides what the RIRs implement. They're not in touch with 
 > merchant silicon manufacturers.
 > 
 > 
 >  -- Niels.

-- 
-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: Making Use of 240/4 NetBlock Re: 202203141407.AYC

[Tom Beecher]

If you want to garner discussion or support for your draft RFC, it's
probably better to have that conversation via the appropriate IETF
channels.

On Mon, Mar 14, 2022 at 2:43 PM Abraham Y. Chen  wrote:

> Hi, Fred:
>
> 0)Thank you for a set of references.
>
> 1)We cited only one IETF Draft (Wilson, et al.) among them, because it
> was the first and only one that clearly stated its limitation (Section 2.
> Caveats of Use). More importantly, it was written by three top APNIC
> officials. Later efforts on this topic have not introduced (based on my
> reading) any more essence to the topic.
>
> 2)"...  I was there for those discussions, and I'm not sure how to put
> it more simply   ":With your knowledge of the past, you are
> uniquely qualified to critique on our work. However, it would be more
> expedient for everyone, if you could first read through at least the
> Abstract and the Conclusions of the EzIP IETF Draft, before commenting.
> This is because EzIP proposal is based on the same general idea as the
> references you cited, but with a slight extra step that produced a series
> of surprising results. In particular, we took the "Caveats" above to our
> hearts before proceeding. So, please put such issues behind you while
> reviewing our work. Thanks,
>
> Regards,
>
>
> Abe (2022-03-14 14:39)
>
>
>
> --
> NANOG Digest, Vol 170, Issue 15
> Message: 17
> Date: Sun, 13 Mar 2022 21:26:11 -0700
> From: Fred Baker  
> To: "Abraham Y. Chen"  , William Herrin
>
> Cc: NANOG  
> Subject: Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock
> Message-ID: <79746dec-8c8b-4d6d-b1d6-cb0a0003a...@gmail.com> 
> <79746dec-8c8b-4d6d-b1d6-cb0a0003a...@gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Mar 12, 2022, at 8:15 AM, Abraham Y. Chen  
>  wrote:
>
> 2)On the other hand, there was a recent APNIC blog that specifically 
> reminded us of a fairly formal request for re-designating the 240/4 netblock 
> back in 2008 (second grey background box). To me, this means whether to 
> change the 240/4 status is not an issue. The question is whether we can 
> identify an application that can maximize its impact.
>
> https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/
>
> I think there might be value in reviewing the discussion of the related 
> Internet Drafts
> https://datatracker.ietf.org/doc/html/draft-deshpande-intarea-ipaddress-reclassification-03https://mailarchive.ietf.org/arch/search/?q=draft-deshpande-intarea-ipaddress-reclassification
> https://datatracker.ietf.org/doc/html/draft-wilson-class-e-02https://mailarchive.ietf.org/arch/search/?q=draft-wilson-class-e
> https://datatracker.ietf.org/doc/html/draft-fuller-240space-02https://mailarchive.ietf.org/arch/search/?q=draft-fuller-240space
>
> The walkaway I had from these discussions was that while changing the 
> definition of the address space would allow RIRs to sell more IPv4 address 
> space for a few weeks (such as happened to APNIC when the last /8's were 
> handed out), there were not enough addresses in the identified pools to solve 
> the address shortage. So it was in the end a fool's errand. If you want to 
> have address space to address the current shortage, you need an addressing 
> architecture with more addresses.
>
> I was there for those discussions, and I'm not sure how to put it more simply.
>
> --
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=link>
> <#m_-3820859315811704609_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: Making Use of 240/4 NetBlock Re: 202203141407.AYC

[Abraham Y. Chen]

Hi, Fred:

0)    Thank you for a set of references.

1)    We cited only one IETF Draft (Wilson, et al.) among them, because 
it was the first and only one that clearly stated its limitation 
(Section 2. Caveats of Use). More importantly, it was written by three 
top APNIC officials. Later efforts on this topic have not introduced 
(based on my reading) any more essence to the topic.


2)    "...  I was there for those discussions, and I'm not sure how to 
put it more simply   ":    With your knowledge of the past, you are 
uniquely qualified to critique on our work. However, it would be more 
expedient for everyone, if you could first read through at least the 
Abstract and the Conclusions of the EzIP IETF Draft, before commenting. 
This is because EzIP proposal is based on the same general idea as the 
references you cited, but with a slight extra step that produced a 
series of surprising results. In particular, we took the "Caveats" above 
to our hearts before proceeding. So, please put such issues behind you 
while reviewing our work. Thanks,


Regards,


Abe (2022-03-14 14:39)



-- NANOG Digest, Vol 170, Issue 15 Message: 
17 Date: Sun, 13 Mar 2022 21:26:11 -0700 From: Fred Baker 
 To: "Abraham Y. Chen" , 
William Herrin  Cc: NANOG  Subject: Re: 
202203071610.AYC Re: Making Use of 240/4 NetBlock Message-ID: 
<79746dec-8c8b-4d6d-b1d6-cb0a0003a...@gmail.com> Content-Type: 
text/plain; charset=us-ascii On Mar 12, 2022, at 8:15 AM, Abraham Y. 
Chen  wrote:



2)On the other hand, there was a recent APNIC blog that specifically 
reminded us of a fairly formal request for re-designating the 240/4 netblock 
back in 2008 (second grey background box). To me, this means whether to change 
the 240/4 status is not an issue. The question is whether we can identify an 
application that can maximize its impact.

 https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/   


I think there might be value in reviewing the discussion of the related 
Internet Drafts

https://datatracker.ietf.org/doc/html/draft-deshpande-intarea-ipaddress-reclassification-03
https://mailarchive.ietf.org/arch/search/?q=draft-deshpande-intarea-ipaddress-reclassification

https://datatracker.ietf.org/doc/html/draft-wilson-class-e-02
https://mailarchive.ietf.org/arch/search/?q=draft-wilson-class-e

https://datatracker.ietf.org/doc/html/draft-fuller-240space-02
https://mailarchive.ietf.org/arch/search/?q=draft-fuller-240space

The walkaway I had from these discussions was that while changing the 
definition of the address space would allow RIRs to sell more IPv4 address 
space for a few weeks (such as happened to APNIC when the last /8's were handed 
out), there were not enough addresses in the identified pools to solve the 
address shortage. So it was in the end a fool's errand. If you want to have 
address space to address the current shortage, you need an addressing 
architecture with more addresses.

I was there for those discussions, and I'm not sure how to put it more simply.

--


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

Re: V6 still not supported (was Re: CC: s to Non List, Members, (was Making Use of 240/4, NetBlock))

[Abraham Y. Chen]

 IPv4 and 
IPv6 could be different from the bulk in the core. However, one 
historical event (see URL below) hints that the IPv6 traffic on AMS-IX 
should have been even lower than what is reported if its peering 
agreements had been settled in a similar manner as those for IPv4.


https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/

Hope this run-down of background and history enable us to synchronize 
our perspective of the IPv6 status.



Regards,


Abe (2022-03-14 14:04)



--
NANOG Digest, Vol 170, Issue 15
Message: 15
Date: Sun, 13 Mar 2022 21:06:51 -0700
From: Fred Baker
To: Joe Maimon, "Chen, Abraham Y."
, "Abraham Y. Chen", Ca By

Cc: NANOG
Subject: Re: V6 still not supported (was Re: CC: s to Non List
Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use
of 240/4, NetBlock))
Message-ID:<7e0b159f-43ac-4507-8fb9-3120b2b90...@gmail.com>
Content-Type: text/plain;   charset=us-ascii


On Mar 11, 2022, at 8:39 AM, Joe Maimon  wrote:

Google's statistics...


I'm not sure which of you I'm replying to. The comment was made on NANOG the 
other day that we should discount Google statistics because they have been 
promoting IPv6 for a decade. It's true that they have been doing so. But they 
aren't the only people with statistics.

https://www.vyncke.org/ipv6status/compare.php?metric=p=in,my,sa,be,de,fr,gr,vn,tw,gf,zz,us,jp,th,br,mx,ae,lk,uy,hu,lu,fi,il,pt,gt,ch,gp,gb,mq,nl,ca,ee,ec,re,au,np,tt,at,ro,ga,ie,no,gy,bt,py,pe,kw,sx,mm,nz,co,cz,bo,ni,tg,ph,pl,sg,is,ar,kr,om,cl,sv,jm,si,mo,se,lv,jo,cg,ba,lc,zw,ir,id,md,hn,by,sk,al,rw,pf,ge,bz,dk,ru,hr,rs,it,vc,ke

You might look at the following links. Eric Vyncke has been putting up charts 
basically on Google, Akamai, and APNIC statistics for a while. One thing to 
consider is that around 90 countries (92 in this capture, as low as 89 a couple 
of days ago) have 5% or greater response rate using IPv6. Google and Akamai 
have their own content networks, and in at least some countries only 
externalize  records or respond to IPv6 requests. APNI isn't that way; they 
don't operate a content network, but rather accept traffic from across the 
backbone. Consider that a content network essentially reports traffic from a 
customer network to their first hop ISP, while when APNIC reports an IPv6 
access, the father form APNIC to the collector in question has to include every 
network and every router in the path. Now look at these:

https://www.vyncke.org/ipv6status/compare.php?metric=p=in
https://www.vyncke.org/ipv6status/compare.php?metric=k=in
https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=IN

I think the APNIC numbers demonstrate that paths through the backbone generally 
support IPv6 end to end, and that from a routing perspective there is no reason 
to favor IPv4.

There are 8 Countries (this evening) that Google reports roughly equal response 
rates from using IPv4 or IPv6. 
cfhttps://www.vyncke.org/ipv6status/compare.php?metric=p=in,my,sa,be,de,fr,gr,vn.
 This doesn't prove that IPv6 has taken over the world, but it does prove that 
those who would discount available statistics sources are a little too shrill in 
doing so.

Where IPv6 has a problem today is with enterprise. IMHO, this is basically 
because enterprise is looking at the bottom line. If ISPs were to do what 
Mythic Beasts says they do, which is charge their users for address space, IPv6 
is virtually free while IPv4 costs something. I suspect that enterprise would 
change its tune dramatically.

--


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

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Daniel Karrenberg]

On 14-03-2022 05:06, Fred Baker wrote:

... Where IPv6 has a problem today is with enterprise. IMHO, this is basically 
because enterprise is looking at the bottom line. If ISPs were to do what 
Mythic Beasts says they do, which is charge their users for address space, IPv6 
is virtually free while IPv4 costs something. I suspect that enterprise would 
change its tune dramatically. ...


This has already started to happen. For example my preferred hosting 
provider recently made the IPv4 address a line item on their invoices. 
The total price did not change. Customers can now save money by electing 
not to use IPv4. This makes sense for both the supplier and the customer 
and it will happen more and more. The cost of clinging to IPv4 will rise 
and it will become more visible.


Daniel

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[Fred Baker]

On Mar 12, 2022, at 8:15 AM, Abraham Y. Chen  wrote:
> 
> 2)On the other hand, there was a recent APNIC blog that specifically 
> reminded us of a fairly formal request for re-designating the 240/4 netblock 
> back in 2008 (second grey background box). To me, this means whether to 
> change the 240/4 status is not an issue. The question is whether we can 
> identify an application that can maximize its impact.
> 
> https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/  

I think there might be value in reviewing the discussion of the related 
Internet Drafts

https://datatracker.ietf.org/doc/html/draft-deshpande-intarea-ipaddress-reclassification-03
https://mailarchive.ietf.org/arch/search/?q=draft-deshpande-intarea-ipaddress-reclassification

https://datatracker.ietf.org/doc/html/draft-wilson-class-e-02
https://mailarchive.ietf.org/arch/search/?q=draft-wilson-class-e

https://datatracker.ietf.org/doc/html/draft-fuller-240space-02
https://mailarchive.ietf.org/arch/search/?q=draft-fuller-240space

The walkaway I had from these discussions was that while changing the 
definition of the address space would allow RIRs to sell more IPv4 address 
space for a few weeks (such as happened to APNIC when the last /8's were handed 
out), there were not enough addresses in the identified pools to solve the 
address shortage. So it was in the end a fool's errand. If you want to have 
address space to address the current shortage, you need an addressing 
architecture with more addresses. 

I was there for those discussions, and I'm not sure how to put it more simply.

Re: Making Use of 240/4 NetBlock Re: 202203140004.AYC

[Abraham Y. Chen]

Hi, John:

0)    Thanks for your comments.

1)    Re: Ur. Pt. 1): I have recently been informed of such activities. 
So far, my attempt to submit a draft and to reach the group chairs have 
not been successful.


2)    Re: Ur. Pt. 2): Our work looks very much inline with your Unicast 
project. My quick reaction is that EzIP appears to be a practical 
application that can benefit from your proposal. Although we further 
limit the application of 240/4 netblock to be "on-premises" (from the 
Internet core's perspective) use, the scheme of the EzIP deployment 
actually makes the scope bigger. Since I am not very familiar with the 
terminologies, does this interpretation make any sense? Please comment.


Regards,


Abe (2022-03-14 00:22)




On 2022-03-12 23:26, John Gilmore wrote:

Abraham Y. Chen  wrote:

1)    Thanks for confirming my understanding of the 240/4 history.
Basically, those in charge of the Internet appear to be leaving the
community in the state of informal debates, since there is no more
formal IPv4 working group.

There is one; it's called "intarea" and is a working group of the IETF.


2)    On the other hand, there was a recent APNIC blog that specifically
reminded us of a fairly formal request for re-designating the 240/4
netblock back in 2008 (second grey background box). To me, this means
whether to change the 240/4 status is not an issue. The question is
whether we can identify an application that can maximize its impact.

https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/

Please read our recent Internet-Draft on the subject:

   https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/

In section 2, you will find references to all the previous allocations
(and requests for allocation) of the 240/4 address block.

John




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

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Fred Baker]

> On Mar 11, 2022, at 8:39 AM, Joe Maimon  wrote:
> 
> Google's statistics...

I'm not sure which of you I'm replying to. The comment was made on NANOG the 
other day that we should discount Google statistics because they have been 
promoting IPv6 for a decade. It's true that they have been doing so. But they 
aren't the only people with statistics.

https://www.vyncke.org/ipv6status/compare.php?metric=p=in,my,sa,be,de,fr,gr,vn,tw,gf,zz,us,jp,th,br,mx,ae,lk,uy,hu,lu,fi,il,pt,gt,ch,gp,gb,mq,nl,ca,ee,ec,re,au,np,tt,at,ro,ga,ie,no,gy,bt,py,pe,kw,sx,mm,nz,co,cz,bo,ni,tg,ph,pl,sg,is,ar,kr,om,cl,sv,jm,si,mo,se,lv,jo,cg,ba,lc,zw,ir,id,md,hn,by,sk,al,rw,pf,ge,bz,dk,ru,hr,rs,it,vc,ke

You might look at the following links. Eric Vyncke has been putting up charts 
basically on Google, Akamai, and APNIC statistics for a while. One thing to 
consider is that around 90 countries (92 in this capture, as low as 89 a couple 
of days ago) have 5% or greater response rate using IPv6. Google and Akamai 
have their own content networks, and in at least some countries only 
externalize  records or respond to IPv6 requests. APNI isn't that way; they 
don't operate a content network, but rather accept traffic from across the 
backbone. Consider that a content network essentially reports traffic from a 
customer network to their first hop ISP, while when APNIC reports an IPv6 
access, the father form APNIC to the collector in question has to include every 
network and every router in the path. Now look at these:

https://www.vyncke.org/ipv6status/compare.php?metric=p=in
https://www.vyncke.org/ipv6status/compare.php?metric=k=in
https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=IN

I think the APNIC numbers demonstrate that paths through the backbone generally 
support IPv6 end to end, and that from a routing perspective there is no reason 
to favor IPv4.

There are 8 Countries (this evening) that Google reports roughly equal response 
rates from using IPv4 or IPv6. cf 
https://www.vyncke.org/ipv6status/compare.php?metric=p=in,my,sa,be,de,fr,gr,vn.
 This doesn't prove that IPv6 has taken over the world, but it does prove that 
those who would discount available statistics sources are a little too shrill 
in doing so.

Where IPv6 has a problem today is with enterprise. IMHO, this is basically 
because enterprise is looking at the bottom line. If ISPs were to do what 
Mythic Beasts says they do, which is charge their users for address space, IPv6 
is virtually free while IPv4 costs something. I suspect that enterprise would 
change its tune dramatically.

Re: Making Use of 240/4 NetBlock

[Christopher Morrow]

On Sun, Mar 13, 2022 at 7:55 PM William Herrin  wrote:

> On Sun, Mar 13, 2022 at 12:29 PM Christopher Morrow
>  wrote:
> > What's the actual proposal for 240/4?
> > Is it: "Make this usable by me on my /intranet/?"
> > Is it: "Make this usable across the internet between bespoke endpoints?"
> > Is it: "Make this usable for any services/users on the wider internet,
> treat it like any other unicast ipv4 address?"
>
> Hi Chris,
>
> I can't speak for anyone else but my proposal is: (A) do the
> standards-level activity which is common to all three proposals, (B)
> give the vendors a couple years to catch up to the new standard, and
> then (C) pick a next step based on what's then the operational
> reality.
>
> The standards-level activity common to all three proposals is:
>
> 1. Define 240/4 excluding 255.255.255.255/32 as unicast addresses (no
> longer "undefined" future use) but continue holding them in reserve.
> 2. Advise hardware and software vendors to treat 240/4 as unicast when
> configured by the user or received by protocol.
> 3. Stop.
>
>
ok, sounds interesting/ok to me :)
I was mostly wondering about the endgame, the 'reason' for the proposal(s)
that keep coming up.

One version of them is: "well, that's 16 /8's!!! think of the ipv4 market!"
(or similar)
I don't think it's particularly productive to wait on 16 /8's which really
are a 1.5 yr lengthening
of the v4 runway/landing-strip. I get that we'll be doing ipv4 things at
scale for at
least a decade more, but even the most generous reading of your 'do
standads, get
vendors, let rolllout happen'  is, I think at least 10 yrs away as well.

using the space intenrally kinda already works... having some standards
action that
said: "err, this is rfc1918-like space" would help internal uses. Not
having that means
that you are (as a deployer of 240/4 internally) constantly ~1 IANA/RIR
decision away
from not being able ot route to parts of the internet.

-chris

Re: Making Use of 240/4 NetBlock

[William Herrin]

On Sun, Mar 13, 2022 at 12:29 PM Christopher Morrow
 wrote:
> What's the actual proposal for 240/4?
> Is it: "Make this usable by me on my /intranet/?"
> Is it: "Make this usable across the internet between bespoke endpoints?"
> Is it: "Make this usable for any services/users on the wider internet, treat 
> it like any other unicast ipv4 address?"

Hi Chris,

I can't speak for anyone else but my proposal is: (A) do the
standards-level activity which is common to all three proposals, (B)
give the vendors a couple years to catch up to the new standard, and
then (C) pick a next step based on what's then the operational
reality.

The standards-level activity common to all three proposals is:

1. Define 240/4 excluding 255.255.255.255/32 as unicast addresses (no
longer "undefined" future use) but continue holding them in reserve.
2. Advise hardware and software vendors to treat 240/4 as unicast when
configured by the user or received by protocol.
3. Stop.

Regards,
Bill Herrin

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

Re: Not Making Use of 240/4 NetBlock

[Niels Bakker]

* b...@theworld.com (b...@theworld.com) [Mon 14 Mar 2022, 00:31 CET]:
Personally I'd rather hear from the RIRs regarding the value or not 
of making more IPv4 space such as 240/4 available. They're on the 
front lines of this.


You've got your policy development process diagram upside down. The 
community decides what the RIRs implement. They're not in touch with 
merchant silicon manufacturers.



-- Niels.

Re: Not Making Use of 240/4 NetBlock

[bzs]

Personally I'd rather hear from the RIRs regarding the value or not of
making more IPv4 space such as 240/4 available. They're on the front
lines of this.

I think sometimes what we're manipulating in these debates is the time
factor: Someone with a worthy, immediate, urgent need versus some
distant horizon which might be preferable in the big picture but is
demanding possibly unreasonable sacrifices of some in the short term.

I don't believe we are pondering making this IPv4 space available and
then returning to the 1980s/1990s relative free-for-all.

This all might be more interesting if driven by consideration of those
needs.

On March 13, 2022 at 13:54 jo...@iecc.com (John Levine) wrote:
 > It appears that Joe Maimon  said:
 > >Saku Ytti wrote:
 > >> What if many/most large CDN, cloud, tier1 would commonly announce a 
 > >> plan to drop all IPv4 at their edge 20 years from now? How would that 
 > >> change our work? What would we stop doing and what would we start doing? 
 > >
 > >I cant see how it would change or do anything IPv6-related for myself 
 > >for at least 19 years. And I suspect most others would fall somewhere 
 > >between that and never.
 > 
 > Yet the four largest cable networks and all of the mobile networks in the
 > US have had full IPv6 support for years as do AWS, Google, Azure, Digital
 > Ocean, Linode, and many other hosting providers.
 > 
 > Could you explain what "most" means where you are?
 > 
 > R's,
 > John

-- 
-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: Making Use of 240/4 NetBlock

[Joe Maimon]

Christopher Morrow wrote:



On Sun, Mar 13, 2022 at 10:39 AM William Herrin > wrote:


On Sun, Mar 13, 2022 at 1:22 AM Joe Maimon mailto:jmai...@jmaimon.com>> wrote:
> The true dilemma is that any amelioration of IPv4 scarcity may
indeed
> contribute to further delaying mass global IPv6 adoption,
regardless of
> whose effort and time is involved.


What's the actual proposal for 240/4?
Is it: "Make this usable by me on my /intranet/?"
Is it: "Make this usable across the internet between bespoke endpoints?"
Is it: "Make this usable for any services/users on the wider internet, 
treat it like any other unicast ipv4 address?"

Is it: "Something entirely different"

The first 2 probably already work today, if you take the time to 
control the horizontal and vertical of your networking space.
The last is probably workable, given enough time to flush out all of 
the endpoints which (today) probably treat 240/4 as 'special'.


240/4 has a special problem. The problem is that the smallest bit of 
cooperation from the broader community, other than those expending 
effort on 240/4 directly is required.


Mostly so that any potential use of 240/4 continues to be standardized. 
Which in theory, is in all parties best interest.


I think the current draft pretty much wanted a word or two changed.



So.. to move forward with 240/4 on the wider internet you'd need a 
bunch of software / hardware updates, and time for those to rollout.

Then you'd need sacrificial lambs in the user and service endpoints.


Nobody is asking for any assistance with that. It will happen or not 
based upon those who wish to expend effort on it. Apparently, most if it 
has already happened.




All of this to regain ~16 /8's worth of space (presuming you could use 
255/8?).


Really, so that anything standardized can be done with it, rather than 
nothing.


This is about extending some utilization capability of IPv4, but it is 
also about preserving standard driven behavior.


I think a /8 is 'free' on the internet for about a month, so 1.5 yrs 
of new address allocations, terrific?


That was the old paradigm, in the old days. Currently a /8 goes pretty 
far and its likely to only get further.




At the end of the day, again, almost all proposals to 'add more ipv4 
space' come down to 1 month per /8.

I think part of Jordi's point is:
  "Is that 1 month really worth the effort?


All the effort requested is for all those who think its wall head 
banging to say knock yourself out, we are unopposed to changing how IPv4 
obsolete addresses are managed because we have already bet on IPv6. Take 
whatever you want. Change whatever you want. We dont care.


Thats not a whole lot of effort being requested of the unwilling in 
exchange for their continued relevance. All the rest of the efforts are 
expected to come from the willing, able and ready. Not your concern.


But perhaps you do care. Why?

  is there a reason that all of the softare/hardware uplift and time 
to deploy is not being spent on v6?"


Perhaps you think that stymieing any effort on IPv4 is important to 
marshall the worlds attention to IPv6. Which if the shoe were on the 
other foot you would find galling and obnoxious.


There are many reasons why IPv6 hasnt done that all on its own and 
pretty much most if not all of them have nothing to do with 240/4


They have to do with IPv6. And we have heard them over and over again. 
Look inwards.


In short, IPv6 apparently keep losing to the cost vs. benefits analysis 
being performed by countless people in countless situations. You can 
claim that it should not, but that is not what is happening.


You cant make IPv4 more expensive than it already is doing all by 
itself. It is wrong to try. And apparently, its not expensive enough to 
drive mass adoption of v6, with any degree of alacrity.


v6 must have costs in contexts that have been under-addressed. Its time 
to knowledge them and perhaps work to address them.




At this point in our matrix timeline it seems to me that:
  "If you were going to deploy v6, you did... if you didn't oh, well.. 
eventually you will?"


Much like Itanium vs. amd64, there are other ways this can turn out, the 
longer it drags out. I think those ways are potentially more undesirable 
than extending IPv4 use in a standardized fashion now.




I'd prefer to not have to deploy  in a rush or on timelines I can't 
cointrol if I hadn't deployed already.
Will that timeline be 'soon' anytime soon? I don't know :( I think 
Grant's "not until i'm long retired" guess

is as good as any though :(

-chris


I for one would like to say I did all the tiny amount I conceivably 
could to leave the internet a better place than I found it.


And I think that means giving IPv4 all the runway it needs to properly 
decelerate to the fullest extent possible or at least not obstructing 
those who would try.


Remember, the dual stack migration was predicated on working v4. 

Re: Making Use of 240/4 NetBlock

[Christopher Morrow]

On Sun, Mar 13, 2022 at 10:39 AM William Herrin  wrote:

> On Sun, Mar 13, 2022 at 1:22 AM Joe Maimon  wrote:
> > The true dilemma is that any amelioration of IPv4 scarcity may indeed
> > contribute to further delaying mass global IPv6 adoption, regardless of
> > whose effort and time is involved.
>
>
What's the actual proposal for 240/4?
Is it: "Make this usable by me on my /intranet/?"
Is it: "Make this usable across the internet between bespoke endpoints?"
Is it: "Make this usable for any services/users on the wider internet,
treat it like any other unicast ipv4 address?"
Is it: "Something entirely different"

The first 2 probably already work today, if you take the time to control
the horizontal and vertical of your networking space.
The last is probably workable, given enough time to flush out all of the
endpoints which (today) probably treat 240/4 as 'special'.

So.. to move forward with 240/4 on the wider internet you'd need a bunch of
software / hardware updates, and time for those to rollout.
Then you'd need sacrificial lambs in the user and service endpoints.

All of this to regain ~16 /8's worth of space (presuming you could use
255/8?).
I think a /8 is 'free' on the internet for about a month, so 1.5 yrs of new
address allocations, terrific?

At the end of the day, again, almost all proposals to 'add more ipv4 space'
come down to 1 month per /8.
I think part of Jordi's point is:
  "Is that 1 month really worth the effort?
  is there a reason that all of the softare/hardware uplift and time to
deploy is not being spent on v6?"

At this point in our matrix timeline it seems to me that:
  "If you were going to deploy v6, you did... if you didn't oh, well..
eventually you will?"

I'd prefer to not have to deploy  in a rush or on timelines I can't
cointrol if I hadn't deployed already.
Will that timeline be 'soon' anytime soon? I don't know :( I think Grant's
"not until i'm long retired" guess
is as good as any though :(

-chris

Re: Not Making Use of 240/4 NetBlock

[Randy Bush]

> Yet the four largest cable networks and all of the mobile networks in the
> US have had full IPv6 support for years as do AWS, Google, Azure, Digital
> Ocean, Linode, and many other hosting providers.
> 
> Could you explain what "most" means where you are?

a vast number of large non-us mobile networks and non-us fixed eyeball
networks use cgn, sad to say.

as saku says, when v6 was 'designed', the expected transition time was
relatively short.  yes, they had negative ops clue; in fact, ops were
openly declared to be the enemy of the v6 'architects' (remember NLA and
TLA).  this led, among other things, to the short-sighted plan for dual
stack to be the only needed transition mechanism.  the first problem
with this is that it requires as much v4 space as v6 space, oops.  thus
was born the plethora of transition mechanisms.

imiho, v6 will continue to slowly deploy with some lulls and some
spurts.  and mailing list religious rants about it will continue
unabated.  in parallel, efforts to de-frag the v4 space are worthwhile,
though they will only slightly alleviate the v4 shortage.

we do what we can.  i only wish we would make less ineffective noise
about it.

randy

Re: Not Making Use of 240/4 NetBlock

[John Levine]

It appears that Joe Maimon  said:
>Saku Ytti wrote:
>> What if many/most large CDN, cloud, tier1 would commonly announce a 
>> plan to drop all IPv4 at their edge 20 years from now? How would that 
>> change our work? What would we stop doing and what would we start doing? 
>
>I cant see how it would change or do anything IPv6-related for myself 
>for at least 19 years. And I suspect most others would fall somewhere 
>between that and never.

Yet the four largest cable networks and all of the mobile networks in the
US have had full IPv6 support for years as do AWS, Google, Azure, Digital
Ocean, Linode, and many other hosting providers.

Could you explain what "most" means where you are?

R's,
John

Re: Making Use of 240/4 NetBlock

[William Herrin]

On Sun, Mar 13, 2022 at 1:22 AM Joe Maimon  wrote:
> The true dilemma is that any amelioration of IPv4 scarcity may indeed
> contribute to further delaying mass global IPv6 adoption, regardless of
> whose effort and time is involved.
>
> And I find advocating for that to be wrong and perhaps to some extent,
> immoral. Unlikely to be productive. And potentially counter-productive.

https://xkcd.com/2592/





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

Re: Making Use of 240/4 NetBlock

[Joe Maimon]

JORDI PALET MARTINEZ via NANOG wrote:

Because it is a single Internet, and what we do in some parts of Internet will 
affect others?

Because, at least in my case, I'm investing my efforts in what it seems to be 
the best in the long-term for the global community, not my personal preferences?


Improving IPv6? Keep up the good work and thank you.

Protesting IPv4 efforts? Not very altruistic, more like you are 
motivated by various deep-seated emotional responses to the continuation 
of the IPv4 internet.


  


El 12/3/22 9:10, "William Herrin"  escribió:


 Why are so many otherwise smart engineers so vulnerable to false
 dilemma style fallacies? There's no "either/or" here. It's not a zero
 sum game. If you don't see value in doing more with IPv4 then why
 don't you get out of the way of folks who do?

 Regards,
 Bill Herrin




The true dilemma is that any amelioration of IPv4 scarcity may indeed 
contribute to further delaying mass global IPv6 adoption, regardless of 
whose effort and time is involved.


And I find advocating for that to be wrong and perhaps to some extent, 
immoral. Unlikely to be productive. And potentially counter-productive.


Joe

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[Joe Maimon]

Saku Ytti wrote:
What if many/most large CDN, cloud, tier1 would commonly announce a 
plan to drop all IPv4 at their edge 20 years from now? How would that 
change our work? What would we stop doing and what would we start doing? 


I cant see how it would change or do anything IPv6-related for myself 
for at least 19 years. And I suspect most others would fall somewhere 
between that and never.


However, such an announcement would actually signal that we should do 
all those things now to IPv4 that will take 10 years to be useful, 
because then they will be useful for at least another 10 years.


Seriously, we have already had this sort of experiment play out numerous 
times, both with a governing body and without. We already know how it goes.


With a governing body: lack of progress right up until the deadline, 
gnashing of teeth ensues until deadline is extended, more often than not 
comprehensive conversion finally completes, later than scheduled.


Without: lack of progress right up to deadline, teeth gnashing, deadline 
is arbitrarily extended, nothing much changes and deadline is forgotten.


When IPv4 is properly obsoleted, we will see many of those announcements 
and some will matter and most wont. As it should be. However 
proclamations are not going to obsolete IPv4. As we have already seen.


I dont think advocating for large players to band together to form their 
own internet-ops standard body is going to save IPv6 and the internet. 
More likely it will doom both as we know it.


Here is an equally unlikely thought experiment.

What if many/most large CDN, cloud, tier1 would commonly announce a plan 
to compatibly extend IPv4, citing a lack of progress in IPv6 deployment 
and resulting IPv4 elimination as well as a stagnant stalemate on any 
such efforts within the would-be-relevant standard bodies?


Joe

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[Saku Ytti]

On Sat, 12 Mar 2022 at 18:19, Abraham Y. Chen  wrote:

> 3)" ... Changes to hardware and software to make use of 240/4 as ordinary 
> unicast IP addresses can and should proceed in parallel to such debate.  ":   
>   Agreed. Since through the EzIP Project, we have identified that the 
> hardware does not need change, and the software modification is minimal, we 
> should proceed to discuss what is the best application for the 240/4 
> netblock, after is re-classified as an ordinary unicast address pool.

It would surprise me greatly if there isn't hardware in the field
which physically cannot be retrofitted for 240/4, as we have a very
diverse set of hardware which very liberally makes assumptions of the
environment it will be in, to both reduce cost and to improve PPS.
These assumptions cause issues already in the environment they are in,
because engineers aren't always correct. It is crucial to understand
not all lookups are equal, and determinism isn't perfect, the devices
are not complex, but they are more complex than that.
And of course a lot more which by software do not, and will not, as
they've stopped receiving software updates. The marginal increase in
cost and effort in any of these cases between CPR and IPv6 is trivial.

Any narrative to prolong dual-stack with the argument 'it is just SW
update' is broken. Only reason we are not 100% IPv6 today, is because
we failed to foresee IPv6 won't take off, we all kind of assumed it
will of course happen organically in due time. I don't think anyone
really believed in 2002 that in 2022 we are still IPv4 and IPv6 is
after thought. And now we should understand, the organic market-driven
move to IPv6 may not ever happen, and are we going to accept all this
cost involved maintaining dual-stack or do we want to reduce CAPEX and
OPEX and have specific plans to return to single-stack world?

What if many/most large CDN, cloud, tier1 would commonly announce a
plan to drop all IPv4 at their edge 20 years from now? How would that
change our work? What would we stop doing and what would we start
doing?



-- 
  ++ytti

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Greg Skinner via NANOG]

I agree.  iMO, this 240/4 issue is another one of those tussles in cyberspace 
.   But I 
don’t fault IETF people or anyone else who pursues technical solutions to these 
types of problems as long as they are open and honest about the limitations of 
these solutions.

Also, IMO, the value of having a discussion about this issue here (and other 
NOG forums) is to get the perspective of people who (generally speaking) deal 
more immediately with the problems the broader “online" population has with 
IETF-based technology.

—gregbo

> On Mar 8, 2022, at 9:25 PM, b...@theworld.com wrote:
> 
> 
> I'm beginning to wonder if the internet will survive the ipv6 adoption
> debates.
> 
> Here's the real problem which you all can promptly ignore:
> 
> The IETF et al are full of bright technical people who can design
> protocols, packet formats, etc.
> 
> But many of the major problems facing the internet are not, at their
> core, engineering problems.
> 
> They're in the realm of social, legal, marketing, politics, int'l
> policy, governance, law enforcement, commerce, economics, sociology,
> psychology, etc. which TBH as bright as many of the engineers et al
> are these problems are way beyond their ken, occasional polymath
> excepted.
> 
> But first you have to admit you have a problem, and limitations.
> 
> Shouting at the rafters about address space depletion etc while waving
> RFCs may not quite do it.
> 
> Similar can be said about spam, malware attacks, phishing, etc.
> 
> Yet another cryptographic protocol probably won't save the day but as
> the expression goes when all you have is a hammer the whole world
> looks like a nail.
> 
> -- 
>-Barry Shein
> 
> Software Tool & Die| bzs at 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: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[Abraham Y. Chen]

Hi, Bill:

1)    Thanks for confirming my understanding of the 240/4 history. 
Basically, those in charge of the Internet appear to be leaving the 
community in the state of informal debates, since there is no more 
formal IPv4 working group.


2)    On the other hand, there was a recent APNIC blog that specifically 
reminded us of a fairly formal request for re-designating the 240/4 
netblock back in 2008 (second grey background box). To me, this means 
whether to change the 240/4 status is not an issue. The question is 
whether we can identify an application that can maximize its impact.


https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/

3)    " ... Changes to hardware and software to make use of 240/4 as 
ordinary unicast IP addresses can and should proceed in parallel to such 
debate. ":     Agreed. Since through the EzIP Project, we have 
identified that the hardware does not need change, and the software 
modification is minimal, we should proceed to discuss what is the best 
application for the 240/4 netblock, after is re-classified as an 
ordinary unicast address pool.


Regards,


Abe (2022-03-12 11:15)


On 2022-03-11 11:34, William Herrin wrote:

On Fri, Mar 11, 2022 at 6:36 AM Abraham Y. Chen  wrote:

1)Thanks for the reference. However, Informative Reference 7 of our IETF 
Draft cites another IANA document which puts the initial date of the 240/4 
topic back to 1981-09 which was much earlier, in fact, coincided with that of 
RFC 791.

Hi Abraham,

As I said, RFC1112 documents the _most recent_ standards action with
respect to 240/4. The earlier RFC 791 you mention described 224/3
(which included 240/4) as "escape to extended addressing mode" which
it specified as "undefined" and "reserved for future use." RFC 988
then redefined and split 224/3 into "class D" and "class E" addresses,
defined "class D" as multicast and "class E" as reserved for future
use without any particular purpose. This saw updates in RFC1112 which
has the current disposition of "class E" aka 240/4.

RFC 1112 spends a grand total of one sentence on Class E addresses. If
you're looking for more, you won't find it. That one sentence is all
they said.



2)My curiosity questions were not about "when" or "how", but "why" and for 
"whom".

As documented or unambiguously inferred, "why" is because the folks in
the 1980s wanted to hold some addresses aside for uses not then known,
and "for whom" was explicitly undefined.



Particularly at a time that IPv4 was planned to be "dead" soon, what was its 
"Future" that deserved to be Reserved for?

As I've said in other postings on the subject, I believe the time has
passed where it was reasonable to expect that a non-unicast use might
be found for 240/4 within the remaining lifetime of the IPv4 protocol.
Nor is there any reason to believe we will need more of another sort
of address such as multicast or broadcast. More, it's well understood
that the network routing and software client behavior for anycast is
identical to unicast, and indeed addresses defined as global unicast
have been routinely allocated to anycast uses. I thus think a
standards action changing 240/4 from "reserved, undefined" to
"reserved, unicast" is justified.

Exactly what unicast use remains a reasonable topic of debate. Such
debate, however, is irrelevant to the hardware and software
implementing it which need only care that the addresses should be
handled in normal unicast routing and termination. Changes to hardware
and software to make use of 240/4 as ordinary unicast IP addresses can
and should proceed in parallel to such debate.

Regards,
Bill Herrin





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

Re: Making Use of 240/4 NetBlock

[JORDI PALET MARTINEZ via NANOG]

Because it is a single Internet, and what we do in some parts of Internet will 
affect others?

Because, at least in my case, I'm investing my efforts in what it seems to be 
the best in the long-term for the global community, not my personal preferences?
 
 

El 12/3/22 9:10, "William Herrin"  escribió:

On Fri, Mar 11, 2022 at 11:58 PM JORDI PALET MARTINEZ via NANOG
 wrote:
> Exactly, many previous unsuccessful discussions at IETF about 240/4: IPv6 
is the only viable long-term solution.
>
> The effort to “reinvent” any part of IPv4 or patches to it, then test 
that everything keeps working as expected, versus the benefits and gained time, 
it is much best invested in continue the IPv6 deployment which is already going 
on in this region and the rest of the world.
>
> It would not make sense, to throw away all the efforts that have been 
already done with IPv6 and we should avoid confusing people.
>
> I just think that even this thread is a waste of time (and will not 
further participate on it), time that can be employed in continue deploying 
IPv6.


Why are so many otherwise smart engineers so vulnerable to false
dilemma style fallacies? There's no "either/or" here. It's not a zero
sum game. If you don't see value in doing more with IPv4 then why
don't you get out of the way of folks who do?

Regards,
Bill Herrin


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



**
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: Making Use of 240/4 NetBlock

[William Herrin]

On Fri, Mar 11, 2022 at 11:58 PM JORDI PALET MARTINEZ via NANOG
 wrote:
> Exactly, many previous unsuccessful discussions at IETF about 240/4: IPv6 is 
> the only viable long-term solution.
>
> The effort to “reinvent” any part of IPv4 or patches to it, then test that 
> everything keeps working as expected, versus the benefits and gained time, it 
> is much best invested in continue the IPv6 deployment which is already going 
> on in this region and the rest of the world.
>
> It would not make sense, to throw away all the efforts that have been already 
> done with IPv6 and we should avoid confusing people.
>
> I just think that even this thread is a waste of time (and will not further 
> participate on it), time that can be employed in continue deploying IPv6.


Why are so many otherwise smart engineers so vulnerable to false
dilemma style fallacies? There's no "either/or" here. It's not a zero
sum game. If you don't see value in doing more with IPv4 then why
don't you get out of the way of folks who do?

Regards,
Bill Herrin


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

Re: Making Use of 240/4 NetBlock

[JORDI PALET MARTINEZ via NANOG]

Exactly, many previous unsuccessful discussions at IETF about 240/4: IPv6 is 
the only viable long-term solution.

 

The effort to “reinvent” any part of IPv4 or patches to it, then test that 
everything keeps working as expected, versus the benefits and gained time, it 
is much best invested in continue the IPv6 deployment which is already going on 
in this region and the rest of the world.

 

It would not make sense, to throw away all the efforts that have been already 
done with IPv6 and we should avoid confusing people.

 

I just think that even this thread is a waste of time (and will not further 
participate on it), time that can be employed in continue deploying IPv6.

 

Regards,

Jordi

@jordipalet

 

 

 

El 12/3/22 6:32, "NANOG en nombre de Greg Skinner via NANOG" 
 escribió:

 

 



On Mar 10, 2022, at 8:44 PM, Masataka Ohta  
wrote:


IIRC, at some time, perhaps when CIDR was deployed widely and
having something other than IPv4 was a hot topic, there was a
discussion on releasing 240/4 in IETF. Reasonings against it were
that the released space will be consumed quickly (at that time,
NAT already existed but was uncommon) and that new IP will be
designed and deployed quickly (we were optimistic).

    
   Masataka Ohta

 

There have been many discussions about 240/4 in the IETF.  For some examples, 
query “240/4” in the ‘ietf’ mail archive on mailarchive.ietf.org.

 

—gregbo



**
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: Making Use of 240/4 NetBlock

[Greg Skinner via NANOG]

> On Mar 10, 2022, at 8:44 PM, Masataka Ohta  
> wrote:
> 
> IIRC, at some time, perhaps when CIDR was deployed widely and
> having something other than IPv4 was a hot topic, there was a
> discussion on releasing 240/4 in IETF. Reasonings against it were
> that the released space will be consumed quickly (at that time,
> NAT already existed but was uncommon) and that new IP will be
> designed and deployed quickly (we were optimistic).
> 
>   Masataka Ohta
> 

There have been many discussions about 240/4 in the IETF.  For some examples, 
query “240/4” in the ‘ietf’ mail archive 
 on 
mailarchive.ietf.org.

—gregbo

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Abraham Y. Chen]

Hi, Ca By:

1)    Re: Ur. Pt. 1) " ... the number is 46% in the USA.  ":    Whoa! 
Your revised number is even higher. And, I could round it up to 50%! 
Seriously, please be specific about where are you reading the number 
that you are reporting? I commented after reading your second reference, 
because I could not find relevant data from the first one. Is there 
something hidden there? Please identify.


2)    Re: Ur. Pt. 2): I have to wait for your clarification for Pt. 1) 
above to proceed with these additional statements.


Regards,


Abe (2022-03-11 15:06)




On 2022-03-11 11:19, Ca By wrote:



On Fri, Mar 11, 2022 at 7:15 AM Abraham Y. Chen  wrote:

Dear Ca By:

1)    It appears that you are reading the Google graph too
optimistically, or incorrectly. That is, the highest peaks of the
graph are about 38%. The average of the graph is about 36%. Citing
"over 40%" from these is a gross exaggeration. In fact, the peaks
were reached on weekends and holidays due to more residential
usage, you can clearly see such by zooming into the graph. In
addition, the graph has been exhibiting an asymptomatic trend ever
since a few years back. The COVID-19 pushed this graph up a bit
due to the lock-down and work-from-home factors. Below was an
analysis pre-pandemic:


Sorry for being imprecise in my communication, the number is 46% in 
the USA.



https://circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit/

2)    Since Google is one of the stronger IPv6 promoters, usage of
IPv6 outside of the Google domain can only be lower, by simple
logic deduction.


Google’s number represents how many users reach it over ipv6. Given 
Google’s ubiquity in the usa, it is a fair barometer for the usa at 
large.  This data is helpful for content providers  estimating demand 
for ipv6 (46% of users will use ipv6 if it is available)  and for the 
network operator community to understand where their peers sit.


In summary, there is a lot of ipv6 on the usa internet today. Almost 
half for Google, per their published numbers. Over 75% end to end ipv6 
on some large mobile networks.  Hence my appeal to view published data.


Reading anecdotal Nanog mails from a handful of folks concluding ipv6 
has failed will not leave the passive impartial observer with an 
accurate view.


Regards,


Abe (2022-03-11 10:11)


--
NANOG Digest, Vol 170, Issue 12

Message: 12
Date: Thu, 10 Mar 2022 08:00:17 -0800
From: Ca By  <mailto:cb.li...@gmail.com>
To: Saku Ytti  <mailto:s...@ytti.fi>
Cc: Joe Greco  <mailto:jgr...@ns.sol.net>,nanog@nanog.org
Subject: Re: V6 still not supported (was Re: CC: s to Non List Members
(was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4
NetBlock))
Message-ID:
  
<mailto:cad6ajgtyqt-omq_kxxfe-sozwq3msj5gc_tkswdpjpi7mme...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Wed, Mar 9, 2022 at 11:56 PM Saku Ytti  
<mailto:s...@ytti.fi>  wrote:


On Wed, 9 Mar 2022 at 21:00, Joe Greco  
<mailto:jgr...@ns.sol.net>  wrote:


I really never thought it'd be 2022 and my networks would be still
heavily v4.  Mind boggling.

Same. And if we don't voluntarily agree to do something to it, it'll
be the same in 2042, we fucked up and those who come after us pay the
price of the insane amount of work and cost dual stack causes.

It is solvable, easily and cheaply, like most problems (energy,
climate), but not when so many poor leaders participate in decision
making.

--
   ++ytti


Ah, the quarterly ipv6 thread? where i remind you all? most of the USA is
on ipv6 (all your smartphone, many of your home router, a growing amount of
your clouds [i see you aws])

https://www.worldipv6launch.org/measurements/

Google sees over 40% of their users on ipv6, with superior latency

https://www.google.com/intl/en/ipv6/statistics.html



-- next part --



<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=icon>
Virus-free. www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=link>


<#m_6390985030485347940_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>




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

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Joe Maimon]

Grant Taylor via NANOG wrote:



I believe that talking about removing IPv4 in any capacity /now/ is a 
disservice to the larger conversation.


We mostly agree. Except that there is a significant vocal portion of the 
IPv6 spectrum that would like to start obsoleting IPv4 now.


I have my doubts about getting back to a single protocol Internet 
(IPv6) in my lifetime, much less my career.


I both doubt and very much hope that it will not be quite that long, but 
even so, the fact that it can even be considered a possibility should be 
a significant wake up call.


In any event, all this underscores the reality that IPv4 requires more 
investment to carry along until that point.



And until that point, IPv6 is an optimization, not a requirement.


How long do you wait during the "optimization" window before actually 
deploying IPv6?  The 11th hour?  Why not start deploying IPv6 with new 
green field deployments at the 2nd hour?



Until you have the itch to do so, until you have a business case to do 
so, until you no longer have any excuse not to do so. The opt in 
optimization is optional.


Joe

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Grant Taylor via NANOG]

On 3/11/22 9:39 AM, Joe Maimon wrote:
I am not really convinced that IPv4 can be 
ignored/marginalized/obsoleted without penetration reaching over 90%, 
globally.


I feel like that's an unfair characterization / summarization.

The VAST MAJORITY of the pro IPv6 discussions that I see are targeting 
parity between IPv4 and IPv6.  As such, there is absolutely no ignoring, 
no marginalizing, no obsoleting of IPv4 in those discussions.


The vast majority of the discussions that I've participated in have not 
been IPv4 exclusive or IPv6.  --  The breakdown tends to be three 
categories, exclusive IPv4 (old), dual IPv4 and IPv6 (current), and 
exclusive IPv6 (far Far FAR future).


As I see it, if we divide the three categories equally, 0-33% is IPv4 
only, 34-66% is dual IPv4 and IPv6, and 67-99% (can be) IPv6 only.  -- I 
fudged the numbers a %, to simplify the 1/3 fractional math.  --  As 
such, we have crossed over from the exclusive IPv4 (0-33%) into the dual 
IPv4 and IPv6 (34-66%).  We have a long way to go before even 
considering exclusive IPv6 (67% (or higher)).


I believe that talking about removing IPv4 in any capacity /now/ is a 
disservice to the larger conversation.


I have my doubts about getting back to a single protocol Internet (IPv6) 
in my lifetime, much less my career.



And until that point, IPv6 is an optimization, not a requirement.


How long do you wait during the "optimization" window before actually 
deploying IPv6?  The 11th hour?  Why not start deploying IPv6 with new 
green field deployments at the 2nd hour?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Joe Maimon]

Ca By wrote:




Google’s number represents how many users reach it over ipv6. Given 
Google’s ubiquity in the usa, it is a fair barometer for the usa at 
large.


Given google's popularity on handheld platforms, the users of which tend 
to be much less sensitive to IPv4 translation mechanisms and have a much 
higher penetration of native v6, I would restate that a bit more 
conservatively as


Google's statistics are likely a fair barometer for USA usage in the 
large content provider arena which have a strong mobile representation.






Reading anecdotal Nanog mails from a handful of folks concluding ipv6 
has failed will not leave the passive impartial observer with an 
accurate view.


Its incontrovertible that IPv6 has racked up a long list of failures in 
its original objectives, expectations, predictions and timelines, even 
up to this point.


I am not really convinced that IPv4 can be 
ignored/marginalized/obsoleted without penetration reaching over 90%, 
globally. And until that point, IPv6 is an optimization, not a requirement.


Perhaps it will accelerate at some percentage point. But if it drags out 
for another decade or two, all bets are off.



Joe

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[William Herrin]

On Fri, Mar 11, 2022 at 6:36 AM Abraham Y. Chen  wrote:
> 1)Thanks for the reference. However, Informative Reference 7 of our IETF 
> Draft cites another IANA document which puts the initial date of the 240/4 
> topic back to 1981-09 which was much earlier, in fact, coincided with that of 
> RFC 791.

Hi Abraham,

As I said, RFC1112 documents the _most recent_ standards action with
respect to 240/4. The earlier RFC 791 you mention described 224/3
(which included 240/4) as "escape to extended addressing mode" which
it specified as "undefined" and "reserved for future use." RFC 988
then redefined and split 224/3 into "class D" and "class E" addresses,
defined "class D" as multicast and "class E" as reserved for future
use without any particular purpose. This saw updates in RFC1112 which
has the current disposition of "class E" aka 240/4.

RFC 1112 spends a grand total of one sentence on Class E addresses. If
you're looking for more, you won't find it. That one sentence is all
they said.


> 2)My curiosity questions were not about "when" or "how", but "why" and 
> for "whom".

As documented or unambiguously inferred, "why" is because the folks in
the 1980s wanted to hold some addresses aside for uses not then known,
and "for whom" was explicitly undefined.


> Particularly at a time that IPv4 was planned to be "dead" soon, what was its 
> "Future" that deserved to be Reserved for?

As I've said in other postings on the subject, I believe the time has
passed where it was reasonable to expect that a non-unicast use might
be found for 240/4 within the remaining lifetime of the IPv4 protocol.
Nor is there any reason to believe we will need more of another sort
of address such as multicast or broadcast. More, it's well understood
that the network routing and software client behavior for anycast is
identical to unicast, and indeed addresses defined as global unicast
have been routinely allocated to anycast uses. I thus think a
standards action changing 240/4 from "reserved, undefined" to
"reserved, unicast" is justified.

Exactly what unicast use remains a reasonable topic of debate. Such
debate, however, is irrelevant to the hardware and software
implementing it which need only care that the addresses should be
handled in normal unicast routing and termination. Changes to hardware
and software to make use of 240/4 as ordinary unicast IP addresses can
and should proceed in parallel to such debate.

Regards,
Bill Herrin


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

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Ca By]

On Fri, Mar 11, 2022 at 7:15 AM Abraham Y. Chen  wrote:

> Dear Ca By:
>
> 1)It appears that you are reading the Google graph too optimistically,
> or incorrectly. That is, the highest peaks of the graph are about 38%. The
> average of the graph is about 36%. Citing "over 40%" from these is a gross
> exaggeration. In fact, the peaks were reached on weekends and holidays due
> to more residential usage, you can clearly see such by zooming into the
> graph. In addition, the graph has been exhibiting an asymptomatic trend
> ever since a few years back. The COVID-19 pushed this graph up a bit due to
> the lock-down and work-from-home factors. Below was an analysis
> pre-pandemic:
>

Sorry for being imprecise in my communication, the number is 46% in the USA.


>
> https://circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit/
>
> 2)Since Google is one of the stronger IPv6 promoters, usage of IPv6
> outside of the Google domain can only be lower, by simple logic deduction.
>
>
Google’s number represents how many users reach it over ipv6. Given
Google’s ubiquity in the usa, it is a fair barometer for the usa at large.
This data is helpful for content providers  estimating demand for ipv6 (46%
of users will use ipv6 if it is available)  and for the network operator
community to understand where their peers sit.

In summary, there is a lot of ipv6 on the usa internet today. Almost half
for Google, per their published numbers. Over 75% end to end ipv6 on some
large mobile networks.  Hence my appeal to view published data.

Reading anecdotal Nanog mails from a handful of folks concluding ipv6 has
failed will not leave the passive impartial observer with an accurate view.


Regards,
>
>
> Abe (2022-03-11 10:11)
>
>
> --
> NANOG Digest, Vol 170, Issue 12
>
> Message: 12
> Date: Thu, 10 Mar 2022 08:00:17 -0800
> From: Ca By  
> To: Saku Ytti  
> Cc: Joe Greco  , nanog@nanog.org
> Subject: Re: V6 still not supported (was Re: CC: s to Non List Members
>   (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4
>   NetBlock))
> Message-ID:
>
> 
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Mar 9, 2022 at 11:56 PM Saku Ytti   wrote:
>
>
> On Wed, 9 Mar 2022 at 21:00, Joe Greco  
>  wrote:
>
>
> I really never thought it'd be 2022 and my networks would be still
> heavily v4.  Mind boggling.
>
> Same. And if we don't voluntarily agree to do something to it, it'll
> be the same in 2042, we fucked up and those who come after us pay the
> price of the insane amount of work and cost dual stack causes.
>
> It is solvable, easily and cheaply, like most problems (energy,
> climate), but not when so many poor leaders participate in decision
> making.
>
> --
>   ++ytti
>
> Ah, the quarterly ipv6 thread? where i remind you all? most of the USA is
> on ipv6 (all your smartphone, many of your home router, a growing amount of
> your clouds [i see you aws])
> https://www.worldipv6launch.org/measurements/
>
> Google sees over 40% of their users on ipv6, with superior latency
> https://www.google.com/intl/en/ipv6/statistics.html
>
>
>  -- next part --
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=link>
> <#m_6390985030485347940_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Abraham Y. Chen]

Dear Ca By:

1)    It appears that you are reading the Google graph too 
optimistically, or incorrectly. That is, the highest peaks of the graph 
are about 38%. The average of the graph is about 36%. Citing "over 40%" 
from these is a gross exaggeration. In fact, the peaks were reached on 
weekends and holidays due to more residential usage, you can clearly see 
such by zooming into the graph. In addition, the graph has been 
exhibiting an asymptomatic trend ever since a few years back. The 
COVID-19 pushed this graph up a bit due to the lock-down and 
work-from-home factors. Below was an analysis pre-pandemic:


https://circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit/

2)    Since Google is one of the stronger IPv6 promoters, usage of IPv6 
outside of the Google domain can only be lower, by simple logic deduction.



Regards,


Abe (2022-03-11 10:11)


--
NANOG Digest, Vol 170, Issue 12

Message: 12
Date: Thu, 10 Mar 2022 08:00:17 -0800
From: Ca By
To: Saku Ytti
Cc: Joe Greco,nanog@nanog.org
Subject: Re: V6 still not supported (was Re: CC: s to Non List Members
(was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4
    NetBlock))
Message-ID:

Content-Type: text/plain; charset="utf-8"

On Wed, Mar 9, 2022 at 11:56 PM Saku Ytti  wrote:


On Wed, 9 Mar 2022 at 21:00, Joe Greco  wrote:


I really never thought it'd be 2022 and my networks would be still
heavily v4.  Mind boggling.

Same. And if we don't voluntarily agree to do something to it, it'll
be the same in 2042, we fucked up and those who come after us pay the
price of the insane amount of work and cost dual stack causes.

It is solvable, easily and cheaply, like most problems (energy,
climate), but not when so many poor leaders participate in decision
making.

--
   ++ytti


Ah, the quarterly ipv6 thread? where i remind you all? most of the USA is
on ipv6 (all your smartphone, many of your home router, a growing amount of
your clouds [i see you aws])

https://www.worldipv6launch.org/measurements/

Google sees over 40% of their users on ipv6, with superior latency

https://www.google.com/intl/en/ipv6/statistics.html



-- next part --


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

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[Abraham Y. Chen]

Hi, Bill:

1)    Thanks for the reference. However, Informative Reference 7 of our 
IETF Draft cites another IANA document which puts the initial date of 
the 240/4 topic back to 1981-09 which was much earlier, in fact, 
coincided with that of RFC 791.


2)    My curiosity questions were not about "when" or "how", but "why" 
and for "whom". Particularly at a time that IPv4 was planned to be 
"dead" soon, what was its "Future" that deserved to be Reserved for?


Regards,


Abe (2022-03-11 09:36)



On 2022-03-10 23:16, William Herrin wrote:

On Thu, Mar 10, 2022 at 7:51 PM Abraham Y. Chen  wrote:

1)" ...  should be ...  ":Instead of "hand wave", this is a diplomatic 
expression to challenge the software engineers' knowledge of the networking program code for the 
current case. Ever since we started our study, we were quite puzzled by why the 240/4 netblock was 
regarded so special? Why no one could tell us what led to its current status, and even after IPv4 
was set to transition to IPv6?

https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

Which leads to RFC 1112 section 4, the disposition of which last
changed in 1989.

You are now informed about its current status along with when and how
it got to be that way.

Regards,
Bill Herrin






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

Re: Making Use of 240/4 NetBlock

[Masataka Ohta]

William Herrin wrote:


Ever since we started our study, we were quite puzzled by why the 240/4
netblock was regarded so special? Why no one could tell us what led to
its current status, and even after IPv4 was set to transition to IPv6?



https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

Which leads to RFC 1112 section 4, the disposition of which last
changed in 1989.


IIRC, at some time, perhaps when CIDR was deployed widely and
having something other than IPv4 was a hot topic, there was a
discussion on releasing 240/4 in IETF. Reasonings against it were
that the released space will be consumed quickly (at that time,
NAT already existed but was uncommon) and that new IP will be
designed and deployed quickly (we were optimistic).

Masataka Ohta

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[William Herrin]

On Thu, Mar 10, 2022 at 7:51 PM Abraham Y. Chen  wrote:
> 1)" ...  should be ...  ":Instead of "hand wave", this is a 
> diplomatic expression to challenge the software engineers' knowledge of the 
> networking program code for the current case. Ever since we started our 
> study, we were quite puzzled by why the 240/4 netblock was regarded so 
> special? Why no one could tell us what led to its current status, and even 
> after IPv4 was set to transition to IPv6?


https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

Which leads to RFC 1112 section 4, the disposition of which last
changed in 1989.

You are now informed about its current status along with when and how
it got to be that way.

Regards,
Bill Herrin



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

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[Abraham Y. Chen]

Dear Seth:

1)    " ...  should be ...  ":    Instead of "hand wave", this is a 
diplomatic expression to challenge the software engineers' knowledge of 
the networking program code for the current case. Ever since we started 
our study, we were quite puzzled by why the 240/4 netblock was regarded 
so special? Why no one could tell us what led to its current status, and 
even after IPv4 was set to transition to IPv6? ... etc. We also could 
not find anyone who could describe to us how was it being handled in the 
existing programs. This included those who claimed to be experts in the 
subject. Perhaps they intentionally tried to hide the detail, or they 
also did not know? One day, we finally came across a program fragment 
that could perform the "disabling 240/4 netblock" function. Upon 
presenting it to an acquaintance knowledgeable of networking programs, 
he confirmed that it was one concise technique to do the job. That was 
sufficient for our purpose as system engineers, because we should not 
overstep our duties by doing software engineer's programing task. That 
is, as long as we can demonstrate that "there exists" a solution, like 
proofing a mathematics theorem, we have completed our part of the deal.


2)    " ... discussed to death many times over ...  ":    This was what 
we were told when we first looked into this subject over half a dozen 
years ago, and more times along the way. As long as there was an issue 
not resolved, however, every angle should be continuously explored. In 
science and engineering, if we stopped studying, because of this kind of 
viewpoint, we would have missed a lot of inventions and discoveries. So, 
this particular consideration is not in our books.


Regards,


Abe (2022-03-10 22:49 EST)

--

NANOG Digest, Vol 170, Issue 11

Message: 10
Date: Wed, 9 Mar 2022 10:29:22 -0800
From: Seth Mattinen
To:nanog@nanog.org
Subject: Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock
Message-ID:<0c6c8b63-6e84-92da-2e28-89b2b5c6d...@rollernet.us>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 3/7/22 2:14 PM, Abraham Y. Chen wrote:


The cost of this software engineering should be minimal.


So basically no solution is offered to what is the showstopper for this
proposal, only a hand wave that it "should be" easy to fix (but that's
everyone else's problem). I mean, I believe this has been discussed to
death many times over in the past and yet here we still are.

--


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

RE: WISPA (was Making Use of 240/4 NetBlock)

[netElastic Systems]

Wish I was.  Will be at MTA in MSP, but will be at WISPAPALOOZA.  Love to have 
a group meet then.

-Original Message-
From: NANOG  On Behalf Of 
Travis Garrison
Sent: Wednesday, March 9, 2022 12:12 PM
To: Dave Taht 
Cc: NANOG 
Subject: RE: WISPA (was Making Use of 240/4 NetBlock)

I will be attending also. We should try to do a meetup of the NANOG members

Thank you
Travis Garrison



-Original Message-
From: NANOG  On Behalf Of Dave 
Taht
Sent: Wednesday, March 9, 2022 1:25 PM
To: Tim Howe 
Cc: NANOG 
Subject: Re: V6 still not supported (was Making Use of 240/4 NetBlock)

I am going to attend the WISPA conference in New Orleans next week.
(anyone going)

Re: V6 still not supported (was Re: Making Use of 240/4 NetBlock))

[Matthew Walster]

On Thu, 10 Mar 2022, 11:22 Masataka Ohta, 
wrote:

> Saku Ytti wrote:
>
> > Same. And if we don't voluntarily agree to do something to it, it'll
> > be the same in 2042, we fucked up and those who come after us pay the
> > price of the insane amount of work and cost dual stack causes.
>
> Indeed, we don't need IPv6 at all at least for the next 20 years,
> which is long enough to have 32bit port length for TCP and UDP to
> make NAT save address space more efficiently.


Rather than fudging it at the transport layer, there's always a network
layer solution. NAT with port overload got us this far, but it requires
state to be stored in the forwarding path. MAP-T limits the range of ports
at the CPE, allowing simple algorithmic translation without any stored
state in the provider network.

That sufficiently kicks down the eyeball side for some considerable time,
but there's still no decent reason to go dual-stack on the content side,
except for resource starvation costs in address heavy environments like
container clouds etc.

What you end up with is NAT overload islands there too, with
gateways/proxies providing the dual-stack, and using TLS SNI for virtual
hosting where protocols don't otherwise support it, and the strong
discouragement of putting network layer information inside protocols
(things requiring ALGs like FTP etc). That's kinda where we are today
anyway.

Honestly, I can not see IPv4 dipping below 90% of hosts addressed with it
in this decade. That doesn't mean IPv6 is <10%, that means IPv4 remains a
near-mandatory service requirement for the bulk of addressable hosts.

Oh and before I get flamed by a certain person -- if you refuse to support
IPv4 and label people fools for not supporting IPv6, you'll just end up
with someone crazy like the ITU-T taking over IPv4 maintenance. No-one
wants that. Carrot, not just stick.

M

Re: WISPA (was Making Use of 240/4 NetBlock)

[Jeremy Austin]

I'm in.

Jeremy Austin

On Wed, Mar 9, 2022 at 11:38 AM Dennis Burgess 
wrote:

> Let me know where and when 
>
>
>
> Dennis Burgess
>
> Author of "Learn RouterOS- Second Edition”
> Link Technologies, Inc -- Mikrotik & WISP Support Services
> Office: 314-735-0270  Website: http://www.linktechs.net
> Create Wireless Coverage’s with www.towercoverage.com
> Need MikroTik Cloud Management: https://cloud.linktechs.net
>
> -Original Message-
> From: NANOG  On Behalf
> Of Travis Garrison
> Sent: Wednesday, March 9, 2022 2:12 PM
> To: Dave Taht 
> Cc: NANOG 
> Subject: RE: WISPA (was Making Use of 240/4 NetBlock)
>
> I will be attending also. We should try to do a meetup of the NANOG members
>
> Thank you
> Travis Garrison
>
>
>
> -Original Message-
> From: NANOG  On Behalf
> Of Dave Taht
> Sent: Wednesday, March 9, 2022 1:25 PM
> To: Tim Howe 
> Cc: NANOG 
> Subject: Re: V6 still not supported (was Making Use of 240/4 NetBlock)
>
> I am going to attend the WISPA conference in New Orleans next week.
> (anyone going)
>


-- 
Jeremy Austin
jhaus...@gmail.com

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Joe Maimon]

Tom Beecher wrote:


The only way IPv6 will ever be ubiquitous is if there comes a time 
where there is some forcing event that requires it to be.


Unless that occurs, people will continue to spend time and energy 
coming up with ways to squeeze the blood out of v4 that could have 
been used to get v6 going instead. I don't foresee anything changing 
for most of the rest of our careers, and possibly the next generation 
behind us.


I dont think it is as bad as that, but what you are implicitly saying is 
that even multi-decades efforts to prolong IPv4 have clear justification 
to begin now, if not sooner.


As for the rest of this popular meme, instead of aspirations to force a 
chosen technology down the throats of many clearly unwilling and/or 
uninterested parties whom make up a still significant percentage of the 
internet, perhaps more effort should be expended on


A) making the chosen technology more attractive, more useful, more 
deployable, more compatible, etc. Because clearly its not enough of 
those things for many, regardless of whatever personal experience or 
theories you may have on the matter.


B) Keeping the rest of the internet as functional as possible, with 
whatever tradeoffs make send, for the actual potential duration of A 
instead of pie-in-the-sky estimates. Which have a 100% track record of 
being wrong.


Persuasion, not coercion. Which even if it were possible, is wrong and 
immoral.


The internet is supposed to be about mutually beneficial cooperation, 
not hierarchical coercion.


Joe

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Joe Maimon]

Owen DeLong via NANOG wrote:

One thing is for certain… If folks had put 0.10 as much effort into deploying 
IPv6 as has been put into arguing about whether or not ~17 /8s worth of IPv4 
makes a meaningful difference to the internet as a whole, IPv4 would long since 
have become irrelevant as it must eventually be.

Owen


You might have had a decent point there instead of a soundbite, except 
that you are conflating different people together, as if the ones 
arguing to extend IPv4 are conveniently the same ones whom if they 
redirected their efforts would have IPv6 deployed in a few jiffies.


Reality is quite a bit different.

Joe

Re: V6 still not supported (was Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock))

[Saku Ytti]

On Thu, 10 Mar 2022 at 16:01, Joe Greco  wrote:

> I am reading your response as to imply that this is somehow my fault
> (for my networks) and that I am a poor leader for not having embraced
> v6.  If that's not what you meant, great, because I feel like there's
> been systemic issues.

No, I meant us as the community of people building the internet in the
last 20 years. Poor state of IPv6+IPv4 not any individual's fault,
some share more fault than others, but we're all culpable. My
apologies, I didn't intend it to read as I'm blaming you.
You can't go IPV6 only in your own network, you have other networks to
talk to, other applications to use to, things to buy which you assert
little control over.

-- 
  ++ytti

Re: V6 still not supported (was Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock))

[Tom Beecher]

>
> Google sees over 40% of their users on ipv6,* with superior latency *
>

Uncle Geoff generally debunked this years ago.

https://www.youtube.com/watch?v=Lt-Xx2CmuQE_channel=NANOG

On Thu, Mar 10, 2022 at 11:01 AM Ca By  wrote:

>
>
> On Wed, Mar 9, 2022 at 11:56 PM Saku Ytti  wrote:
>
>> On Wed, 9 Mar 2022 at 21:00, Joe Greco  wrote:
>>
>> > I really never thought it'd be 2022 and my networks would be still
>> > heavily v4.  Mind boggling.
>>
>> Same. And if we don't voluntarily agree to do something to it, it'll
>> be the same in 2042, we fucked up and those who come after us pay the
>> price of the insane amount of work and cost dual stack causes.
>>
>> It is solvable, easily and cheaply, like most problems (energy,
>> climate), but not when so many poor leaders participate in decision
>> making.
>>
>> --
>>   ++ytti
>
>
> Ah, the quarterly ipv6 thread… where i remind you all… most of the USA is
> on ipv6 (all your smartphone, many of your home router, a growing amount of
> your clouds [i see you aws])
>
> https://www.worldipv6launch.org/measurements/
>
> Google sees over 40% of their users on ipv6, with superior latency
>
> https://www.google.com/intl/en/ipv6/statistics.html
>
>
>
>>

Re: V6 still not supported (was Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock))

[Ca By]

On Wed, Mar 9, 2022 at 11:56 PM Saku Ytti  wrote:

> On Wed, 9 Mar 2022 at 21:00, Joe Greco  wrote:
>
> > I really never thought it'd be 2022 and my networks would be still
> > heavily v4.  Mind boggling.
>
> Same. And if we don't voluntarily agree to do something to it, it'll
> be the same in 2042, we fucked up and those who come after us pay the
> price of the insane amount of work and cost dual stack causes.
>
> It is solvable, easily and cheaply, like most problems (energy,
> climate), but not when so many poor leaders participate in decision
> making.
>
> --
>   ++ytti


Ah, the quarterly ipv6 thread… where i remind you all… most of the USA is
on ipv6 (all your smartphone, many of your home router, a growing amount of
your clouds [i see you aws])

https://www.worldipv6launch.org/measurements/

Google sees over 40% of their users on ipv6, with superior latency

https://www.google.com/intl/en/ipv6/statistics.html



>

Re: V6 still not supported (was Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock))

[Joe Greco]

On Thu, Mar 10, 2022 at 09:55:42AM +0200, Saku Ytti wrote:
> On Wed, 9 Mar 2022 at 21:00, Joe Greco  wrote:
> > I really never thought it'd be 2022 and my networks would be still
> > heavily v4.  Mind boggling.
> 
> Same. And if we don't voluntarily agree to do something to it, it'll
> be the same in 2042, we fucked up and those who come after us pay the
> price of the insane amount of work and cost dual stack causes.
> 
> It is solvable, easily and cheaply, like most problems (energy,
> climate), but not when so many poor leaders participate in decision
> making.

I am reading your response as to imply that this is somehow my fault
(for my networks) and that I am a poor leader for not having embraced
v6.  If that's not what you meant, great, because I feel like there's
been systemic issues.

There are several ASN's I run infrastructure for, on an (as you
put it) "voluntary" basis, for organizations that run critical bits
of Internet infrastructure but which aren't funded like they are
critical bits.

The problem is that I really don't have the ability to donate more
of my time, since I am already 150% booked, and I'm not willing to
hire someone just to donate their time.

I have no idea what it is I can agree to do to make something happen
here that is accomplished "easily and cheaply".  From my perspective,
IPv4+6 is many times the effort to deploy as just IPv4, somewhere
between 5x-10x as much work depending on the specifics.  I love many
of the ideas behind v6, but adoption seems tepid.  I had to fight
years ago to get IPv6 via broadband, and most common end-user gear
still does not seem to support it, or enable it by default.

Looking at the results, I think we've screwed this up.  Just like the
e-mail ecosystem was screwed up by poor design and then stupid bolt-on
fixes, so we've finally arrived at a point where people just don't 
even want to deal with the problem.  At least with e-mail, you can
plausibly outsource it if you're not masochistic.  I feel like IPv6 is
that same sort of problem, except you can't outsource it.  You can
avoid it by throwing some more IPv4 NAT and proxies into the mix
though.  And tragically, that seems to be what's happened.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: V6 still not supported (was Re: Making Use of 240/4 NetBlock))

[Masataka Ohta]

Saku Ytti wrote:


Same. And if we don't voluntarily agree to do something to it, it'll
be the same in 2042, we fucked up and those who come after us pay the
price of the insane amount of work and cost dual stack causes.


Indeed, we don't need IPv6 at all at least for the next 20 years,
which is long enough to have 32bit port length for TCP and UDP to
make NAT save address space more efficiently.

Masataka Ohta

Re: V6 still not supported (was Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock))

[Saku Ytti]

On Wed, 9 Mar 2022 at 21:00, Joe Greco  wrote:

> I really never thought it'd be 2022 and my networks would be still
> heavily v4.  Mind boggling.

Same. And if we don't voluntarily agree to do something to it, it'll
be the same in 2042, we fucked up and those who come after us pay the
price of the insane amount of work and cost dual stack causes.

It is solvable, easily and cheaply, like most problems (energy,
climate), but not when so many poor leaders participate in decision
making.

-- 
  ++ytti

Re: Making Use of 240/4 NetBlock

[Masataka Ohta]

John Gilmore wrote:


Whatever the IPv6 transition might require, it isn't comparable to the
small effort needed to upgrade a few laggard OS's to support 240/4 and
to do some de-bogonization in the global Internet, akin to what CloudFlare
did for 1.1.1.1.


It may be a good idea to offer 127/8 for relocation. Even if
the range may be used internally by some devices (though, for
double NAT, rfc6598 shared address should be used), it is a
local problem for people using bogon addresses.

Masataka Ohta

Re: 202203090732.AYC Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: Making Use of 240/4 NetBlock)

[Abraham Y. Chen]

Dear Mel & Bill:

0)    Thank you for your kind advice.

1)    To be honest, I am a bit of lost with multiple comments about my 
eMail Header at the same time. Especially, some seem not in agreement 
with the other. Rather than opening up a discussion thread, such as 
"eMail Header Rules" that for sure will distract us from the real topic 
on the table, I have sent a request to Valerie Wittkop (Program 
Director) for a copy of the "official" rules for me to follow.


Regards,


Abe (2022-03-09 23:13)


On 2022-03-09 14:23, Abraham Y. Chen wrote:

On 2022-03-09 13:16, Mel Beckman wrote:
Alternatively, just use BCC. There is no reason for you to tell us 
who else you want to hear what you say. There’s nothing wrong with 
CCing, and nothing in the rules against it, but your recipients may 
not appreciate you distributing their email addresses on this list, 
to which they are not a member.


 -mel beckman


On Mar 9, 2022, at 9:29 AM, William Herrin  wrote:


Mr. Chen:

Would you please stop changing the subject line with an added date 
stamp every time you post? It fouls threaded email readers and is 
most inconsiderate.


In addition, I respectfully encourage you to trim the recipients to 
just the mailnig list and the specific individual to whom you are 
sending a reply.


Thanks,
Bill Herrin


On Wed, Mar 9, 2022 at 9:19 AM William Herrin  wrote:

Mr. Chen:

Would you please stop changing the subject line with an added
date stamp every time you post? It fouls threaded email readers
and is most inconsiderate.

Thanks,
Bill Herrin


On Wed, Mar 9, 2022 at 9:09 AM Abraham Y. Chen
 wrote:

Dear John:

1)    Thanks for your comment on how eMail headers could be
used.

Dear Bill:

2)    I am glad that you agree that it should be a viable
    discussion on making use of the 240/4 netblock, while
waiting for IPv6 to deliver its promises.

3)    As to your question about where does IPv6 stand today
and where is it heading, I like to highlight a recent APNIC
blog that you may have read. It also appeared on CircleID.
After a long recount of the history, the author seems to
hint that 1995 may be the new starting point for looking
forward.


https://blog.apnic.net/2022/02/21/another-year-of-the-transition-to-ipv6/?utm_source=mailpoet_medium=email_campaign=apnic-blog-weekly-wrap_4

<https://blog.apnic.net/2022/02/21/another-year-of-the-transition-to-ipv6/?utm_source=mailpoet_medium=email_campaign=apnic-blog-weekly-wrap_4>



https://circleid.com/posts/20220220-another-year-of-the-transition-to-ipv6

4)    We fully realize that the EzIP approach is quite
unorthodox. As such, we received numerous quick criticisms
in the past. With the proposal now put together, we do hope
colleagues on this list will take the time to review its
specifics. I look forward to comments and critiques on its
merits.

Regards,


Abe (2022-03-09 12:08)


Message: 7
Date: 8 Mar 2022 15:32:36 -0500
From: "John Levine"  <mailto:jo...@iecc.com>
To:nanog@nanog.org
Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re:
        202203071610.AYC Re: Making Use of 240/4 NetBlock)
Message-ID:<20220308203237.53e7038b1...@ary.qy>  
<mailto:20220308203237.53e7038b1...@ary.qy>
Content-Type: text/plain; charset=utf-8

It appears that Anne Mitchell  
<mailto:amitch...@isipp.com>  said:


Cc: NANOG  <mailto:nanog@nanog.org>, Greg Skinner  
<mailto:gregskinn...@icloud.com>, "Karandikar, Abhay"  
<mailto:direc...@iitk.ac.in>, Rama Ati

  <mailto:rama_...@outlook.com>, Bob Corner GMAIL  
<mailto:bobbiecor...@gmail.com>, "Hsing, T. Russell"  <mailto:ths...@ieee.org>, 
"Chen, Henry C.J."
  <mailto:hcjc...@avinta.com>, ST Hsieh  
<mailto:uschinae...@gmail.com>, "Chen, Abraham Y."  
<mailto:ayc...@alum.mit.edu>
This is a whole lot of cc:s to people who aren't even part of this 
group/list.  One wonders with this many cc:s, how many bcc:s there also were, 
and to whom.


There are several thousand people on the NANOG list, and public web 
archives.  I don't think this
is a useful question.

FWIW, I also don't think that repurposing 240/4 is a good idea.  To be 
useful it would require
that every host on the Internet update its network stack, which would 
take on the order of
a decade, to free up some space that would likely be depleted in a year 
or two.  It's basically
the same amount of work as getting everything to work on IPv6.

R's,
John


--

Message: 8
   

Re: Making Use of 240/4 NetBlock

[John Levine]

It appears that David Conrad  said:
>isn’t very far), 240/4 isn’t sourcing or sinking significant traffic on the 
>Internet.

FWIW, my tiny server sees about 20 packets/day from that range.  It's not very 
much but it's
hard to imagine why I'm seeing any at all.

It's more than I see from 0/8, less than what I see from 192.168.0.0/16.

R's,
John

RE: WISPA (was Making Use of 240/4 NetBlock)

[Dennis Burgess]

Let me know where and when  



Dennis Burgess

Author of "Learn RouterOS- Second Edition” 
Link Technologies, Inc -- Mikrotik & WISP Support Services 
Office: 314-735-0270  Website: http://www.linktechs.net 
Create Wireless Coverage’s with www.towercoverage.com 
Need MikroTik Cloud Management: https://cloud.linktechs.net 

-Original Message-
From: NANOG  On Behalf Of 
Travis Garrison
Sent: Wednesday, March 9, 2022 2:12 PM
To: Dave Taht 
Cc: NANOG 
Subject: RE: WISPA (was Making Use of 240/4 NetBlock)

I will be attending also. We should try to do a meetup of the NANOG members

Thank you
Travis Garrison



-Original Message-
From: NANOG  On Behalf Of Dave 
Taht
Sent: Wednesday, March 9, 2022 1:25 PM
To: Tim Howe 
Cc: NANOG 
Subject: Re: V6 still not supported (was Making Use of 240/4 NetBlock)

I am going to attend the WISPA conference in New Orleans next week.
(anyone going)

RE: WISPA (was Making Use of 240/4 NetBlock)

[Travis Garrison]

I will be attending also. We should try to do a meetup of the NANOG members

Thank you
Travis Garrison



-Original Message-
From: NANOG  On Behalf Of Dave 
Taht
Sent: Wednesday, March 9, 2022 1:25 PM
To: Tim Howe 
Cc: NANOG 
Subject: Re: V6 still not supported (was Making Use of 240/4 NetBlock)

I am going to attend the WISPA conference in New Orleans next week.
(anyone going)

Re: Making Use of 240/4 NetBlock

[John R. Levine]

Um, are you suggesting there is sufficiently heavy use of 240/4 to 
result in a significant security/stability issue if the address space is 
allocated?  I thought you were arguing too many systems would have to be 
updated to even send/receive packets with 240/4 in the source or 
destination field.


Both, actually.  A few messages back someone said a cloud provider was 
using 240/4 for private address space, which is easy to believe since they 
have their own versions of the system software they run, e.g., Amazon's 
own distro of linux for use within AWS.


So first you have to figure out all of the random computers that need 
network stack upgrades, and then, oh, you can't talk to Google or whoever. 
At this point, either buying a chunk of real IPv4 space or getting IPv6 
working looks quite attractive.


Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: Making Use of 240/4 NetBlock

[David Conrad]

John,

On Mar 9, 2022, at 10:48 AM, John Kristoff  wrote:
> Isn't this essentially the same thing as the DNS name collision problem
> ICANN has been studying and discussing?

Not really (IMHO).  As mentioned to Mr. Levine, what ICANN is concerned about 
is really the security/stability implications of delegating previously 
undelegated but otherwise unconstrained name space, not name space that has 
been designated with “for future use” status.  That designation has resulted in 
code that prohibits its use and to make use of 240/4, the code has to be fixed. 
 The name collision problem ICANN is studying is the result of traffic hitting 
the root for names like CORP and HOME. As far as I know (which isn’t very far), 
240/4 isn’t sourcing or sinking significant traffic on the Internet.

Regards,
-drc





signature.asc
Description: Message signed with OpenPGP

Re: Making Use of 240/4 NetBlock

[David Conrad]

John,

On Mar 9, 2022, at 10:45 AM, John Levine  wrote:
>> When did squatting become a justification for not allocating addresses?
> Um, when can I register my .corp and .home domains?

Um, are you suggesting there is sufficiently heavy use of 240/4 to result in a 
significant security/stability issue if the address space is allocated?  I 
thought you were arguing too many systems would have to be updated to even 
send/receive packets with 240/4 in the source or destination field.

You’re equating the use of address space explicitly reserved “for future use” 
(or for multicast use) with unallocated name space. A more reasonable (but 
still flawed) analogy to .corp and .home would be the squatting on 1/8. I was 
at IANA when we allocated 1/8 to APNIC and recall the gnashing of teeth that 
resulted. Yet we have a demonstration proof that 1/8 could be made usable.

I don’t really have a dog in this fight and my intuition suggests that trying 
to make 240/4 global unicast wouldn’t be worth the effort, but I remain of the 
belief that it would be better to have actual data on what breaks if there was 
an attempt to use it than to come up with specious arguments like “but it might 
annoy squatters”.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: V6 still not supported (was Making Use of 240/4 NetBlock)

[Dave Taht]

I am going to attend the WISPA conference in New Orleans next week.
(anyone going?). I don't see any topics related to ipv6 there, nor as
requirements for broadband grants.

I first tried to deploy ipv6 at my wisp 14 years ago, and failed
utterly. Since then, I've kept track of that market, and most of the
ipv6 support from the vendors that serve it, has been faltering. In
particular, I've been working on improving mikrotik's fq_codel and
cake support only to be completely stymied by several bugs in their
ipv6 implementation. ( https://www.youtube.com/watch?v=TWViGcBlnm0 ).

This week, I've been trying to get a cerowrt box with a hurricane ipv6
tunnel upgraded to modern openwrt, but am running into issues with the
default deny firewall.

Cisco Meraki only recently got a first release of ipv6 out the door.

Tomorrow I hope to take a look at a new ubnt 60ghz outdoor radio,
which I'm told "HAS WORKING IPV6!!", and hoping for the best, because
it has a SDN stack I have no visibility into.

Re: V6 still not supported (was Making Use of 240/4 NetBlock)

[Tim Howe]

On Wed, 9 Mar 2022 09:46:41 -0800
David Conrad  wrote:

> Tim,
> 
> On Mar 9, 2022, at 9:09 AM, Tim Howe  wrote:
> > Some of our biggest vendors who have supposedly supported
> > v6 for over a decade have rudimentary, show-stopping bugs.  
> 
> Not disagreeing (and not picking on you), but despite hearing this
> with some frequency, I haven’t seen much data to corroborate these
> sorts of statements.

Heh :)  This is kind of funny for me since I am usually far
more likely to be accused of not being able to shut up about it.  I
don't like to throw vendors under the bus publicly, but I will instead
name some positive actors whose efforts I appreciate:
Juniper fixed their DHCPv6 relay server when I was able to show
them it was not working correctly; they have also had other bugs that
were DHCPv6 related and provided work-arounds and fixes (they still
have a few bugs that appear to be the result of incomplete fixes for
related issues).  I'm still not sure if they ever fixed the fact that
SRX routers can't dynamically add the default v6 route (I still had to
hard code this last time I tested on SRX320; the bug is documented).
Of course, it still feels like not-that-long-ago when Juniper
wanted me to buy a special license for each switch that I wanted to use
OSPFv3 on.  That's no longer a thing, but it made me pretty mad at the
time.

ZyXel has been very responsive to adding support, fixing
functionality, and working with me on in-depth and long term testing of
issues.  I'm not sure I have ever worked with a vendor that was so
responsive to my requests and reports.  This is in sharp contrast to
one of their competitors who basically told me they have no interest in
adding the IPv6 support they had previously told me they could add.

Adtran is the only vendor I know of that has DHCPv6 option-18
support in their gpon/xgspon OLT cards.  They have also fixed v6 DNS
issues that we have reported on their 5000 chassis.  If it weren't for
their OLTs I would probably not know what "working" looks like.  They
are also the only vendor that has ever handed me a Broadcom based CPE
to test that worked out of the box.  Sadly, I have problems with most
of their current gen; the 515ac is a bright spot - someone important
must be buying these who insisted on v6 support.  There are still some
minor issues with MAC tables on the OLTs that have only revealed
themselves over time, but nothing show-stopping (just requires minor
manual intervention in some cases).

The ISC's Kea DHCP server is a must have for us; this org
deserves more recognition and support from the community.  We use it
for prefix delegation and option-18 (basically all dhcpv6 is relayed
there).

I have still not seen an ACS that has equiv v6 support, but I
will say that both Adtran and Calix appear to be making /very recent/
efforts and have shown progress in this regard.

Ubiquiti Edge routers have pretty decent IPv6 support at the
CLI, but the web GUIs expose little to none of it.

Of course shout out to Microsoft Windows for great support
going back a long way; I wouldn't use it, but the efforts help us all.
The OpenBSD team are also rock stars.

--TimH

Re: V6 still not supported (was Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock))

[Joe Greco]

On Wed, Mar 09, 2022 at 09:46:41AM -0800, David Conrad wrote:
> Tim,
> 
> On Mar 9, 2022, at 9:09 AM, Tim Howe  wrote:
> > Some of our biggest vendors who have supposedly supported
> > v6 for over a decade have rudimentary, show-stopping bugs.
> 
> Not disagreeing (and not picking on you), but despite hearing 
> this with some frequency, I haven???t seen much data to corroborate 
> these sorts of statements.

Fine.  We could start at the top, with protocols that are defective
by design, such as OSPFv3, which lack built-in authentication and 
rely on IPsec.  That's great if you have a system where this is all
tightly and neatly integrated, but smaller scale networks may be
built on Linux or BSD platforms, and this can quickly turn into a
trainwreck of loosely cooperating but separate subsystems, maintaining
IPsec with one set of tools and the routing with another.

Or ... FreeBSD's firewall has a DEFAULT_TO_DENY option for IPv4 but
not for IPv6.  Perhaps not a show-stopping bug, granted.  But, wait,
if you really want end-to-end IPv6 (without something like NAT in
between doing its "faux-firewalling") endpoints, wouldn't you really
want a firewall that defaults to deny, just in case something went
awry?  If I've got a gateway host that normally does stateful
firewalling but it fails to load due to a typo, I'd really like
it to die horribly not packet forwarding anything, because someone
will then notice that.  But if it fails open, that's pretty awful
because it may not be noticed for months or years.  So that's a
show-stopper.

As exciting as it would be to go all-in on v6, it's already quite a
bit of a challenge to build everything dual-stack and get to feature
parity.  The gratuitous differences feel like arrogant protocol
developers who know what's best for you and are going to make you 
comply with their idea of how the world should work, complexity be
damned.

I really never thought it'd be 2022 and my networks would be still
heavily v4.  Mind boggling.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[William Herrin]

On Wed, Mar 9, 2022 at 10:31 AM Seth Mattinen  wrote:
> On 3/7/22 2:14 PM, Abraham Y. Chen wrote:
> > The cost of this software engineering should be minimal.
>
> So basically no solution is offered to what is the showstopper for this
> proposal, only a hand wave that it "should be" easy to fix (but that's
> everyone else's problem). I mean, I believe this has been discussed to
> death many times over in the past and yet here we still are.

Hi Seth,

AFAICT, the core of Abraham's proposal is to deploy 240/4 as an
addition to RFC1918 space, to be used as folks' equipment permits.
Activity beyond that (associated with IoT) appears to have no
inter-domain application that need fall within the standards
development space at this time.

Would you care to articulate the showstopper problem you see for the
standards-relevant portion of the proposal?

Regards,
Bill Herrin


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

Re: Making Use of 240/4 NetBlock

[John Kristoff]

On Wed, 9 Mar 2022 10:38:20 -0800
David Conrad  wrote:

> When did squatting become a justification for not allocating
> addresses?

Isn't this essentially the same thing as the DNS name collision problem
ICANN has been studying and discussing?  Perhaps scale and potential
for harm is different, but I think the essence of the challenge is
essentially the same. In the name space we are unlikely to see
.home (for example) allocated any time soon if ever thanks to what some
might describe as a form of squatting.  I would look to that work for
some perspective on when or why something like this might, or might not
be justified.

  


John

Re: Making Use of 240/4 NetBlock

[John Levine]

It appears that David Conrad  said:
>-=-=-=-=-=-
>
>On Mar 9, 2022, at 10:08 AM, John R. Levine  wrote:
>> On Wed, 9 Mar 2022, John Gilmore wrote:
>>> Major networks are already squatting on the space internally, because they 
>>> tried it and it works.
>> Sounds like an excellent reason not to try to use it for global unicast.
>
>When did squatting become a justification for not allocating addresses?

Um, when can I register my .corp and .home domains?

R's,
John

Re: Making Use of 240/4 NetBlock

[David Conrad]

On Mar 9, 2022, at 10:08 AM, John R. Levine  wrote:
> On Wed, 9 Mar 2022, John Gilmore wrote:
>> Major networks are already squatting on the space internally, because they 
>> tried it and it works.
> Sounds like an excellent reason not to try to use it for global unicast.

When did squatting become a justification for not allocating addresses?

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[Seth Mattinen]

On 3/7/22 2:14 PM, Abraham Y. Chen wrote:

The cost of this software engineering should be minimal.


So basically no solution is offered to what is the showstopper for this 
proposal, only a hand wave that it "should be" easy to fix (but that's 
everyone else's problem). I mean, I believe this has been discussed to 
death many times over in the past and yet here we still are.

Re: 202203090732.AYC Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: Making Use of 240/4 NetBlock)

[Mel Beckman]

Also, Mr. Chen, if your intent is to give your CC recipients copies of our 
discussions on this board, please note that I for one will be deleting any 
additional emails you CC. I do not want to disclose to others what I say on 
this list. If they want to find out, let them use the online archive, like 
every other non subscriber.

None of this has anything to bear on your proposal’s technical merits, for 
which I have no opinion.

 -mel beckman

On Mar 9, 2022, at 10:19 AM, Mel Beckman  wrote:

 Alternatively, just use BCC. There is no reason for you to tell us who else 
you want to hear what you say. There’s nothing wrong with CCing, and nothing in 
the rules against it, but your recipients may not appreciate you distributing 
their email addresses on this list, to which they are not a member.

 -mel beckman

On Mar 9, 2022, at 9:29 AM, William Herrin  wrote:


Mr. Chen:

Would you please stop changing the subject line with an added date stamp every 
time you post? It fouls threaded email readers and is most inconsiderate.

In addition, I respectfully encourage you to trim the recipients to just the 
mailnig list and the specific individual to whom you are sending a reply.

Thanks,
Bill Herrin


On Wed, Mar 9, 2022 at 9:19 AM William Herrin 
mailto:b...@herrin.us>> wrote:
Mr. Chen:

Would you please stop changing the subject line with an added date stamp every 
time you post? It fouls threaded email readers and is most inconsiderate.

Thanks,
Bill Herrin


On Wed, Mar 9, 2022 at 9:09 AM Abraham Y. Chen 
mailto:ayc...@avinta.com>> wrote:

Dear John:

1)Thanks for your comment on how eMail headers could be used.

Dear Bill:

2)I am glad that you agree that it should be a viable discussion on making 
use of the 240/4 netblock, while waiting for IPv6 to deliver its promises.

3)As to your question about where does IPv6 stand today and where is it 
heading, I like to highlight a recent APNIC blog that you may have read. It 
also appeared on CircleID. After a long recount of the history, the author 
seems to hint that 1995 may be the new starting point for looking forward.


https://blog.apnic.net/2022/02/21/another-year-of-the-transition-to-ipv6/?utm_source=mailpoet_medium=email_campaign=apnic-blog-weekly-wrap_4

https://circleid.com/posts/20220220-another-year-of-the-transition-to-ipv6

4)We fully realize that the EzIP approach is quite unorthodox. As such, we 
received numerous quick criticisms in the past. With the proposal now put 
together, we do hope colleagues on this list will take the time to review its 
specifics. I look forward to comments and critiques on its merits.

Regards,


Abe (2022-03-09 12:08)


Message: 7
Date: 8 Mar 2022 15:32:36 -0500
From: "John Levine" <mailto:jo...@iecc.com>
To: nanog@nanog.org<mailto:nanog@nanog.org>
Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re:
        202203071610.AYC Re: Making Use of 240/4 NetBlock)
Message-ID: 
<20220308203237.53e7038b1...@ary.qy><mailto:20220308203237.53e7038b1...@ary.qy>
Content-Type: text/plain; charset=utf-8

It appears that Anne Mitchell <mailto:amitch...@isipp.com> 
said:


Cc: NANOG <mailto:nanog@nanog.org>, Greg Skinner 
<mailto:gregskinn...@icloud.com>, "Karandikar, Abhay" 
<mailto:direc...@iitk.ac.in>, Rama Ati


<mailto:rama_...@outlook.com>, Bob Corner GMAIL 
<mailto:bobbiecor...@gmail.com>, "Hsing, T. Russell" 
<mailto:ths...@ieee.org>, "Chen, Henry C.J."
<mailto:hcjc...@avinta.com>, ST Hsieh 
<mailto:uschinae...@gmail.com>, "Chen, Abraham Y." 
<mailto:ayc...@alum.mit.edu>


This is a whole lot of cc:s to people who aren't even part of this group/list.  
One wonders with this many cc:s, how many bcc:s there also were, and to whom.


There are several thousand people on the NANOG list, and public web archives.  
I don't think this
is a useful question.

FWIW, I also don't think that repurposing 240/4 is a good idea.  To be useful 
it would require
that every host on the Internet update its network stack, which would take on 
the order of
a decade, to free up some space that would likely be depleted in a year or two. 
 It's basically
the same amount of work as getting everything to work on IPv6.

R's,
John


--

Message: 8
Date: Tue, 8 Mar 2022 13:11:58 -0800
From: William Herrin <mailto:b...@herrin.us>
To: John Levine <mailto:jo...@iecc.com>
Cc: "nanog@nanog.org"<mailto:nanog@nanog.org> 
<mailto:nanog@nanog.org>
Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re:
202203071610.AYC Re: Making Use of 240/4 NetBlock)
Message-ID:

<mailto:CAP-guGVCXC_8H+wgriM=vv0bqpg4+arw0pxhcqhh7rccrxv...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

On Tue, Mar 8, 2022 at 12:34 PM John Levine 
<mailto:jo...@iecc.com> wrote:


FWIW

Re: 202203090732.AYC Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: Making Use of 240/4 NetBlock)

[Mel Beckman]

Alternatively, just use BCC. There is no reason for you to tell us who else you 
want to hear what you say. There’s nothing wrong with CCing, and nothing in the 
rules against it, but your recipients may not appreciate you distributing their 
email addresses on this list, to which they are not a member.

 -mel beckman

On Mar 9, 2022, at 9:29 AM, William Herrin  wrote:


Mr. Chen:

Would you please stop changing the subject line with an added date stamp every 
time you post? It fouls threaded email readers and is most inconsiderate.

In addition, I respectfully encourage you to trim the recipients to just the 
mailnig list and the specific individual to whom you are sending a reply.

Thanks,
Bill Herrin


On Wed, Mar 9, 2022 at 9:19 AM William Herrin 
mailto:b...@herrin.us>> wrote:
Mr. Chen:

Would you please stop changing the subject line with an added date stamp every 
time you post? It fouls threaded email readers and is most inconsiderate.

Thanks,
Bill Herrin


On Wed, Mar 9, 2022 at 9:09 AM Abraham Y. Chen 
mailto:ayc...@avinta.com>> wrote:

Dear John:

1)Thanks for your comment on how eMail headers could be used.

Dear Bill:

2)I am glad that you agree that it should be a viable discussion on making 
use of the 240/4 netblock, while waiting for IPv6 to deliver its promises.

3)As to your question about where does IPv6 stand today and where is it 
heading, I like to highlight a recent APNIC blog that you may have read. It 
also appeared on CircleID. After a long recount of the history, the author 
seems to hint that 1995 may be the new starting point for looking forward.


https://blog.apnic.net/2022/02/21/another-year-of-the-transition-to-ipv6/?utm_source=mailpoet_medium=email_campaign=apnic-blog-weekly-wrap_4

https://circleid.com/posts/20220220-another-year-of-the-transition-to-ipv6

4)We fully realize that the EzIP approach is quite unorthodox. As such, we 
received numerous quick criticisms in the past. With the proposal now put 
together, we do hope colleagues on this list will take the time to review its 
specifics. I look forward to comments and critiques on its merits.

Regards,


Abe (2022-03-09 12:08)


Message: 7
Date: 8 Mar 2022 15:32:36 -0500
From: "John Levine" <mailto:jo...@iecc.com>
To: nanog@nanog.org<mailto:nanog@nanog.org>
Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re:
        202203071610.AYC Re: Making Use of 240/4 NetBlock)
Message-ID: 
<20220308203237.53e7038b1...@ary.qy><mailto:20220308203237.53e7038b1...@ary.qy>
Content-Type: text/plain; charset=utf-8

It appears that Anne Mitchell <mailto:amitch...@isipp.com> 
said:


Cc: NANOG <mailto:nanog@nanog.org>, Greg Skinner 
<mailto:gregskinn...@icloud.com>, "Karandikar, Abhay" 
<mailto:direc...@iitk.ac.in>, Rama Ati


<mailto:rama_...@outlook.com>, Bob Corner GMAIL 
<mailto:bobbiecor...@gmail.com>, "Hsing, T. Russell" 
<mailto:ths...@ieee.org>, "Chen, Henry C.J."
<mailto:hcjc...@avinta.com>, ST Hsieh 
<mailto:uschinae...@gmail.com>, "Chen, Abraham Y." 
<mailto:ayc...@alum.mit.edu>


This is a whole lot of cc:s to people who aren't even part of this group/list.  
One wonders with this many cc:s, how many bcc:s there also were, and to whom.


There are several thousand people on the NANOG list, and public web archives.  
I don't think this
is a useful question.

FWIW, I also don't think that repurposing 240/4 is a good idea.  To be useful 
it would require
that every host on the Internet update its network stack, which would take on 
the order of
a decade, to free up some space that would likely be depleted in a year or two. 
 It's basically
the same amount of work as getting everything to work on IPv6.

R's,
John


--

Message: 8
Date: Tue, 8 Mar 2022 13:11:58 -0800
From: William Herrin <mailto:b...@herrin.us>
To: John Levine <mailto:jo...@iecc.com>
Cc: "nanog@nanog.org"<mailto:nanog@nanog.org> 
<mailto:nanog@nanog.org>
Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re:
202203071610.AYC Re: Making Use of 240/4 NetBlock)
Message-ID:

<mailto:CAP-guGVCXC_8H+wgriM=vv0bqpg4+arw0pxhcqhh7rccrxv...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

On Tue, Mar 8, 2022 at 12:34 PM John Levine 
<mailto:jo...@iecc.com> wrote:


FWIW, I also don't think that repurposing 240/4 is a good idea.  To be useful 
it would require
that every host on the Internet update its network stack,


Hi John,

That's incorrect and obviously so. While repurposing 240/4 as general
purpose Internet addresses might require that level of effort, other
uses such as local LAN addressing would only require the equipment on
that one lan to be updated -- a much more attainable goal.

Reallocating 240/4 as unpurposed unicast address space would allow
some st

Re: Making Use of 240/4 NetBlock

[John R. Levine]

On Wed, 9 Mar 2022, John Gilmore wrote:

Major networks are already squatting on the space internally, because they 
tried it and it works.


Sounds like an excellent reason not to try to use it for global unicast.

Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

V6 still not supported (was Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock))

[David Conrad]

Tim,

On Mar 9, 2022, at 9:09 AM, Tim Howe  wrote:
> Some of our biggest vendors who have supposedly supported
> v6 for over a decade have rudimentary, show-stopping bugs.

Not disagreeing (and not picking on you), but despite hearing this with some 
frequency, I haven’t seen much data to corroborate these sorts of statements.

>   A subset of these vendors will listen to you and fix the
> problems.  Give them your support and loyalty.  I want to name names so
> bad…


Perhaps the right approach would be similar for network operators to move to a 
timed full disclosure model (like Google’s Project Zero for security issues)?  
In the software security world, this model seems to have had a positive impact 
in getting fixes out. If a vendor who claims v6 support doesn’t actually 
support v6 (or, if a vendor fixes a known lack of v6 support), it would seem to 
me that this is information that folks on NANOG (and elsewhere) would find 
useful.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: 202203090732.AYC Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: Making Use of 240/4 NetBlock)

[William Herrin]

 Mr. Chen:

Would you please stop changing the subject line with an added date stamp
every time you post? It fouls threaded email readers and is most
inconsiderate.

In addition, I respectfully encourage you to trim the recipients to just
the mailnig list and the specific individual to whom you are sending a
reply.

Thanks,
Bill Herrin


On Wed, Mar 9, 2022 at 9:19 AM William Herrin  wrote:

> Mr. Chen:
>
> Would you please stop changing the subject line with an added date stamp
> every time you post? It fouls threaded email readers and is most
> inconsiderate.
>
> Thanks,
> Bill Herrin
>
>
> On Wed, Mar 9, 2022 at 9:09 AM Abraham Y. Chen  wrote:
>
>> Dear John:
>>
>> 1)Thanks for your comment on how eMail headers could be used.
>>
>> Dear Bill:
>>
>> 2)    I am glad that you agree that it should be a viable discussion on
>> making use of the 240/4 netblock, while waiting for IPv6 to deliver its
>> promises.
>>
>> 3)As to your question about where does IPv6 stand today and where is
>> it heading, I like to highlight a recent APNIC blog that you may have read.
>> It also appeared on CircleID. After a long recount of the history, the
>> author seems to hint that 1995 may be the new starting point for looking
>> forward.
>>
>>
>> https://blog.apnic.net/2022/02/21/another-year-of-the-transition-to-ipv6/?utm_source=mailpoet_medium=email_campaign=apnic-blog-weekly-wrap_4
>>
>>
>>
>> https://circleid.com/posts/20220220-another-year-of-the-transition-to-ipv6
>>
>> 4)We fully realize that the EzIP approach is quite unorthodox. As
>> such, we received numerous quick criticisms in the past. With the proposal
>> now put together, we do hope colleagues on this list will take the time
>> to review its specifics. I look forward to comments and critiques on its
>> merits.
>>
>> Regards,
>>
>>
>> Abe (2022-03-09 12:08)
>>
>>
>> Message: 7
>> Date: 8 Mar 2022 15:32:36 -0500
>> From: "John Levine"  
>> To: nanog@nanog.org
>> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re:
>>  202203071610.AYC Re: Making Use of 240/4 NetBlock)
>> Message-ID: <20220308203237.53e7038b1...@ary.qy> 
>> <20220308203237.53e7038b1...@ary.qy>
>> Content-Type: text/plain; charset=utf-8
>>
>> It appears that Anne Mitchell   
>> said:
>>
>> Cc: NANOG  , Greg Skinner 
>>  , "Karandikar, Abhay" 
>>  , Rama Ati
>>
>>  , Bob Corner GMAIL 
>>  , "Hsing, T. Russell" 
>>  , "Chen, Henry C.J." 
>> , ST Hsieh  
>> , "Chen, Abraham Y."  
>> 
>>
>> This is a whole lot of cc:s to people who aren't even part of this 
>> group/list.  One wonders with this many cc:s, how many bcc:s there also 
>> were, and to whom.
>>
>> There are several thousand people on the NANOG list, and public web 
>> archives.  I don't think this
>> is a useful question.
>>
>> FWIW, I also don't think that repurposing 240/4 is a good idea.  To be 
>> useful it would require
>> that every host on the Internet update its network stack, which would take 
>> on the order of
>> a decade, to free up some space that would likely be depleted in a year or 
>> two.  It's basically
>> the same amount of work as getting everything to work on IPv6.
>>
>> R's,
>> John
>>
>>
>> --
>>
>> Message: 8
>> Date: Tue, 8 Mar 2022 13:11:58 -0800
>> From: William Herrin  
>> To: John Levine  
>> Cc: "nanog@nanog.org"   
>> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re:
>>  202203071610.AYC Re: Making Use of 240/4 NetBlock)
>> Message-ID:
>>   
>> 
>> Content-Type: text/plain; charset="UTF-8"
>>
>> On Tue, Mar 8, 2022 at 12:34 PM John Levine  
>>  wrote:
>>
>> FWIW, I also don't think that repurposing 240/4 is a good idea.  To be 
>> useful it would require
>> that every host on the Internet update its network stack,
>>
>> Hi John,
>>
>> That's incorrect and obviously so. While repurposing 240/4 as general
>> purpose Internet addresses might require that level of effort, other
>> uses such as local LAN addressing would only require the equipment on
>> that one lan to be updated -- a much more attainable goal.
>>
>> Reallocating 240/4 as unpurposed unicast address space would allow
>> some standards-compliant uses to become practical before others. A few
>> quite

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Tim Howe]

On Wed, 9 Mar 2022 11:22:49 -0500
Tom Beecher  wrote:

> > It doesn't take any OS upgrades for "getting everything to work on
> > IPv6".  All the OS's and routers have supported IPv6 for more than a
> > decade.
> >  
> 
> There are lots of vendors, both inside and outside the networking space,
> that have consistently released products with non-existant or broken IPv6
> implementations. That includes smaller startups, as well as very big
> names. An affirmative choice is often made to make sure v4 works , get the
> thing out the door, and deal with v6 later, or if a big client complains.

This a thousand times.  Don't believe the claims of IPv6
support until you have fully tested it.  Almost no vendor is including
any IPv6 testing in their QA process and nobody is including it in any
of their support staff training.  Their labs may not even have v6
capability.  Some of our biggest vendors who have supposedly supported
v6 for over a decade have rudimentary, show-stopping bugs.  The support
staff at these vendors have often never even seen a customer using v6,
and they have no idea what it looks like on their own gear.

A subset of these vendors will listen to you and fix the
problems.  Give them your support and loyalty.  I want to name names so
bad...

--TimH

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Tom Hill]

On 09/03/2022 00:25, Tom Beecher wrote:
The only way IPv6 will ever be ubiquitous is if there comes a time where 
there is some forcing event that requires it to be.


In about two years time, IPv4 addresses will be worth on the order of 
$100/IP, assuming current trends hold.


That's a lot of revenue in leasing IPv4 to the business customers that 
refuse to think about IPv6 because $reason.


It's also a lot of unit cost to add to a consumer-grade service, where 
your margins are distastefully thin already (well, in some markets) and 
set to get thinner when you need to buy a swathe of CGNAT boxes to keep 
routing IPv4.


Even at todays's dollar price, this dilemma holds true, but I largely 
suspect that there are too few fixed-line ISPs that have been forced 
into CGNAT yet - the more that are, the more will wonder why they're 
buying so many of them.


--
Tom

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Tom Beecher]

>
> It doesn't take any OS upgrades for "getting everything to work on
> IPv6".  All the OS's and routers have supported IPv6 for more than a
> decade.
>

There are lots of vendors, both inside and outside the networking space,
that have consistently released products with non-existant or broken IPv6
implementations. That includes smaller startups, as well as very big
names. An affirmative choice is often made to make sure v4 works , get the
thing out the door, and deal with v6 later, or if a big client complains.

To be completely fair, some of those vendors also mess up IPv4
implementations as well, but in my experience , v4 stuff is more often
'vanilla' coding issues, whereas v6 mistakes tend to be more basic
functional errors, like handling leading zeros correctly.



On Wed, Mar 9, 2022 at 4:17 AM John Gilmore  wrote:

> John Levine  wrote:
> > FWIW, I also don't think that repurposing 240/4 is a good idea.  To be
> > useful it would require that every host on the Internet update its
> > network stack, which would take on the order of a decade...
>
> Those network stacks were updated for 240/4 in 2008-2009 -- a decade
> ago.  See the Implementation Status section of our draft:
>
>   https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/
>
> Major networks are already squatting on the space internally, because
> they tried it and it works.  We have running code.  The future is now.
> We are ready to update the standards.
>
> The only major OS that doesn't support 240/4 is Microsoft Windows -- and
> it comes with regular online updates.  So if IETF made the decision to
> make it unicast space, most MS OS users could be updated within less
> than a year.
>
> > It's basically
> > the same amount of work as getting everything to work on IPv6.
>
> If that was true, we'd be living in the IPv6 heaven now.
>
> It doesn't take any OS upgrades for "getting everything to work on
> IPv6".  All the OS's and routers have supported IPv6 for more than a
> decade.
>
> Whatever the IPv6 transition might require, it isn't comparable to the
> small effort needed to upgrade a few laggard OS's to support 240/4 and
> to do some de-bogonization in the global Internet, akin to what CloudFlare
> did for 1.1.1.1.
>
> John
>
>

202203081821.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[Abraham Y. Chen]

Hi, Stephen:

1)    First, logistics: Since I have been waiting for the moderation of 
my first posting on NANOG, could I assume that you are sending me this 
personal eMail as a Moderator?


2)    Perhaps the material provided in my writing was not sufficient, 
you seem to be expressing concerns from other perspectives. As concisely 
characterized by one of the "Internet fathers", the EzIP is an overlay 
network relative to the current Internet. As such, the EzIP deployment 
is pretty much independent of the hurdles that the current Internet 
equipment or convention may impose on it. That is, we can start the EzIP 
deployment leaving everything in the current Internet alone. This is 
because each EzIP deployment module, called RAN (Regional Area Network) 
is tethered via one IPv4 public address onto the Internet core. Since 
each RAN appears to be a private network, it can be set up according to 
its own requirements. That is, each RAN can make use of any desired IPv4 
technology, while leaving others aside. As long as the packets on that 
single access path between the RAN and the Internet conform to the 
Internet conventions, the deployment of the EzIP proposal should work.


3)    " ... if you plan on endpoint computers (such as those in homes) 
to use the 240/4 netblock. ...   ":    No, we do not. As presented by 
the RAN demonstration cited by the whitepaper, one of the primary 
criteria of the EzIP proposal is not to affect the current private 
network setups. Although, other than Windows OS based products, there 
are more and more IoTs do support 240/4 netblock. Even some Internet 
routers appear to do so, as well.


4)    " ... DD-WRT project? ...    ": EzIP does not have any 
ambition to alter or replace the existing Internet equipment in any 
sense. Fortunately, we can deploy our solution without such complication 
due to the overlay characteristics. Our main goal is to demonstrate that 
"*/there exists/*" one feasible configuration that can operate EzIP in 
parallel to the existing Internet for providing equivalent services. 
From such a skeletal reference, one can expand to larger deployments, 
as well as put on desired features and capabilities. For example, we 
have utilized OpenWrt 19.07.3 to demonstrate the feasibility of the EzIP 
scheme. Since the enabling technique is "disabling the program code that 
has been disabling the use of the 240/4 netblock",  any other projects 
such as DD-WRT can replicate it just as well, if so inclined.


5)    "... Firewalls ...  NIST ...   ":    Since EzIP is only 
identifying the additional address resources from the "Reserve" and 
suggesting how to use it, I am not clear why high level functionalities 
such as security related firewall tasks get involved here. Do NIST 
Guidelines specify blocking any packet with the 240/4 netblock address? 
I failed to spot such.  Since there is no natural division between the 
240/4 netblock from the rest of IPv4 address pool, I can't see any 
reason to single this netblock out in the firewall related tasks anyway. 
Do you know the reason why? I would appreciate very much if you could 
elaborate your concerns.


6)    By the way, the EzIP's RAN is actually very much the same as 
CG-NAT or CDN, architecturally.  The only difference is that EzIP 
Project manged to identify a larger usable address pool enabling the 
practice of static addressing to simplify operation logistics, mitigate 
cyber insecurity, etc.



I look forward to your thoughts.


Regards,


Abe (2022-03-09 23:28 EST)



On 2022-03-08 13:08, Stephen Satchell wrote:

On 3/7/22 2:14 PM, Abraham Y. Chen wrote:
 In a nutshell, EzIP proposes to disable the program codes in 
current routers that have been disabling the use of the 240/4 
NetBlock. The cost of this software engineering should be minimal. 
The EzIP deployment architecture is the same as that of the existing 
CG-NAT (Carrier Grade Network Address Translation). Consequently, 
there is no need to modify any hardware equipment. There is an online 
setup description (Reference II), called RAN (Regional Area Network), 
that demonstrates the feasibility of this approach.


You have another surface that will need to dealt with if you plan on 
endpoint computers (such as those in homes) to use the 240/4 netblock. 
You will need to talk to the authors of firewall books and web sites 
to update the examples to remove all-traffic blocks on 240/4.  Then 
individual administrations, not just ISP/Service-Provider, will need 
to know to modify any home-brew firewalls to open all addresses except 
255.255.255.255 (and perhaps 240.0.0.0).


That includes my publications about firewall configurations.

If you haven't already, you will need to include makers of access 
points and companies such as SonicWALL.  Have you talked to pfSense?  
DD-WRT project?  UFW project?  firewalld project?  The Berkeley Packet 
Filter project?  How about authors of the NIST _Guidelines on 
Firewalls and Firewall Policy_