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: 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: 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: 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: 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&countries=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&countries=in
https://www.vyncke.org/ipv6status/compare.php?metric=k&countries=in
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=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&countries=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: 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: 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&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
Virus-free. www.avast.com

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_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&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_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: 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: 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&ab_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: 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: 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: 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.

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: 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_ public

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

[John Gilmore]

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

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

[bzs]

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| 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: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Dave Taht]

On Tue, Mar 8, 2022 at 11:30 PM Mark Andrews  wrote:
>
> Given the draft lies about the status of 127/8.  Words have meanings.
>
>When all of 127.0.0.0/8 was reserved for loopback addressing, IPv4
>addresses were not yet recognized as scarce.  Today, there is no
>justification for allocating 1/256 of all IPv4 addresses for this
>purpose, when only one of these addresses is commonly used and only a
>handful are regularly used at all.  Unreserving the majority of these
>addresses provides a large number of additional IPv4 host addresses
>for possible use, alleviating some of the pressure of IPv4 address
>exhaustion.
>
> It is not RESERVED, it is ASSIGNED.
>
>  The class A network number 127 is assigned the "loopback"
>  function, that is, a datagram sent by a higher level protocol
>  to a network 127 address should loop back inside the host.  No
>  datagram "sent" to a network 127 address should ever appear on
>  any network anywhere.
>
> If it was actually reserved there would be much less complaint.  People
> have made use of that space based on the fact that it was ASSIGNED a
> purpose whether you like that or feel that it was a good use of resources.
>
> Compulsory acquisition is something that should not be done lightly.  It
> also requires fair compensation to be paid.
>
> > On 9 Mar 2022, at 13:35, Seth David Schoen  wrote:
> >
> > John R. Levine writes:
> >
> >> This still doesn't mean that screwing around with 240/4 or, an even worse
> >> 127/8 minus 127/24, is a good idea.
> >
> > I hope you'll be slightly mollified to learn that it's actually 127/8
> > minus 127/16.
> >
> > https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-127/
> >
> > That's the most challenging one, but we've still seen something of a
> > lack of people getting in touch to point out concrete problems.
> >
> > One person did get in touch to describe an unofficial use of, apparently,
> > all of 127/8 as private address space in a VPN product.  If people let
> > us know about more, we can investigate workarounds or possible changes
> > to our proposals.
>
> What’s “unofficial” about it?  The point of ASSIGNING 127/8 for loopback
> meant the ANYONE could use that address space OFFICIALLY so long as packets
> with those addresses didn’t leave the machine.

re: *the machine*.

This touches upon the one use case I've come up with for narrowing the
scope of the loopback 127.x,
and widening it slightly.

What is a "machine"? nowadays there are fleets of microservices
(:cough: kubernetes) being deployed.
Crossing a security barrier within one machine is one thing, crossing
it into the wire between machines,
another. Local compute, separated by vms or containers, is often
orders of magnitude faster than going
over a wire, and a cluster of those can be carried from physical
machine to physical machine.

I otherwise don't want to be drawn into the tar-baby discussion about
127, it's discussion of utilizing 240/4
sanely and 0/8 sanely I desire more.


>
> > We previously thought that the reference NTP implementation was using
> > all of 127/8 to identify hardware clock drivers.  But it turns out it
> > doesn't actually connect to these.
> >
> > If anyone reading this knows of something that uses a loopback address
> > outside of 127/16 for an application, or something that can't be updated
> > and would be harmed if the rest of the network stopped treating this as
> > loopback, we'd be glad to hear about it.
>
> What does it matter what people are using those addresses for.  They are
> using them in good faith and are under no obligation to report how they
> are using them.
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>


-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

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

[Mark Andrews]

Given the draft lies about the status of 127/8.  Words have meanings.

   When all of 127.0.0.0/8 was reserved for loopback addressing, IPv4
   addresses were not yet recognized as scarce.  Today, there is no
   justification for allocating 1/256 of all IPv4 addresses for this
   purpose, when only one of these addresses is commonly used and only a
   handful are regularly used at all.  Unreserving the majority of these
   addresses provides a large number of additional IPv4 host addresses
   for possible use, alleviating some of the pressure of IPv4 address
   exhaustion.

It is not RESERVED, it is ASSIGNED.

 The class A network number 127 is assigned the "loopback"
 function, that is, a datagram sent by a higher level protocol
 to a network 127 address should loop back inside the host.  No
 datagram "sent" to a network 127 address should ever appear on
 any network anywhere.

If it was actually reserved there would be much less complaint.  People
have made use of that space based on the fact that it was ASSIGNED a
purpose whether you like that or feel that it was a good use of resources.

Compulsory acquisition is something that should not be done lightly.  It
also requires fair compensation to be paid.

> On 9 Mar 2022, at 13:35, Seth David Schoen  wrote:
> 
> John R. Levine writes:
> 
>> This still doesn't mean that screwing around with 240/4 or, an even worse
>> 127/8 minus 127/24, is a good idea.
> 
> I hope you'll be slightly mollified to learn that it's actually 127/8
> minus 127/16.
> 
> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-127/
> 
> That's the most challenging one, but we've still seen something of a
> lack of people getting in touch to point out concrete problems.
> 
> One person did get in touch to describe an unofficial use of, apparently,
> all of 127/8 as private address space in a VPN product.  If people let
> us know about more, we can investigate workarounds or possible changes
> to our proposals.

What’s “unofficial” about it?  The point of ASSIGNING 127/8 for loopback
meant the ANYONE could use that address space OFFICIALLY so long as packets
with those addresses didn’t leave the machine.

> We previously thought that the reference NTP implementation was using
> all of 127/8 to identify hardware clock drivers.  But it turns out it
> doesn't actually connect to these.
> 
> If anyone reading this knows of something that uses a loopback address
> outside of 127/16 for an application, or something that can't be updated
> and would be harmed if the rest of the network stopped treating this as
> loopback, we'd be glad to hear about it.

What does it matter what people are using those addresses for.  They are
using them in good faith and are under no obligation to report how they
are using them.

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

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

[Owen DeLong via NANOG]

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


> On Mar 8, 2022, at 18:35, Seth David Schoen  wrote:
> 
> John R. Levine writes:
> 
>> This still doesn't mean that screwing around with 240/4 or, an even worse
>> 127/8 minus 127/24, is a good idea.
> 
> I hope you'll be slightly mollified to learn that it's actually 127/8
> minus 127/16.
> 
> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-127/
> 
> That's the most challenging one, but we've still seen something of a
> lack of people getting in touch to point out concrete problems.
> 
> One person did get in touch to describe an unofficial use of, apparently,
> all of 127/8 as private address space in a VPN product.  If people let
> us know about more, we can investigate workarounds or possible changes
> to our proposals.
> 
> We previously thought that the reference NTP implementation was using
> all of 127/8 to identify hardware clock drivers.  But it turns out it
> doesn't actually connect to these.
> 
> If anyone reading this knows of something that uses a loopback address
> outside of 127/16 for an application, or something that can't be updated
> and would be harmed if the rest of the network stopped treating this as
> loopback, we'd be glad to hear about it.

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

[Seth David Schoen]

John R. Levine writes:

> This still doesn't mean that screwing around with 240/4 or, an even worse
> 127/8 minus 127/24, is a good idea.

I hope you'll be slightly mollified to learn that it's actually 127/8
minus 127/16.

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

That's the most challenging one, but we've still seen something of a
lack of people getting in touch to point out concrete problems.

One person did get in touch to describe an unofficial use of, apparently,
all of 127/8 as private address space in a VPN product.  If people let
us know about more, we can investigate workarounds or possible changes
to our proposals.

We previously thought that the reference NTP implementation was using
all of 127/8 to identify hardware clock drivers.  But it turns out it
doesn't actually connect to these.

If anyone reading this knows of something that uses a loopback address
outside of 127/16 for an application, or something that can't be updated
and would be harmed if the rest of the network stopped treating this as
loopback, we'd be glad to hear about it.

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

[Seth David Schoen]

John Levine writes:

> FWIW, I also don't think that repurposing 240/4 is a good idea.

As people will be aware, we have a different draft on this issue, so
I'm also going to pipe up here.

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

(Our draft offers no specific plan for exactly how to use the address
space, arguing that the most important short-term priority is to ensure
that implementations stop rejecting it, rather than to decide on a policy
for how or when it can be allocated.  For example, it might turn out that
debogonization appears too daunting a task, in which case there might be
a consensus to make it into official private address space in the future.)

> To be useful it would require that every host on the Internet update
> its network stack,

Most hosts other than Windows already made this change following the
previous proposal in 2008.  So we mostly have to get Windows to make the
change now.

Routers are a more complicated question, and we would love people to help
us obtain some concrete data about this.

> which would take on the order of a decade, to free up some space that
> would likely be depleted in a year or two.

When I presented about this at NANOG 84 and APRICOT recently, I noted
that a lot of people's intuitions about rapid exhaustion of IPv4
resources come from RIR allocations that were done with nominal fees.
But blocks that became available and were sold for market rates seemed
to last longer.  We think that, if it does become feasible to allocate
historically-reserved space for public Internet use, market-based
allocations like auction mechanisms (which can potentially also be done
by RIRs) will make people more cautious in their appetite for number
resources, while also preventing the price of those resources from rising
as quickly as it otherwise would.

Someone asked a question about how long we thought it would take for
that depletion to occur, and I passed it on to Lee Howard (on account
of his experience in the IPv4 secondary markets).  I think I remember
that his answer was "about seven years" -- I should double-check that
it wasn't six years or eight years.  I understood the question I was
passing on to be something like "how long will these resources last,
assuming RIRs allocate them by selling them in a series of auctions or
selling them into existing address space markets as though they were
newly-recovered previously-allocated address space?".

> It's basically the same amount of work as getting everything to work
> on IPv6.

That's challenging to quantify, but in any case it doesn't appear to be
_the same work_ or, necessarily, _work by the same people_.  For
example, Windows already supports IPv6 quite well, but doesn't support
unicast 240/4 at all.  My Linux laptop supports both well, but my ISP
doesn't give me native IPv6.  (I don't know yet whether or not my ISP
would have to make changes to support native 240/4, although I look
forward to finding out!)

I don't want people to work to support 240/4 (and other address ranges
we've proposed unreserving) at the expense of supporting IPv6.  I agree
with the consensus that implementers and operators ought to support
IPv6.  Still, I haven't seen why one can be expected to substitute for
or compete with the other, unless one envisions a very direct conflict
between improving IPv4 support or services and improving IPv6 support
or services.

We also have a new draft (published yesterday) more directly on point
about that issue...

https://datatracker.ietf.org/doc/draft-schoen-intarea-ietf-maintaining-ipv4/

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

[John R. Levine]

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 agree.  There is a great deal of unused or underused v4 space that 
increasing prices have found and even if the long term cost of setting up 
v6 is lower, it's more than the short term cost to buy another v4 block.


This still doesn't mean that screwing around with 240/4 or, an even worse 
127/8 minus 127/24, is a good idea.


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: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Masataka Ohta]

John Levine wrote:


Oh, absolutely.  I have conversations with my hosting provider in which
they tell me that nobody has ever asked for IPv6 other than me, and they
had no idea their upstream (Spectrum) had native IPv6.  So I keep using
a tunnel.


Why do you think you need IPv6?

What is the point to have a tunnel even if people, maybe excluding you,
are fine without it?

Masataka Ohta

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

[Nathan Angelacos]

On Tue, 2022-03-08 at 19:25 -0500, 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. 


Exactly.   The only thing I see changing anything is when the MTU gets
low enough that you are sending more encapsulation headers than
payload.   When the effective MTU is 8, then... But by then I'll have a
1Tb link to my house... so who cares?!

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

[John Kristoff]

On 8 Mar 2022 19:14:34 -0500
"John Levine"  wrote:

> I have conversations with my hosting provider in which they tell me
> that nobody has ever asked for IPv6 other than me,

Oh you too?  I got that response all the time.  Then I when I press,
they usually say they've had one, two, three, maybe four others ask over
some really long period of time.  The good news is most hosting
providers I've dealt with in the past few years have v6 support now.
Those that don't seem to be in the minority now from what I can tell.

When I was a college DJ, the older people used to tell me for each
phone call I get into the show figure you have about 100 listeners.
I'm sure that was a WAG, but I bet there is some 1 to x ratio of others
out there that just aren't calling about IPv6.

John

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

[Tom Beecher]

>
> Is it not past time we admit that we have no real idea what the
> schedule or level of effort will be for making IPv6 ubiquitous? This
> year it was more than last year and next year it'll probably be more
> than this year. The more precise predictions all seem to have fallen
> flat.
>

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.

On Tue, Mar 8, 2022 at 4:13 PM William Herrin  wrote:

> 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 quickly.
>
>
> > 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.
>
> Is it not past time we admit that we have no real idea what the
> schedule or level of effort will be for making IPv6 ubiquitous? This
> year it was more than last year and next year it'll probably be more
> than this year. The more precise predictions all seem to have fallen
> flat.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

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

[John Levine]

It appears that William Herrin  said:
>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.

If you want to patch your devices so they use 240/4 as a version of
10/8 on your own network, you can do that any time you want.

>Reallocating 240/4 as unpurposed unicast address space would allow
>some standards-compliant uses to become practical before others. A few
>quite quickly.

So long as we agree that "quickly" means a decade.  If we did this bad idea,
at some point there would be a tipping point where enough hosts recognized
them to be useful, but we say the same thing about IPv6.

>Is it not past time we admit that we have no real idea what the
>schedule or level of effort will be for making IPv6 ubiquitous?

Oh, absolutely.  I have conversations with my hosting provider in which
they tell me that nobody has ever asked for IPv6 other than me, and they
had no idea their upstream (Spectrum) had native IPv6.  So I keep using
a tunnel.  I would expect the same conversations about 240/4.

R's,
John

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

[William Herrin]

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 quickly.


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

Is it not past time we admit that we have no real idea what the
schedule or level of effort will be for making IPv6 ubiquitous? This
year it was more than last year and next year it'll probably be more
than this year. The more precise predictions all seem to have fallen
flat.

Regards,
Bill Herrin


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

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

[John Levine]

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

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

[Anne Mitchell]

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

Anne

--
Anne P. Mitchell, Attorney at Law
CEO Get to the Inbox by SuretyMail
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing law)
Author: The Email Deliverability Handbook
Board of Directors, Denver Internet Exchange
Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
Prof. Emeritus, Lincoln Law School
Chair Emeritus, Asilomar Microcomputer Workshop
Legal Counsel: The CyberGreen Institute
In-house Counsel: Mail Abuse Prevention System (MAPS) (Closed in 2004)


> On Mar 8, 2022, at 8:46 AM, Abraham Y. Chen  wrote:
> 
> Hi, Tom:
> 
> 0)Thanks to your thoughts.
> 
> 1)First, logistics: Since this was my first post to this Forum, I got an 
> auto-response stating that my post was being moderated. Then, I got your 
> message even before I received any follow-up notice from such, nor my writing 
> being published. Are you responding to the general distribution or acting as 
> a moderator?
> 
> 2)"  an overly convoluted mechanism to tunnel 240/4. ":We 
> started our work due to curiosity. As we made progresses in various areas, 
> quite a few topics have distilled to a different yet much clearer picture. 
> Allow me to describe the current EzIP proposal with respect to these aspects: 
>   
> 
> A."overly convoluted":EzIP proposes to make use of the 
> long-reserved 240/4 NetBlock by utilizing the RFC791 to carry it.  However, 
> this is only needed for the long term full end-to-end deployment. For the 
> immediate EzIP configuration that is for supporting the current Server / 
> Client (Master /Slave) model (similar to the current CG-NAT, or CDN), EzIP 
> will be using a degenerated configuration which we call it RAN (Regional Area 
> Network) where the standard IPv4 packet header will be suffice, even without 
> the RFC791. I believe these schemes are opposite to "convoluted".  
> 
> B."tunnel":Instead of tunneling in the current sense of 6to4 
> tunneling, or similar, which interacts with the parameters of transmission 
> environment, EzIP is an overlay network consisting of RANs (Regional Area 
> Networks), each is tethered from the current Internet via one IPv4 public 
> address. Since each RAN appears to be a private network to the Internet core, 
> pretty much everything in the RAN is independent of the latter.  Direct 
> communications between IoTs residing in separate RANs, when needed, will 
> still be carried by native IPv4 packets (with the addition of Option Words 
> carrying IoTs' Source and Destination addresses within the host RANs, 
> respectively).  
> 
> Could you please clarify your characterizations of the above?
> 
> 
> 
> Regards,
> 
> 
> 
> 
> 
> Abe (2022-03-08 10:46)
> 
> 
> 
> 
> 
> On 2022-03-08 09:09, Tom Beecher wrote:
>> I recall reading the IETF draft some time ago. It seemed like an overly 
>> convoluted mechanism to tunnel 240/4. 
>> 
>> On Tue, Mar 8, 2022 at 8:50 AM Abraham Y. Chen  wrote:
>> Dear Colleagues:
>> 
>> 0)I was made aware of a recent discussion on this Forum that cited our 
>> work on the 240/4 NetBlock, nicknamed EzIP (Phonetic for Easy IPv4). (Please 
>> see, at the end of this MSG, the URL to the discussion and the highlighted 
>> text where the citation was made.)
>> 
>> 1)As the lead investigator of the EzIP Project, I would like to  
>> formally introduce our solution by bringing your attention to an overview 
>> whitepaper:
>> 
>> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>> 
>> 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.
>> 
>> 2)There are additional consequential benefits by deploying EzIP, such as 
>> those mentioned by our comment to Reference III in the above whitepaper.
>> 
>> I look forward to addressing your thoughts.
>> 
>> 
>> Regards,
>> 
>> 
>> 
>> Abe (2022-03-07 17:14 EST)
>> VP Engineering
>> Avinta Communications, Inc.
>> Milpitas, CA 95035 USA
>> +1(408)942-1485
>> Skype: Abraham.Y.Chen
>> eMail: ayc...@avinta.com
>> WebSite: www.Avinta.com
>> 
>> 
>> ***
>> 
>> https://mailman.nanog.org/pipermail/nanog/2021-November/216766.html
>> 
>> Class D addresses? was: Redploying m

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

[Abraham Y. Chen]

Hi, Tom:

0)    Thanks to your thoughts.

1)    First, logistics: Since this was my first post to this Forum, I 
got an auto-response stating that my post was being moderated. Then, I 
got your message even before I received any follow-up notice from such, 
nor my writing being published. Are you responding to the general 
distribution or acting as a moderator?


2)    "  an overly convoluted mechanism to tunnel 240/4.     
":    We started our work due to curiosity. As we made progresses in 
various areas, quite a few topics have distilled to a different yet much 
clearer picture. Allow me to describe the current EzIP proposal with 
respect to these aspects:


    A.    "overly convoluted":    EzIP proposes to make use of the 
long-reserved 240/4 NetBlock by utilizing the RFC791 to carry it.  
However, this is only needed for the long term full end-to-end 
deployment. For the immediate EzIP configuration that is for supporting 
the current Server / Client (Master /Slave) model (similar to the 
current CG-NAT, or CDN), EzIP will be using a degenerated configuration 
which we call it RAN (Regional Area Network) where the standard IPv4 
packet header will be suffice, even without the RFC791. I believe these 
schemes are opposite to "convoluted".


    B.    "tunnel": Instead of tunneling in the current sense of 6to4 
tunneling, or similar, which interacts with the parameters of 
transmission environment, EzIP is an */overlay/* network consisting of 
RANs (Regional Area Networks), each is tethered from the current 
Internet via one IPv4 public address. Since each RAN appears to be a 
private network to the Internet core, pretty much everything in the RAN 
is independent of the latter. Direct communications between IoTs 
residing in separate RANs, when needed, will still be carried by native 
IPv4 packets (with the addition of Option Words carrying IoTs' Source 
and Destination addresses within the host RANs, respectively).



    Could you please clarify your characterizations of the above?


Regards,



Abe (2022-03-08 10:46)





On 2022-03-08 09:09, Tom Beecher wrote:
I recall reading the IETF draft some time ago. It seemed like an 
overly convoluted mechanism to tunnel 240/4.


On Tue, Mar 8, 2022 at 8:50 AM Abraham Y. Chen  wrote:

Dear Colleagues:

0)    I was made aware of a recent discussion on this Forum that
cited our work on the 240/4 NetBlock, nicknamed EzIP (Phonetic for
Easy IPv4). (Please see, at the end of this MSG, the URL to the
discussion and the highlighted text where the citation was made.)

1)    As the lead investigator of the EzIP Project, I would like
to  formally introduce our solution by bringing your attention to
an overview whitepaper:

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

    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.

2)    There are additional consequential benefits by deploying
EzIP, such as those mentioned by our comment to Reference III in
the above whitepaper.

I look forward to addressing your thoughts.


Regards,


Abe (2022-03-07 17:14 EST)
VP Engineering
Avinta Communications, Inc.
Milpitas, CA 95035 USA
+1(408)942-1485
Skype: Abraham.Y.Chen
eMail: ayc...@avinta.com
WebSite: www.Avinta.com 


***

https://mailman.nanog.org/pipermail/nanog/2021-November/216766.html


  Class D addresses? was: Redploying most of 127/8 as unicast public

*Greg Skinner* gregskinner0 at icloud.com


/Mon Nov 29 18:47:14 UTC 2021/

  * Previous message (by thread): Class D addresses? was:
Redploying most of 127/8 as unicast public

  * Next message (by thread): Class E addresses? 240/4 history

  * *Messages sorted by:* [ date ]


[ thread ]


[ subject ]


[ author ]
  

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

[Tom Beecher]

I recall reading the IETF draft some time ago. It seemed like an overly
convoluted mechanism to tunnel 240/4.

On Tue, Mar 8, 2022 at 8:50 AM Abraham Y. Chen  wrote:

> Dear Colleagues:
>
> 0)I was made aware of a recent discussion on this Forum that cited our
> work on the 240/4 NetBlock, nicknamed EzIP (Phonetic for Easy IPv4).
> (Please see, at the end of this MSG, the URL to the discussion and the
> highlighted text where the citation was made.)
>
> 1)As the lead investigator of the EzIP Project, I would like to
> formally introduce our solution by bringing your attention to an overview
> whitepaper:
>
> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
> 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.
>
> 2)There are additional consequential benefits by deploying EzIP, such
> as those mentioned by our comment to Reference III in the above whitepaper.
> I look forward to addressing your thoughts.
>
>
> Regards,
>
>
> Abe (2022-03-07 17:14 EST)
> VP Engineering
> Avinta Communications, Inc.
> Milpitas, CA 95035 USA
> +1(408)942-1485
> Skype: Abraham.Y.Chen
> eMail: ayc...@avinta.com
> WebSite: www.Avinta.com
>
>
> ***
>
> https://mailman.nanog.org/pipermail/nanog/2021-November/216766.html
> Class D addresses? was: Redploying most of 127/8 as unicast public *Greg
> Skinner* gregskinner0 at icloud.com
> 
> *Mon Nov 29 18:47:14 UTC 2021*
>
>- Previous message (by thread): Class D addresses? was: Redploying
>most of 127/8 as unicast public
>
>- Next message (by thread): Class E addresses? 240/4 history
>
>- *Messages sorted by:* [ date ]
> 
> [
>thread ]
>
>  [
>subject ]
>
>  
> [
>author ]
>
> 
>
> --
>
> >* On Nov 24, 2021, at 5:08 PM, William Herrin  >> wrote:
> *> >* On Wed, Nov 24, 2021 at 4:36 PM David Conrad  > wrote:
> *>>>* I like research but what would the RIRs study? The percentage of the
> *>> >>* Lots of people said similar things when 1.0.0.0/8  
> was allocated to APNIC
> *>>* and they said similar things when 1.1.1.0/24  was 
> stood up as an
> *>>* experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty 
> popular.
> *> >* Hi David,
> *> >* I don't recall there being any equipment or software compatibility
> *>* concerns with 1.0.0.0/8 . If you do, feel free to 
> refresh my memory. As
> *>* I recall it, there were concerns with prior local use and potential
> *>* trash traffic. It seemed likely those concerns could be addressed with
> *>* experiments, and the experiments in fact addressed them.
> *> >* The prior local use worry reared its head again with 240/4 but given
> *>* the prior experience with 1.0.0.0/8  I don't personally 
> believe we need
> *>* to re-run that experiment just because the numbers are part of a
> *>* different block.
> *> > >>* Seems to me that a number of folks on this list and during this
> *>>* discussion would disagree with a blanket assertion that 240/4
> *>>* is “dysfunctional on the 2021 Internet” - some of them even
> *>>* wrote a draft discussing the possibility.
> *> >* Line them up. Show of hands. Who really thinks that if we assign
> *>* 240.0.0.1 to a customer tomorrow without waiting for anyone to clean
> *>* up their software and hardware, you won't get enough complaints about
> *>* things not working that you have to take it back and assign a
> *>* different address instead?
> *> > >>* 1. Move 240/4 from "reserved" to "unallocated unicast"
> *>> >>* OK, but this seems like a quibble.  The status for 240/4 is “
> *>>* RESERVED: designated by the IETF for specific non-global-unicast
> *>>* purposes as noted.”  The “as noted” part is “Future Use”.
> *> >* It's not a quibble. Some vendors take the current status to mean
> *>* "treat it like unicast until we're told otherwise." Others take the
> *>* status to mean, "packets with these a