This seems like a really bad idea to me; am I really the only one who noticed?
https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
That's over a week old and I don't see 3000 comments on it, so maybe it's just
me. So many things are just me.
[ Hat tip to Lauren Weinstein, whom I stole it from ]
Cheers,
-- jra
Hi Jay,
I think it's a good idea. It won't be usable any time in the next two
decades but if we're still using IPv4 in two decades we'll be glad to
have anything we can scrounge. Why not ask OS authors to start
assigning 127.0.0.1/16 to loopback instead of 127.0.0.1/8?
Regards,
Bill Herrin
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.
Lots of bad attempts to justify a bad idea.
"The IPv4 network 127/8 was first reserved by Jon Postel in 1981 [RFC0776]. Postel's policy was to reserve the first and last network of each class, and it does not appear that he had a specific plan for how to use 127/8.”
Having a space for permission-less innovation and testing is a good thing. Jon understood that.
"By contrast, IPv6, despite its vastly larger pool of available address space, allocates only a single local loopback address (::1) [RFC4291]. This appears to be an architectural vote of confidence in the idea that Internet protocols ultimately do not require millions of distinct loopback addresses.”
This is an apples-to-oranges comparison. IPv6 has both link and site local addresses and an architecture to deliver packets to specific instances of each. This does not exist in the IPv4 world.
"In theory, having multiple local loopback addresses might be useful for increasing the number of distinct IPv4 sockets that can be used for inter-process communication within a host. The local loopback /16 network retained by this document will still permit billions of distinct concurrent loopback TCP connections within a single host, even if both the IP address and port number of one endpoint of each connection are fixed.”
But it doesn’t deliver millions of end points. Sorry you simulation will not work because we don’t have more that 65000 end points anymore. Sorry RFC 1918 addresses are not always suitable.
"Reserved for <use>" is not the same as “Reserved”.
Mark
I didn't comment because I was laughing too hard to be able to reliably use
the keyboard.
- Matt
Someone is wrong on the Internet.
Other problems which will occur sooner:
1. Unix 32-bit time_t overflow.
2. North American Numbering Plan runs out of +1 zone phone numbers
3. IPv6 deployed and working everywhere/everything on the Internet
4. Analog AM and FM radio broadcasting deprecated (see digital DAB/DRM/HD)
5. Heat death of the universe
Again, covered by XKCD
I've got other things to do first.
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 going to try to enumerate them.
However suffice it to say that drafts like these are concrete documentation of non-groupthink and essentially you are advocating for self-censorship and loss of historical perspective.
Which given the state of IPv6 transition, perhaps more of that in the past would have been nice.
For example 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.
Predictive self-fulfilling circular arguments of this sort should no longer be given any weight, and along your lines, should never even be brought up.
Lots of bad attempts to justify a bad idea.
"The IPv4 network 127/8 was first reserved by Jon Postel in 1981 [RFC0776]. Postel's policy was to reserve the first and last network of each class, and it does not appear that he had a specific plan for how to use 127/8.”
Having a space for permission-less innovation and testing is a good thing. Jon understood that.
Yes its a good idea to have space that is guaranteed to be available to every system regardless of its networking condition and that the host has deterministic control over the addressing used in that space.
However, it turns out that /8 was much too large. The extreme few instances of its usefulness at that size pale in comparison with even the possibility of its usefulness to the public.
So any attempt to adjust that should be given proper attention and serious thought.
"By contrast, IPv6, despite its vastly larger pool of available address space, allocates only a single local loopback address (::1) [RFC4291]. This appears to be an architectural vote of confidence in the idea that Internet protocols ultimately do not require millions of distinct loopback addresses.”
This is an apples-to-oranges comparison. IPv6 has both link and site local addresses and an architecture to deliver packets to specific instances of each. This does not exist in the IPv4 world.
SO an IPv6 only system without any network interfaces can run multiple discrete instances of the same daemon accepting connections on the same TCP port? Can I script that, can I template that with hardcoded addresses, same as I can now for 127/8?
Good thing I can just use ::FFFF:127.0.0.1/104
"In theory, having multiple local loopback addresses might be useful for increasing the number of distinct IPv4 sockets that can be used for inter-process communication within a host. The local loopback /16 network retained by this document will still permit billions of distinct concurrent loopback TCP connections within a single host, even if both the IP address and port number of one endpoint of each connection are fixed.”
But it doesn’t deliver millions of end points. Sorry you simulation will not work because we don’t have more that 65000 end points anymore. Sorry RFC 1918 addresses are not always suitable.
"Reserved for <use>" is not the same as “Reserved”.
Mark
Let them use IPv6 link local for their simulations.
This seems like a really bad idea to me; am I really the only one who noticed?
Its only a relevant idea if you still care about IPv4. In which case, it might be a good idea.
Joe
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 going to try to enumerate them.
However suffice it to say that drafts like these are concrete documentation of non-groupthink and essentially you are advocating for self-censorship and loss of historical perspective.
I’m advocating for not taking address away that have been allocated for a purpose. No one knows what the impact of doing that will be. Perhaps we should just take back 216.222.144.0/20? You obviously think taking back address that are in use to be a good thing. This is similar to taking back other address that are allocated but not advertised.
Which given the state of IPv6 transition, perhaps more of that in the past would have been nice.
For example draft-fuller-240space-02 from 2008 which fell prey to the "by the time this is usable IPv6 will have taken over" groupthink.
Again an oranges vs apples comparison. Class E is not 127/8. This is “Reserved" vs "Reserved for use on the host”. Totally different histories. Totally different expectations.
Objectively wrong.
Predictive self-fulfilling circular arguments of this sort should no longer be given any weight, and along your lines, should never even be brought up.
Lots of bad attempts to justify a bad idea.
"The IPv4 network 127/8 was first reserved by Jon Postel in 1981 [RFC0776]. Postel's policy was to reserve the first and last network of each class, and it does not appear that he had a specific plan for how to use 127/8.”
Having a space for permission-less innovation and testing is a good thing. Jon understood that.
Yes its a good idea to have space that is guaranteed to be available to every system regardless of its networking condition and that the host has deterministic control over the addressing used in that space.
However, it turns out that /8 was much too large. The extreme few instances of its usefulness at that size pale in comparison with even the possibility of its usefulness to the public.
So any attempt to adjust that should be given proper attention and serious thought.
"By contrast, IPv6, despite its vastly larger pool of available address space, allocates only a single local loopback address (::1) [RFC4291]. This appears to be an architectural vote of confidence in the idea that Internet protocols ultimately do not require millions of distinct loopback addresses.”
This is an apples-to-oranges comparison. IPv6 has both link and site local addresses and an architecture to deliver packets to specific instances of each. This does not exist in the IPv4 world.
SO an IPv6 only system without any network interfaces can run multiple discrete instances of the same daemon accepting connections on the same TCP port?
Yes. I’ve been doing testing over the IPv6 loopback for 20+ years now.
Can I script that, can I template that with hardcoded addresses, same as I can now for 127/8?
Good thing I can just use ::FFFF:127.0.0.1/104
You can script is to the same extent that you can hard code 127/8 addresses. I’ve used ULA addresses but conceptually they are the same. The lo0 interface also has more that 127.0.0.1 IPv4 addresses on it.
% ifconfig lo0 inet6
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet6 fd92:7065:b8e:ffff::1 prefixlen 64
inet6 fd92:7065:b8e:ffff::2 prefixlen 64
inet6 fd92:7065:b8e:ffff::3 prefixlen 64
inet6 fd92:7065:b8e:ffff::4 prefixlen 64
inet6 fd92:7065:b8e:ffff::5 prefixlen 64
inet6 fd92:7065:b8e:ffff::6 prefixlen 64
inet6 fd92:7065:b8e:ffff::7 prefixlen 64
inet6 fd92:7065:b8e:ffff::8 prefixlen 64
inet6 fd92:7065:b8e:ffff::9 prefixlen 64
inet6 fd92:7065:b8e:ffff::10 prefixlen 64
inet6 fd92:7065:b8e:ff::1 prefixlen 64
inet6 fd92:7065:b8e:ff::2 prefixlen 64
inet6 fd92:7065:b8e:99ff::1 prefixlen 64
inet6 fd92:7065:b8e:99ff::2 prefixlen 64
inet6 fd92:7065:b8e:fffe::a35:4 prefixlen 64
nd6 options=201<PERFORMNUD,DAD>
%
"In theory, having multiple local loopback addresses might be useful for increasing the number of distinct IPv4 sockets that can be used for inter-process communication within a host. The local loopback /16 network retained by this document will still permit billions of distinct concurrent loopback TCP connections within a single host, even if both the IP address and port number of one endpoint of each connection are fixed.”
But it doesn’t deliver millions of end points. Sorry you simulation will not work because we don’t have more that 65000 end points anymore. Sorry RFC 1918 addresses are not always suitable.
"Reserved for <use>" is not the same as “Reserved”.
Mark
Let them use IPv6 link local for their simulations.
Which doesn’t work when you are simulating dual stack.
It appears that Joe Maimon <jmaimon@jmaimon.com> 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
going to try to enumerate them.
Aw, c'mon, don't leave us guessing.
For example
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 reasons the IETF didn't repurpose 240/8 is objectively wrong.
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, for a 2% increase
in the address space, or for 127/8 less than 1%. The code for IPv6
is already written, after all.
Also, while the world has run out of free IPv4 address space, there is
plenty of IPv4 if you are willing to pay for it. A 2% increase in v4
addresses would not change that.
"By contrast, IPv6, despite its vastly larger pool of available address space, allocates only a single local loopback address (::1)
[RFC4291]. This appears to be an architectural vote of confidence in the idea that Internet protocols ultimately do not require millions of
distinct loopback addresses.”This is an apples-to-oranges comparison. IPv6 has both link and site local addresses and an architecture to deliver packets to specific
instances of each. This does not exist in the IPv4 world.
SO an IPv6 only system without any network interfaces can run multiple
discrete instances of the same daemon accepting connections on the same
TCP port?
Sure.
Can I script that, can I template that with hardcoded
addresses, same as I can now for 127/8?
Sure, if you think that's a good idea which it isn't. Use LLAs on your loopback interface.
Personally, I take my 127/8 addresses from a configuration file since I don't know in advance what
other daemons might also want to run on addresses only visible on the local machine. Or, you know,
some maniac might decide that part of 127/8 isn't loopback so I have to move them to the part that
still is.
In IPv6 I use ULAs since that gives me the option of routing them or not.
R's,
John
Subject: Redploying most of 127/8 as unicast public
To: nanog nanog@nanog.org;
This seems like a really bad idea to me; am I really the only one who noticed?https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
I can think of about a dozen /8’s that would be better to use. (Hint, they all have DOD in the name.) They haven’t been in routing tables for decades and there wouldn’t be hardly any technical issues (like there would be with 127/8). The only drawback is I’ve seen a lot of organizations treat them like rfc1918 space.
There is a better chance of writing a successful RFC to clean up "cisco, cisco" for user/pass on Google.
Mark.
Mark Andrews wrote:
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 going to try to enumerate them.
However suffice it to say that drafts like these are concrete documentation of non-groupthink and essentially you are advocating for self-censorship and loss of historical perspective.
I’m advocating for not taking address away that have been allocated for a purpose. No one knows what the impact of doing that will be. Perhaps we should just take back 216.222.144.0/20? You obviously think taking back address that are in use to be a good thing. This is similar to taking back other address that are allocated but not advertised.
I am advocating for serious discussion on the merits, and only the merits, of each individual idea and proposal and to respect those willing to put in the effort even while likely knowing of the undeserved scorn bound to come their way from those who choose not do as I would advocate them doing.
And I think the basic contention is that the vast majority of 127/8 is not in use. Apples to oranges, indeed.
You can script is to the same extent that you can hard code 127/8 addresses. I’ve used ULA addresses but conceptually they are the same. The lo0 interface also has more that 127.0.0.1 IPv4 addresses on it.
% ifconfig lo0 inet6
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet6 ::1 prefixlen 128 .
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet6 fd92:7065:b8e:ffff::1 prefixlen 64
Thats twice now you have suggested that ULA and LLA are an exact substitute for dedicated system loopback prefix.
At the very least, it is semantically not.
Doesnt IPv6 deserve its own instead of squatting on IPv4?
Joe
John Levine wrote:
It appears that Joe Maimon <jmaimon@jmaimon.com> said:
For example
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 reasons the IETF didn't repurpose 240/8 is objectively wrong.
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, for a 2% increase
in the address space, or for 127/8 less than 1%. The code for IPv6
is already written, after all.
And since 2008, IPv6 related updates and patches were so few and far between that they could not compare with those that would have been required if the IETF had ordered the internet to enable 240/4.
All 240/4 needed was a decade of normal product lifecycle patching. Basically an afterthought. A not insignificant percentage of which has happened practically all by itself to date.
And you seriously suggest that "effort" FSVO is equivalent to IPv6, which deployment wise is pretty much in the same state as 240/4, even with the IETF's full backing?
Which statistic are you torturing to somehow equate the two software and deployment projects? Its like comparing an ant to an elephant.
And given the current sorry state of IPv6 deployment, forgive me for thinking that perhaps they got the numbers a teeny weeny bit wrong.
Also, while the world has run out of free IPv4 address space, there is
plenty of IPv4 if you are willing to pay for it. A 2% increase in v4
addresses would not change that.
In the decade it would have taken for 240/4 to become globally usable, the rate of consumption, allocation and utilization of IPv4 has changed to the point that yes, it would have made a big difference. In another decade, should IPv6 not have finally managed to obsolete IPv4, the appreciation of utilitarian value can only to be greater.
Its like a whole nother do-over of the final /8 give out, except twice.
Think of it in terms of /24s because thats really all any small outfit ever needs of IPv4 and its critical for any startup. 65k is nothing to sneeze at looking at it that way.
"By contrast, IPv6, despite its vastly larger pool of available address space, allocates only a single local loopback address (::1)
[RFC4291]. This appears to be an architectural vote of confidence in the idea that Internet protocols ultimately do not require millions of
distinct loopback addresses.”
IPv6 evangelicals are fond of citing the in-exhaustiveness of IPv6 in support of most any not particularly prudent allocation methodology or use of astonishingly large (in comparison to IPv4) amounts of it, but ::1 is all that can be mustered up for loopback.
On the other hand, we must take great pause and care of doing anything to disturb the 1/256th of the entire address pool allocated for that purpose to IPv4.
In-congruent, to say the least.
Anyways, IPv6 is supposed to save us from the degrading IPv4 network, whats one more degradation in the form of 127/8 -> 127.0/16 ?
This is an apples-to-oranges comparison. IPv6 has both link and site local addresses and an architecture to deliver packets to specific
instances of each. This does not exist in the IPv4 world.
SO an IPv6 only system without any network interfaces can run multiple
discrete instances of the same daemon accepting connections on the same
TCP port?Sure.
Can I script that, can I template that with hardcoded
addresses, same as I can now for 127/8?
Sure, if you think that's a good idea which it isn't. Use LLAs on your loopback interface.
Which LLA's does an IPv6 stack without any IPv6 enabled interfaces have?
Or worse, which LLA's will the IPv6 stack have with an IPv6 enabled interface? Depends on the hardware address?
LLA's are not a loopback range. So using them for that purpose is less than ideal, and unworthy of this new protocol thats supposed to take all the good of IPv4, discard the bad, innovate the new, usher in a renewal for the internet, and fail at all of that.
Personally, I take my 127/8 addresses from a configuration file since I don't know in advance what
other daemons might also want to run on addresses only visible on the local machine.
How you deal with loopbacks on your system, is by definition, local to your system.
All other mechanisms are not. Maybe by convention, but not definition.
Dont we appreciate standards for that very reason?
Or, you know,
some maniac might decide that part of 127/8 isn't loopback so I have to move them to the part that
still is.In IPv6 I use ULAs since that gives me the option of routing them or not.
R's,
John
ULA and registered ULA are one of those things thats hard to think about with a straight face. They betray a variety of dichotomies that are quite ridiculous.
Joe
John Levine wrote:
It appears that Joe Maimon <jmaimon@jmaimon.com> said:
For example
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 reasons the IETF didn't repurpose 240/8 is objectively wrong.
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, for a 2% increase
in the address space, or for 127/8 less than 1%. The code for IPv6
is already written, after all.And since 2008, IPv6 related updates and patches were so few and far between that they could not compare with those that would have been required if the IETF had ordered the internet to enable 240/4.
All 240/4 needed was a decade of normal product lifecycle patching. Basically an afterthought. A not insignificant percentage of which has happened practically all by itself to date.
CIDR is much older than that and we still have to avoid .0 and .255 addresses in class C space. 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 in between to be clean for 240/4 is more than just a replacement cycle. There is a lot of really old gear out there that still talks to the world and it will never work with 240/4 addresses.
If you are selling IPv4 connectivity and your customer is given a 240/4 address but can’t reach some place on the internet that their neighbour with out a 240/4 can who are they going to blame? Can you afford the defective product law suite. You gave then an address that you knew fore well would not work reliably with the Internet as a whole.
Using 1/8 is still fraught. At least with 1/8 you are not fighting kernels that need to be modified for which source is not available.
No, you are not alone. This just gets kinda pathetic.
It also shows how an IPv6 is a failure.
(No please, leave me alone all you IPv6 zealots).
I think its time to go back to design board and start
working on IPv8 
so we finnaly get rid of IPv4...
It’s being discussed on Hacker News.
Right up there with the FUSSP.
https://www.rhyolite.com/anti-spam/you-might-be.html
Someone should write a page like that about the FUSIAS (final ultimate solution to the IPv4 address shortage) proposals.
Grüße, Carsten
putting more numbers on the table, the pre-exhaustion burn rate of unallocated ipv4 address space was around 13 x /8 a year, i.e. a /8 every four weeks.
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.
Nick
Jay R. Ashworth wrote:
This seems like a really bad idea to me; am I really the only one who noticed?
https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
That's definitely a stupid idea.
As it requires to update all the end systems not to recognize 127/8
as loopback, releasing Class E, which is 16 times larger than 127/8,
as an additional public unicast address range is a lot (16 times)
better.
Though intermediate systems such as backbone routers must be updated
to release Class E, that is a lot lot lot less painful to replace the
end systems.
Masataka Ohta
Perhaps it was just submitted 144 days too earlier and thus was miscategorized?
/John
Disclaimer(s): my views alone. Contains 100% recycled electrons.
This is actually worse than our collective progress on replacing v4 to date.
-jim