Re: 240/4 (Re: 44/8)

[Greg Skinner via NANOG]

> On Jul 22, 2019, at 9:15 PM, Ross Tajvar  wrote:
> 
>> Editor's note: This draft has not been submitted to any formal
>> process.  It may change significantly if it is ever submitted.
>> You are reading it because we trust you and we value your
>> opinions.  *Please do not recirculate it.*  Please join us in
>> testing patches and equipment!
> 
> (emphasis mine)
> 
> Interesting choice to host it in a public Github repo, then...
> 

Funny, that …

BTW, there are a few missing links in the References that some of you may find 
useful:

[IEN48]Cerf, V., "The CATENET MODEL FOR INTERNETWORKING", 1978,


[IETF-13]  Gross, P., Bowers, K., "IETF Proceedings", 1989,


[IHML] Many, T., "Internet History Mailing list", 2019,


Dave Täht and John Gilmore raised issues discussed in the draft in the February 
2019 

 and March 2019 
 
internet-history list archives, respectively.

FWIW, here are some additional resources:

IPv4 Unicast Extensions Netdevconf preso, March 2019 


The IPv4 Cleanup Project GitHub repo 


—gregbo

Re: 240/4 (Re: 44/8)

[Ross Tajvar]

>  Editor's note: This draft has not been submitted to any formal
>  process.  It may change significantly if it is ever submitted.
>  You are reading it because we trust you and we value your
>  opinions.  *Please do not recirculate it.*  Please join us in
>  testing patches and equipment!

(emphasis mine)

Interesting choice to host it in a public Github repo, then...

On Mon, Jul 22, 2019 at 11:17 PM Mikael Abrahamsson 
wrote:

> On Mon, 22 Jul 2019, Owen DeLong wrote:
>
> >   2.  It was decided that the effort to modify each and every IP
> stack in order to facilitate use of this relatively small block (16 /8s
> being evaluated against a global
> >   run rate at the time of roughly 2.5 /8s per month, mostly
> to RIPE and APNIC) vs. putting that same effort into modifying each and
> every IP stack to support
> >   IPv6 was an equation of very small benefit for slightly
> smaller cost. (Less than 8 additional months of IPv4 free pool vs.
> hopefully making IPv6 deployable
> >   before IPv4 ran out).
>
> Well, people are working on making 240/4 usable in IP stacks:
>
>
> https://raw.githubusercontent.com/dtaht/unicast-extensions/master/rfcs/draft-gilmore-taht-v4uniext.txt
>
> There have been patches accepted into some BSDs and into Linux
> tools/kernel and other operating systems to make 240/4 configurable and
> working as unicast space.
>
> I don't expect it to show up in DFZ anytime soon, but some people have
> dilligently been working on removing any obstacles to using 240/4 in most
> common operating systems.
>
> For controlled environments, it's probably deployable today with some
> caveats. I think it'd be fine as a compliment to RFC1918 space for some
> internal networks.
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>

Re: 240/4 (Re: 44/8)

[George Herbert]

Most importantly, if you're running out of 1918 space is a totally
different problem than running out of global routable space.

If you patch common OSes for 240/4 usability but a significant fraction of
say unpatched OSes, IOT, consumer routers, old random net cruft necessary
for infrastructure aren't patched... it's not actually globally routable.
At some point you can write off the few stragglers but... really, get IPv6
everywhere.

On Mon, Jul 22, 2019 at 8:50 PM Owen DeLong  wrote:

>
>
> > On Jul 22, 2019, at 20:14 , Mikael Abrahamsson  wrote:
> >
> > On Mon, 22 Jul 2019, Owen DeLong wrote:
> >
> >>  2.  It was decided that the effort to modify each and every IP
> stack in order to facilitate use of this relatively small block (16 /8s
> being evaluated against a global
> >>  run rate at the time of roughly 2.5 /8s per month, mostly
> to RIPE and APNIC) vs. putting that same effort into modifying each and
> every IP stack to support
> >>  IPv6 was an equation of very small benefit for slightly
> smaller cost. (Less than 8 additional months of IPv4 free pool vs.
> hopefully making IPv6 deployable
> >>  before IPv4 ran out).
> >
> > Well, people are working on making 240/4 usable in IP stacks:
> >
> >
> https://raw.githubusercontent.com/dtaht/unicast-extensions/master/rfcs/draft-gilmore-taht-v4uniext.txt
> >
> > There have been patches accepted into some BSDs and into Linux
> tools/kernel and other operating systems to make 240/4 configurable and
> working as unicast space.
> >
> > I don't expect it to show up in DFZ anytime soon, but some people have
> dilligently been working on removing any obstacles to using 240/4 in most
> common operating systems.
> >
> > For controlled environments, it's probably deployable today with some
> caveats. I think it'd be fine as a compliment to RFC1918 space for some
> internal networks.
> >
> > --
> > Mikael Abrahamssonemail: swm...@swm.pp.se
>
> I guess people can do whatever they want. I personally consider it to be a
> sad sad waste of time that could be better spent deploying IPv6 to more
> places.
>
> Owen
>
>

-- 
-george william herbert
george.herb...@gmail.com

Re: 240/4 (Re: 44/8)

[Owen DeLong]

> On Jul 22, 2019, at 20:14 , Mikael Abrahamsson  wrote:
> 
> On Mon, 22 Jul 2019, Owen DeLong wrote:
> 
>>  2.  It was decided that the effort to modify each and every IP 
>> stack in order to facilitate use of this relatively small block (16 /8s 
>> being evaluated against a global
>>  run rate at the time of roughly 2.5 /8s per month, mostly to 
>> RIPE and APNIC) vs. putting that same effort into modifying each and every 
>> IP stack to support
>>  IPv6 was an equation of very small benefit for slightly smaller 
>> cost. (Less than 8 additional months of IPv4 free pool vs. hopefully making 
>> IPv6 deployable
>>  before IPv4 ran out).
> 
> Well, people are working on making 240/4 usable in IP stacks:
> 
> https://raw.githubusercontent.com/dtaht/unicast-extensions/master/rfcs/draft-gilmore-taht-v4uniext.txt
> 
> There have been patches accepted into some BSDs and into Linux tools/kernel 
> and other operating systems to make 240/4 configurable and working as unicast 
> space.
> 
> I don't expect it to show up in DFZ anytime soon, but some people have 
> dilligently been working on removing any obstacles to using 240/4 in most 
> common operating systems.
> 
> For controlled environments, it's probably deployable today with some 
> caveats. I think it'd be fine as a compliment to RFC1918 space for some 
> internal networks.
> 
> -- 
> Mikael Abrahamssonemail: swm...@swm.pp.se

I guess people can do whatever they want. I personally consider it to be a sad 
sad waste of time that could be better spent deploying IPv6 to more places.

Owen

Re: 240/4

[Daniel Senie]

At 02:29 PM 10/16/2007, Pekka Savola wrote:



On Tue, 16 Oct 2007, Alain Durand wrote:

Classifying it as private use should come with the health warning use this
at your own risk, this stuff can blow up your network. In other words, this
is for experimental use only.


Do we need to classify anything (yet)?


Yes.


I say the proof is in the pudding.  Once some major user decides 
they'll need 240/4 for something, they'll end up knocking their 
vendors' (probably dozens) and their own ops folks' doors.  Once 
they get those vendors fixed up to support 240/4 in all the releases 
that they're interested in, and ops to change configs, they can 
deploy something in 240/4 for whatever (most likely private use, or 
private use with a NAT to the outside).


It would behoove us to allocate SOME of 240/4 as private address 
space, and mark the rest as future, allocatable if it's deemed 
possible. If all of 240/4 is given over without guidance to private 
address use, a huge mess will follow, should we later decide it safe 
to use on the public network.



If the users decide that maybe doing the legwork is too difficult.. 
well, maybe that's a sign that deploying 240/4 isn't worth the 
trouble (yet) and reclassifying would also be premature.


It's not like the IETF or any other body is holding 240/4 hostage or 
something.


Yes, actually, it's specifically reserved, and it's in a block above 
multicast. I'm sure I was not the only one who saw that and said 
this probably won't be 'normal' address space. If it's going to be 
used as unicast space, then it'd be helpful for an RFC to say so. 
However, I doubt that would happen, as it will likely be shouted down 
by those who see it as a threat to IPv6 deployment.


  It's what the vendors' code and what ops folks have configured 
that matters.  If the code and configs can be changed and widely 
deployed, we have some proof that doing this might make sense at 
least in some context.  Prior to that, there is no need to do anything.


Make a few /8's out of it available for experimental, private use. 
See what happens. But don't just throw the entire /4 out there for 
private use. We may later find it actually usable (or we may not) and 
want to visit that possibility later.

Re: 240/4

[Bill Stewart]

On 10/16/07, Justin M. Streiner [EMAIL PROTECTED] wrote:
  The effort someone would spend figuring out if 204/4 is reachable and
  not-pain-inducing in their infrastructure is better spent figuring out how 
  to
  make IPv6 work within their sphere of responsibilities.
 I agree.  The current rate at which blocks of IPv4 space are being
 allocated to the RIRs suggests that releasing a chunk from, say, 240/5 or
 248/5 for consumption gets you about 1 year, tops.

A year is good.  My recommendation would be to adamantly refuse to let the RIRs
assign it for public space and insist that it's for experimental use only,
even though these days the place for research is IPv6 or its
interaction with IPv4,
and maybe even put out some interesting but not actually useful piece
of researchware
such as RFC1149bis (homeland security emergency warning notification
via location-agile mobile distribution of audio recordings using
peer-to-peer avian carriers.)

Then when we actually do run out of IPv4 space and major players start
complaining
that they're Just Not Ready for IPv6, because you know that's going to happen,
have the RFC author grudgingly agree to release the space and retarget
the research,
giving the carriers and other players one more year to get serious.

-- 

 Thanks; Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.