Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-19 Thread Joe Maimon
Owen DeLong via NANOG wrote: I don’t see the difference between 6 and 7 usable addresses on all the /29s in the world as actually making a significant impact on the usable lifespan of IPv4. Owen This idea gets better each time I think about it. The changes and support required would typic

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-19 Thread Owen DeLong via NANOG
I don’t see the difference between 6 and 7 usable addresses on all the /29s in the world as actually making a significant impact on the usable lifespan of IPv4. Owen > On Nov 17, 2021, at 19:33 , Dave Taht wrote: > > I am sad to see the most controversial of the proposals (127/16) first > disc

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-19 Thread Owen DeLong via NANOG
> On Nov 17, 2021, at 19:03 , John Levine wrote: > > It appears that Joe Maimon said: >> Mark Andrews wrote: >>> It’s a denial of service attack on the IETF process to keep bringing up >>> drafts like this that are never going to be approved. 127/8 is >> in use. It isn’t free. >> >> There

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-18 Thread Jim
On Thu, Nov 18, 2021 at 11:05 AM John R. Levine wrote: ..> The IETF is not the Network Police, and all IETF standards are entirely > voluntary. Yes, however the IETF standards can be an obstacle -- if they are, then it is reasonable to adjust that which might impede a future useful development: r

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-18 Thread Justin Streiner
The proposals I've seen all seem to deliver minimal benefit for the massive lift (technical, administrative, political, etc) involved to keep IPv4 alive a little longer. Makes about as much sense as trying to destabilize US currency by counterfeiting pennies. Thank you jms On Thu, Nov 18, 2021

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-18 Thread David Conrad
On Nov 18, 2021, at 9:00 AM, John R. Levine wrote: >> The only effort involved on the IETF's jurisdiction was to stop squatting on >> 240/4 and perhaps maybe some other small pieces of IPv4 that could possibly >> be better used elsewhere by others who may choose to do so. > > The IETF is not th

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-18 Thread Joe Maimon
John R. Levine wrote: The only effort involved on the IETF's jurisdiction was to stop squatting on 240/4 and perhaps maybe some other small pieces of IPv4 that could possibly be better used elsewhere by others who may choose to do so. The IETF is not the Network Police, and all IETF standa

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-18 Thread John R. Levine
The only effort involved on the IETF's jurisdiction was to stop squatting on 240/4 and perhaps maybe some other small pieces of IPv4 that could possibly be better used elsewhere by others who may choose to do so. The IETF is not the Network Police, and all IETF standards are entirely voluntary

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-18 Thread Joe Maimon
Dave Taht wrote: I am sad to see the most controversial of the proposals (127/16) > first discussed here. > > Try this instead? > > https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/ > > > in my mind, has the most promise for making the internet better in the near

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-18 Thread Joe Maimon
Mark Andrews wrote: CIDR is much older than that and we still have to avoid .0 and .255 addresses in class C space. I use .0 all the time. Similarly for .0.0 and .255.255 for class B space and .0.0.0 and .255.255.255 for class A space. Getting everybody you want to contact and the path i

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-18 Thread Dave Taht
I am sad to see the most controversial of the proposals (127/16) first discussed here. Try this instead? https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/ in my mind, has the most promise for making the internet better in the nearer term. Could I get y'all to put asi

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-18 Thread Steven Bakker
On Thu, 2021-11-18 at 10:51 +, Nick Hilliard wrote: > The ask is to update every ip stack in the world (including > validation,  > equipment retirement, reconfiguration, etc) and the gain is 4 weeks > of > extra ip address space in terms of estimated consumption. (Not to mention the static 12

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-18 Thread Nick Hilliard
John Levine wrote on 18/11/2021 03:03: The amount of work to change every computer in the world running TCP/IP and every IP application to treat 240/4 as unicast (or to treat some of 127/8) is not significantly less than the work to get them to support IPv6. So it would roughly double the work, f

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-17 Thread Mark Andrews
> On 18 Nov 2021, at 17:21, Joe Maimon wrote: > > > > John Levine wrote: >> It appears that Joe Maimon said: >> >>> For example >>> https://datatracker.ietf.org/doc/html/draft-fuller-240space-02 from 2008 >>> which fell prey to the "by the time this is usable IPv6 will have taken >>> over"

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-17 Thread Joe Maimon
John Levine wrote: It appears that Joe Maimon said: For example https://datatracker.ietf.org/doc/html/draft-fuller-240space-02 from 2008 which fell prey to the "by the time this is usable IPv6 will have taken over" groupthink. Objectively wrong. I will agree that your explanation of the r

Re: WKBI #586, Redploying most of 127/8 as unicast public

2021-11-17 Thread John Levine
It appears that Joe Maimon said: >Mark Andrews wrote: >> It’s a denial of service attack on the IETF process to keep bringing up >> drafts like this that are never going to be approved. 127/8 is >in use. It isn’t free. > >There are so many things wrong with this statement that I am not even >g