Re: Redploying most of 127/8 as unicast public
On 18 Nov 2021, at 11:58, Joe Maimon <jmaimon@chl.com> 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.
Which given the state of IPv6 transition, perhaps more of that in the past would have been nice.
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.
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.
On 18 Nov 2021, at 10:45, scott <surfer@mauigateway.com> wrote:
On 11/17/2021 1:29 PM, Jay R. Ashworth wrote:
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, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
On 18 Nov 2021, at 11:58, Joe Maimon <jmaimon@chl.com> 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
On Nov 17, 2021, at 21:33 , Joe Maimon <jmaimon@jmaimon.com> wrote:
Mark Andrews wrote:
On 18 Nov 2021, at 11:58, Joe Maimon <jmaimon@chl.com> 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.
This contention is provably false for some definitions of “in use”.
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.
In what way would the LLA or ULA above be meaningfully different from 127/8 as deployed?
At the very least, it is semantically not.
How so?
Doesnt IPv6 deserve its own instead of squatting on IPv4?
I don’t see any “squatting on IPv4” here. Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread, having a prefix dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best tradeoff. Owen
On Fri, Nov 19, 2021 at 7:00 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread, having a prefix dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best tradeoff.
I would prefer to discuss the other drafts. However, - and this is not in the 127 draft, and is an opinion not shared with the other authors - I have a specific use case for making 127 "more routable", in that there is nowadays a twisty maze of microservices, bottled up in a variety of kubernetes containers, running on top of vms, on top of a hypervisor, that are often hooked together via rfc1918 addressing and NAT. Trying to figure out that particular path, from within one of those containers, can be a PITA. The concept of 127 being local to a physical host (and routed internally, rather than natted), where those twisty maze of services ideally remains within that host, holds some appeal to me.
Owen
-- 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
On Nov 19, 2021, at 07:23 , Dave Taht <dave.taht@gmail.com> wrote:
On Fri, Nov 19, 2021 at 7:00 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread, having a prefix dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best tradeoff.
I would prefer to discuss the other drafts. However, - and this is not in the 127 draft, and is an opinion not shared with the other authors - I have a specific use case for making 127 "more routable", in that there is nowadays a twisty maze of microservices, bottled up in a variety of kubernetes containers, running on top of vms, on top of a hypervisor, that are often hooked together via rfc1918 addressing and NAT.
Trying to figure out that particular path, from within one of those containers, can be a PITA. The concept of 127 being local to a physical host (and routed internally, rather than natted), where those twisty maze of services ideally remains within that host, holds some appeal to me.
Couldn’t you do this with 169.254.0.0/16 (or IPv6 GUA or ULA) just as easily without the need to rewrite virtually every layer of the stack of miscellaneous software defined networking stuff you just listed? Owen
Owen DeLong wrote:
On Nov 17, 2021, at 21:33 , Joe Maimon <jmaimon@jmaimon.com> wrote:
And I think the basic contention is that the vast majority of 127/8 is not in use. Apples to oranges, indeed. This contention is provably false for some definitions of “in use”.
Determining the extent of this would be part of serious consideration.
In what way would the LLA or ULA above be meaningfully different from 127/8 as deployed?
Because 127/8 is the exact same number on every system and it is routed the same way on every system and every system can choose to use it how it and it alone wishes to. So this make it a deterministic prefix solely in control of the local system without any external context to ever be taken into consideration, by convention and standard. LLA and ULA and whatever random prefix you may wish to use for loopback, whether in IPv6 or even IPv4 have none of these qualities.
Doesnt IPv6 deserve its own instead of squatting on IPv4? I don’t see any “squatting on IPv4” here.
It means that the only deterministic loopback prefix in IPv6 larger than a single address is the one IPv6 inherited from IPv4.
Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread,
This is not my point, it is the contention of the draft standard and it is something I would hope is taken into serious consideration and researched properly/ My point is that to the extent this is true, the value of the space for other purposes could very well warrant re-purposing.
having a prefix dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best tradeoff.
Owen
But this is how it is to be done in IPv6, so lets get some lack-of-feature parity going with IPv4. Joe
On Nov 19, 2021, at 07:39 , Joe Maimon <jmaimon@jmaimon.com> wrote:
Owen DeLong wrote:
On Nov 17, 2021, at 21:33 , Joe Maimon <jmaimon@jmaimon.com> wrote:
And I think the basic contention is that the vast majority of 127/8 is not in use. Apples to oranges, indeed. This contention is provably false for some definitions of “in use”.
Determining the extent of this would be part of serious consideration.
In what way would the LLA or ULA above be meaningfully different from 127/8 as deployed?
Because 127/8 is the exact same number on every system and it is routed the same way on every system and every system can choose to use it how it and it alone wishes to.
But the proposal seeks to change that nature of 127.0.0.0/8 to make it more like LLA/ULA, so…
So this make it a deterministic prefix solely in control of the local system without any external context to ever be taken into consideration, by convention and standard.
At the moment, that’s already true. AIUI, the proposal being discussed seeks to convert 127.0.0.0/8 outside of 127.0.0.1 (or at least outside of 127.0.0.0/16) into routable GUA.
LLA and ULA and whatever random prefix you may wish to use for loopback, whether in IPv6 or even IPv4 have none of these qualities.
And if we implement the proposal at hand, which as near as I can tell you are supporting, that changes.
Doesnt IPv6 deserve its own instead of squatting on IPv4? I don’t see any “squatting on IPv4” here.
It means that the only deterministic loopback prefix in IPv6 larger than a single address is the one IPv6 inherited from IPv4.
Well… Worst case, it could use ::ffff:7f00:0000::/96 Whether you consider that “squatting on IPv4” or not is left as an exercise to the reader. I do not, though I can understand and must admit that it is equally legitimate if someone else does.
Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread,
This is not my point, it is the contention of the draft standard and it is something I would hope is taken into serious consideration and researched properly/
My point is that to the extent this is true, the value of the space for other purposes could very well warrant re-purposing.
Having trouble following your desired outcome here. It seems as if you both want 127.0.0.0/8 to retain it’s unique properties as deterministically loopback only and also want the benefits of repurposing it as GUA. Have cake, Eat cake, please to pick only one.
having a prefix dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best tradeoff.
Owen
But this is how it is to be done in IPv6, so lets get some lack-of-feature parity going with IPv4.
I’m all for IPv6 having better implementations than IPv4 rather than mere feature parity. IMHO, having additional loopbacks be assigned from either LLA or ULA space (or even GUA, really) where that is needed is a superior choice vs. 127.0.0.0/8. For one thing, the alternative addressing schemes (other than LLA) allow for routing of the addresses off the box even though they are configured on loopback interfaces. There are a number of situations where this can be a useful way to ensure that the addresses remain usable regardless of the up/down state of connectivity on any particular non-loopback interface on the box. It’s one of the reasons, for example, that virtually every IBGP speaking router has a GUA or ULA/1918 loopback address which is routed in the IGP and almost all IBGP sessions are terminated on those loopback interfaces. Owen
On Fri, Nov 19, 2021 at 8:35 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
I’m all for IPv6 having better implementations than IPv4 rather than mere feature parity.
Me too, just not in a dystopian Harrison Bergeron sort of way. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Owen DeLong wrote:
LLA and ULA and whatever random prefix you may wish to use for loopback, whether in IPv6 or even IPv4 have none of these qualities. And if we implement the proposal at hand, which as near as I can tell you are supporting, that changes.
Having trouble following your desired outcome here. It seems as if you both want 127.0.0.0/8 to retain it’s unique properties as deterministically loopback only and also want the benefits of repurposing it as GUA.
Have cake, Eat cake, please to pick only one.
Let me clear that up then. I support serious consideration of the idea. My desired outcome is to see ideas like these either adopted or not but based solely on their own merits and especially in their own protocol context. And that folk who have studied the issue and invested their efforts be taken seriously and not be met with undeserved and might I add, unkind, scorn. (I havent studied the issue or invested the effort, so you may continue to direct your scorn this way) Its well past time to stop behaving as if we are a bunch of teenagers on a private BBS. I like the loopback prefix feature of IPv4. I can easily concede that its too large, especially in this day and age. And that there is a good chance that significant benefit can come from addressing that before IPv4 becomes obsolete. I question the lack of dedicated loopback feature in IPv6 and I acknowledge that yes, you can accomplish the same with non loopback prefixes by essentially assigning them to loopback, but point out that that does not make them the same thing. I can understand that sometimes you may explicitly not want to use the loopback prefix for loopback applications. In fact many times. However, you dont really have much options when it comes to IPv6. And I discuss IPv6 loopback simply because of the pushback directed in a non-meritorious fashion from folk who apparently believe simultaneously that IPv6 is superior in every way to IPv4 and that any improvements|changes to IPv4 somehow endanger IPv6 imminent dominance.
having a prefix dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best tradeoff.
Owen
But this is how it is to be done in IPv6, so lets get some lack-of-feature parity going with IPv4. I’m all for IPv6 having better implementations than IPv4 rather than mere feature parity.
Actually I am (somewhat facetiously) suggesting that IPv4 have non-feature parity with IPv6 by taking away its loopback prefix.
IMHO, having additional loopbacks be assigned from either LLA or ULA space (or even GUA, really) where that is needed is a superior choice vs. 127.0.0.0/8.
Anyone who wants to assign routable IPv4 to loopback is free to do so and there are plenty of IPv4 ranges to choose from. The converse is not true in IPv6.
For one thing, the alternative addressing schemes (other than LLA) allow for routing of the addresses off the box even though they are configured on loopback interfaces. There are a number of situations where this can be a useful way to ensure that the addresses remain usable regardless of the up/down state of connectivity on any particular non-loopback interface on the box.
It’s one of the reasons, for example, that virtually every IBGP speaking router has a GUA or ULA/1918 loopback address which is routed in the IGP and almost all IBGP sessions are terminated on those loopback interfaces.
Owen
And its the fairly common way of implementing anycast services. But that is not what we are addressing on this thread. I actually think that IPv6 evangelicals should welcome any all ideas like this, especially if they believe it will further degrade the overall state of IPv4, because that should only serve as stronger impetus for IPv6 deployment. That mode of thought has been commonly expressed here and other places before. Best, Joe
On Nov 19, 2021, at 10:50 , Joe Maimon <jmaimon@jmaimon.com> wrote:
Owen DeLong wrote:
LLA and ULA and whatever random prefix you may wish to use for loopback, whether in IPv6 or even IPv4 have none of these qualities. And if we implement the proposal at hand, which as near as I can tell you are supporting, that changes.
Having trouble following your desired outcome here. It seems as if you both want 127.0.0.0/8 to retain it’s unique properties as deterministically loopback only and also want the benefits of repurposing it as GUA.
Have cake, Eat cake, please to pick only one.
Let me clear that up then.
I support serious consideration of the idea. My desired outcome is to see ideas like these either adopted or not but based solely on their own merits and especially in their own protocol context. And that folk who have studied the issue and invested their efforts be taken seriously and not be met with undeserved and might I add, unkind, scorn.
(I havent studied the issue or invested the effort, so you may continue to direct your scorn this way)
Its well past time to stop behaving as if we are a bunch of teenagers on a private BBS.
I like the loopback prefix feature of IPv4.
I can easily concede that its too large, especially in this day and age. And that there is a good chance that significant benefit can come from addressing that before IPv4 becomes obsolete.
I question the lack of dedicated loopback feature in IPv6 and I acknowledge that yes, you can accomplish the same with non loopback prefixes by essentially assigning them to loopback, but point out that that does not make them the same thing.
I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.
I can understand that sometimes you may explicitly not want to use the loopback prefix for loopback applications. In fact many times. However, you dont really have much options when it comes to IPv6
I have not encountered a device where I could not assign additional prefixes to a loopback interface in IPv6, so I’m having trouble understanding your meaning here.
And I discuss IPv6 loopback simply because of the pushback directed in a non-meritorious fashion from folk who apparently believe simultaneously that IPv6 is superior in every way to IPv4 and that any improvements|changes to IPv4 somehow endanger IPv6 imminent dominance.
I have little concern (if any) of the latter. I believe that IPv6 is mostly equivalent to IPv4 in virtually every way and vastly superior in exactly one way… It has enough addresses. (and in all the ways that result from that, i.e. potential to restore end to end addressing, elimination of NAPT, etc.). I think that IPv6 also offers some features not available in IPv4, the benefits of which we haven’t fully explored or realized (MIP6, DHCP-PD, improved zeroconf, RD, etc.). Certainly the IPSEC implementation in IPv6 is quite a bit cleaner than it’s back-ported counterpart on IPv4 which has become such a nightmare in most implementations that the vast majority of VPNs have migrated to some cockamamy HTTPS “SSL VPN” thing.
having a prefix dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best tradeoff.
Owen
But this is how it is to be done in IPv6, so lets get some lack-of-feature parity going with IPv4. I’m all for IPv6 having better implementations than IPv4 rather than mere feature parity.
Actually I am (somewhat facetiously) suggesting that IPv4 have non-feature parity with IPv6 by taking away its loopback prefix.
Both have a loopback prefix. IPv4: 127.0.0.0/8 and IPv6: ::1/128 Admittedly, there are a lot more addresses available in the IPv4 loopback prefix, but again, I view that as being mostly waste as a result of historical ignorance at the time a decision was being made.
IMHO, having additional loopbacks be assigned from either LLA or ULA space (or even GUA, really) where that is needed is a superior choice vs. 127.0.0.0/8.
Anyone who wants to assign routable IPv4 to loopback is free to do so and there are plenty of IPv4 ranges to choose from.
The converse is not true in IPv6.
I guess that depends on what you mean by “converse”. If you mean non-routable addresses deployed on the loopback interface, I think LL works fine for that purpose. If you mean routable addresses deployed on the loopback interface, I think ULA or GUA works fine for that purpose. If you mean something else, then I’m still not clear what you’re intent is here.
For one thing, the alternative addressing schemes (other than LLA) allow for routing of the addresses off the box even though they are configured on loopback interfaces. There are a number of situations where this can be a useful way to ensure that the addresses remain usable regardless of the up/down state of connectivity on any particular non-loopback interface on the box.
It’s one of the reasons, for example, that virtually every IBGP speaking router has a GUA or ULA/1918 loopback address which is routed in the IGP and almost all IBGP sessions are terminated on those loopback interfaces.
Owen
And its the fairly common way of implementing anycast services. But that is not what we are addressing on this thread.
I actually think that IPv6 evangelicals should welcome any all ideas like this, especially if they believe it will further degrade the overall state of IPv4, because that should only serve as stronger impetus for IPv6 deployment. That mode of thought has been commonly expressed here and other places before.
I don’t think the current proposals being discussed will improve or degrade IPv4. I think they will distract implementors that choose to implement them from useful work for a while and end in neither benefit nor detriment beyond the detriment that comes from wasting effort. If I thought it would significantly degrade IPv4, I might be all for it, but I doubt it would even be that useful. Owen
Owen DeLong wrote:
I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.
Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 parity would require the same, so merely designating a prefix would only be the beginning. There may not be a need. But there is clearly some benefit.
I can understand that sometimes you may explicitly not want to use the loopback prefix for loopback applications. In fact many times. However, you dont really have much options when it comes to IPv6 I have not encountered a device where I could not assign additional prefixes to a loopback interface in IPv6, so I’m having trouble understanding your meaning here.
In IPv6 if you want a loopback prefix you have to pick one yourself or determine which one the system has chosen on its own. Because there is no dedicated loopback prefix other than ::1/128
Anyone who wants to assign routable IPv4 to loopback is free to do so and there are plenty of IPv4 ranges to choose from.
The converse is not true in IPv6. I guess that depends on what you mean by “converse”.
I mean that in IPv6 you must assign an otherwise non-loopback prefix if you want one.
If you mean non-routable addresses deployed on the loopback interface, I think LL works fine for that purpose.
It works, but it is non deterministic and system dependent.
If you mean routable addresses deployed on the loopback interface, I think ULA or GUA works fine for that purpose.
And IPv4 has that too.
I actually think that IPv6 evangelicals should welcome any all ideas like this, especially if they believe it will further degrade the overall state of IPv4, because that should only serve as stronger impetus for IPv6 deployment. That mode of thought has been commonly expressed here and other places before. I don’t think the current proposals being discussed will improve or degrade IPv4. I think they will distract implementors that choose to implement them from useful work for a while and end in neither benefit nor detriment beyond the detriment that comes from wasting effort.
There seems to be some weird mental representation of how standards affect the real world. Standards do not demand or direct or control in any way what individuals do based upon their own assessment of their needs, available resources and resulting benefits. You are neither responsible or in control of how people choose to expend their implementing resources. Nor should you. What standards do is increase the potential benefits of conforming to certain behavior. So what you are really saying is that standardizing something that others may then choose to recognize as a worthwhile expenditure of their resources is something you would like to prevent on the assumption that those efforts would have otherwise gone into IPv6 advancement. You dont have the immediate moral high ground on that one. You dont have the long term moral high ground on that one because such thinking isnt new and we know its wishful at best. You dont have the logical high ground on that one because you are assuming facts not in evidence, namely that - Resources are being feverishly expended deploying IPv6 (as if) - Those same resources will be the ones redirected to implement ideas such as these - That those efforts are in anyways comparable in scope to work being done on IPv6 (which is supposed to be done already) - That any such diversion of activity will actually have any real world affect on the state of IPv6
If I thought it would significantly degrade IPv4, I might be all for it, but I doubt it would even be that useful.
Owen
Reclaiming 127/8 while assigning a /64 for loopback in IPv6 would create a clear (but narrow) case where IPv6 would be superior to IPv4, irrelevant of overall network state. Objectors to the proposal based upon their real world use of far larger than v4 /16 for loopback applications could implement on IPv6 with even more space, and in the exact same addressing context. Which GUA and LL are not, no matter how readily available and easily assignable and otherwise equivalent they are in every way but the one. They are not loopback designated by standard (and system implementation). Joe
On Nov 20, 2021, at 19:11 , Joe Maimon <jmaimon@jmaimon.com> wrote:
Owen DeLong wrote:
I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.
Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 parity would require the same, so merely designating a prefix would only be the beginning.
There may not be a need. But there is clearly some benefit.
Which is? You still haven’t answered that question.
I can understand that sometimes you may explicitly not want to use the loopback prefix for loopback applications. In fact many times. However, you dont really have much options when it comes to IPv6 I have not encountered a device where I could not assign additional prefixes to a loopback interface in IPv6, so I’m having trouble understanding your meaning here.
In IPv6 if you want a loopback prefix you have to pick one yourself or determine which one the system has chosen on its own. Because there is no dedicated loopback prefix other than ::1/128
Well, technically, fe80::/10 is also present and predictable on every loopback interface. It does come with the additional baggage of having to specify a scope id when referencing it, but that’s pretty minor.
Anyone who wants to assign routable IPv4 to loopback is free to do so and there are plenty of IPv4 ranges to choose from.
The converse is not true in IPv6. I guess that depends on what you mean by “converse”.
I mean that in IPv6 you must assign an otherwise non-loopback prefix if you want one.
Again, not really…fe80::/10 is right there waiting for you.
If you mean non-routable addresses deployed on the loopback interface, I think LL works fine for that purpose.
It works, but it is non deterministic and system dependent.
Nope… It’s every bit as deterministic as 127.0.0.0/8. If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you try it on something other than linux, it probably doesn’t work. That’s also true of 127.*.*.*.
If you mean routable addresses deployed on the loopback interface, I think ULA or GUA works fine for that purpose.
And IPv4 has that too.
Right, so we have parity or better in the case of IPv6. In IPv4, you have 16.7 Million addresses reserved for this purpose. In IPv6, it’s considerably more if you count all of fe80::/10. (somewhere north of 340,000,000,000,000,000,000,000,000,000,000,000 addresses IIRC) You can also get away with IPv6 loopback behavior on a dual stack system by using ::ffff:7fxx:xxxx as well.
I actually think that IPv6 evangelicals should welcome any all ideas like this, especially if they believe it will further degrade the overall state of IPv4, because that should only serve as stronger impetus for IPv6 deployment. That mode of thought has been commonly expressed here and other places before. I don’t think the current proposals being discussed will improve or degrade IPv4. I think they will distract implementors that choose to implement them from useful work for a while and end in neither benefit nor detriment beyond the detriment that comes from wasting effort.
There seems to be some weird mental representation of how standards affect the real world. Standards do not demand or direct or control in any way what individuals do based upon their own assessment of their needs, available resources and resulting benefits.
Maybe, maybe not. They certainly influence some of those choices in a variety of ways.
You are neither responsible or in control of how people choose to expend their implementing resources. Nor should you.
Agreed. But I have every right to express my desires and displeasures with widespread plans to encourage what I perceive as misuse and that’s exactly what’s happening here. My right to attempt to discourage it by opposing proposed standards is exactly equal to your right to encourage it by promoting them.
What standards do is increase the potential benefits of conforming to certain behavior.
No, what standards do is encourage people to implement things in compatible ways in hopes that doing so is beneficial. A proposed standard that doesn’t provide an apparent clear benefit, therefore doesn’t merit adoption.
So what you are really saying is that standardizing something that others may then choose to recognize as a worthwhile expenditure of their resources is something you would like to prevent on the assumption that those efforts would have otherwise gone into IPv6 advancement.
I’m really saying what I said. That IMHO, there’s no benefit to the internet overall if this proposed change is accepted and/or implemented and I see no benefit to standardizing it. As such, I remain opposed to doing so. Whether or not the effort that would be wasted implementing it would go to IPv6 or to some other more useful pursuit is not a concern I factor into my opinion in this case.
You dont have the immediate moral high ground on that one.
I’m really not concerned about where your misinterpretations of my statements land me in your opinion of the moral high ground, but thanks for playing.
You dont have the long term moral high ground on that one because such thinking isnt new and we know its wishful at best.
Same response.
You dont have the logical high ground on that one because you are assuming facts not in evidence, namely that
Same response.
- Resources are being feverishly expended deploying IPv6 (as if)
Some are. More certainly would be beneficial.
- Those same resources will be the ones redirected to implement ideas such as these
I have made no such assumption. I have made the assumption that since this is a complete waste of effort, whatever else those resources could be used for would likely be more useful. I believe there to be sufficient evidence to support that assumption, though I understand you don’t agree with the assertion it is based upon.
- That those efforts are in anyways comparable in scope to work being done on IPv6 (which is supposed to be done already)
I’ve made no such assumption, nor do I consider the relative scope to be in any way relevant.
- That any such diversion of activity will actually have any real world affect on the state of IPv6
Again, have not made any such assumption here, either. It’s not relevant. The only thing I consider relevant is that any resources expended on a complete waste of time could be better expended elsewhere.
If I thought it would significantly degrade IPv4, I might be all for it, but I doubt it would even be that useful.
Owen
Reclaiming 127/8 while assigning a /64 for loopback in IPv6 would create a clear (but narrow) case where IPv6 would be superior to IPv4, irrelevant of overall network state.
Why do you need another /64 when you already have a /10?
Objectors to the proposal based upon their real world use of far larger than v4 /16 for loopback applications could implement on IPv6 with even more space, and in the exact same addressing context.
They can already effectively do that today.
Which GUA and LL are not, no matter how readily available and easily assignable and otherwise equivalent they are in every way but the one. They are not loopback designated by standard (and system implementation).
And this matters why? Owen
Owen DeLong wrote:
On Nov 20, 2021, at 19:11 , Joe Maimon <jmaimon@jmaimon.com> wrote:
Owen DeLong wrote:
I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion. Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 parity would require the same, so merely designating a prefix would only be the beginning.
There may not be a need. But there is clearly some benefit. Which is? You still haven’t answered that question.
You have right below. And if there is indeed no benefit, than there is no reason not to repurpose 127/8 considering that you may use many other ranges in IPv4 for loopback and that you can just use IPv6 for loopback and there you go you have a whole /10. Its not like it will overnight cause system admin headaches. And they should be running their loopback apps on IPv6 anyways.
Well, technically, fe80::/10 is also present and predictable on every loopback interface. It does come with the additional baggage of having to specify a scope id when referencing it, but that’s pretty minor.
Nope… It’s every bit as deterministic as 127.0.0.0/8.
If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you try it on something other than linux, it probably doesn’t work. That’s also true of 127.*.*.*.
So fe80::/10 is the loopback prefix for IPv6 Joe
On Nov 20, 2021, at 20:37 , Joe Maimon <jmaimon@jmaimon.com> wrote:
Owen DeLong wrote:
On Nov 20, 2021, at 19:11 , Joe Maimon <jmaimon@jmaimon.com> wrote:
Owen DeLong wrote:
I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion. Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 parity would require the same, so merely designating a prefix would only be the beginning.
There may not be a need. But there is clearly some benefit. Which is? You still haven’t answered that question.
You have right below.
And if there is indeed no benefit, than there is no reason not to repurpose 127/8 considering that you may use many other ranges in IPv4 for loopback and that you can just use IPv6 for loopback and there you go you have a whole /10.
One doesn’t need a reason for inaction… One needs a reason to act. There is (so far) no compelling reason to repurpose 127/8 as far as I can see.
Its not like it will overnight cause system admin headaches. And they should be running their loopback apps on IPv6 anyways.
You are arguing that just because we can do a thing, we should do a thing. I am arguing that unless there’s a compelling reason to change the standard, we should leave it as is until it dies a natural death of old age. (or alternatively until we finally disconnect the life support keeping it artificially alive which is a more accurate metaphor for the current state of IPv4).
Well, technically, fe80::/10 is also present and predictable on every loopback interface. It does come with the additional baggage of having to specify a scope id when referencing it, but that’s pretty minor.
Nope… It’s every bit as deterministic as 127.0.0.0/8.
If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you try it on something other than linux, it probably doesn’t work. That’s also true of 127.*.*.*.
So fe80::/10 is the loopback prefix for IPv6
It’s link local. It’s present on loopback. fe80::/10%lo0 (on a linux box) is a loopback prefix for IPv6 which is universally deployed. The scope id becomes important in this context, but other than that, it’s identical to the semantics of IPv4. Owen
Owen DeLong wrote:
Agreed. But I have every right to express my desires and displeasures with widespread plans to encourage what I perceive as misuse and that’s exactly what’s happening here.
My right to attempt to discourage it by opposing proposed standards is exactly equal to your right to encourage it by promoting them.
Since your discouragement may take form in preventing some amount of improvement or amelioration to IPv4 users, there is a human cost associated to that. Absent the equivalent clear correlation of harm to whatever else you believe those resources are engaged in, I would not say those two behaviors are of equal consequence.
I’m really saying what I said. That IMHO, there’s no benefit to the internet overall if this proposed change is accepted and/or implemented and I see no benefit to standardizing it. As such, I remain opposed to doing so.
There is a clear difference of opinion on this, that there stands a very good chance that prompt implementation now may prove to provide significant benefit in the future, should IPv6 continue to lag, which you cannot guarantee it wont. Further, there is historical precedent that discouraging re-purposing IPv4 addressing is the wrong decision.
Whether or not the effort that would be wasted implementing it would go to IPv6 or to some other more useful pursuit is not a concern I factor into my opinion in this case.
And I appreciate that, as I consider that reasoning to be specious at best, morally dubious at worst.
Again, have not made any such assumption here, either. It’s not relevant. The only thing I consider relevant is that any resources expended on a complete waste of time could be better expended elsewhere.
I dont consider my opinion as to what people's effort should be spent on relevant to whether a particular proposal has merit all of its own.
Which GUA and LL are not, no matter how readily available and easily assignable and otherwise equivalent they are in every way but the one. They are not loopback designated by standard (and system implementation). And this matters why?
Owen
So re-purpose 127/8 and if users and developers agree with you, it will become available right about the time IPv6 should have finally managed to obsolete IPv4, no harm no foul. And if it fails at that again, at least we will have 127/8 and cohorts. Joe
On 21 Nov 2021, at 00.00, Joe Maimon <jmaimon@jmaimon.com> wrote:
There is a clear difference of opinion on this, that there stands a very good chance that prompt implementation now may prove to provide significant benefit in the future, should IPv6 continue to lag, which you cannot guarantee it wont.
The reassignment being implemented faster than IPv6 seems like a big assumption.
Max Harmony via NANOG wrote:
On 21 Nov 2021, at 00.00, Joe Maimon <jmaimon@jmaimon.com> wrote:
There is a clear difference of opinion on this, that there stands a very good chance that prompt implementation now may prove to provide significant benefit in the future, should IPv6 continue to lag, which you cannot guarantee it wont. The reassignment being implemented faster than IPv6 seems like a big assumption.
Suppose you are correct. This time. Even a broken clock can be right twice a day. The only loss for the most part in most of these related proposals is the time spent dickering on them and a few extra patches thrown in over the next decade. So just agree already. 127/8 is actually the proposal with the most potential for implementation issues as the definition change wends its way into system updates. And its easy to see that typical system updates tend to bring far greater disruption to system administrators on a regular basis. I would not rule out this change in that regard. And if you are wrong, as history suggests you may very well be? What is lost by not acting now is possibly far greater. Joe
On Nov 20, 2021, at 21:00 , Joe Maimon <jmaimon@jmaimon.com> wrote:
Owen DeLong wrote:
Agreed. But I have every right to express my desires and displeasures with widespread plans to encourage what I perceive as misuse and that’s exactly what’s happening here.
My right to attempt to discourage it by opposing proposed standards is exactly equal to your right to encourage it by promoting them.
Since your discouragement may take form in preventing some amount of improvement or amelioration to IPv4 users, there is a human cost associated to that.
Since wasted effort may prevent other things I see as advantageous to the network and humanity in general from happening, there is a human cost to not preventing it.
Absent the equivalent clear correlation of harm to whatever else you believe those resources are engaged in, I would not say those two behaviors are of equal consequence.
You are entitled to your opinion. I do not happen to share it.
I’m really saying what I said. That IMHO, there’s no benefit to the internet overall if this proposed change is accepted and/or implemented and I see no benefit to standardizing it. As such, I remain opposed to doing so.
There is a clear difference of opinion on this, that there stands a very good chance that prompt implementation now may prove to provide significant benefit in the future, should IPv6 continue to lag, which you cannot guarantee it wont.
There stands some chance. It’s not clear how good that chance is. Obviously you think it is a higher probability than I do. You also assume that it would be widely implemented faster than deployment of IPv6 which is also an assertion of which I remain unconvinced.
Further, there is historical precedent that discouraging re-purposing IPv4 addressing is the wrong decision.
Nope… There is historical precedent that you don’t like it. IMHO, we’ve done far too many things and put far too much effort into avoiding rather than completing IPv6 transition. As such, I think that the historical precedent argues that adding to those errors will not accelerate IPv6 transition and is, therefore, wasted effort at best and potentially counterproductive.
Whether or not the effort that would be wasted implementing it would go to IPv6 or to some other more useful pursuit is not a concern I factor into my opinion in this case.
And I appreciate that, as I consider that reasoning to be specious at best, morally dubious at worst.
At least we agree on something.
Again, have not made any such assumption here, either. It’s not relevant. The only thing I consider relevant is that any resources expended on a complete waste of time could be better expended elsewhere.
I dont consider my opinion as to what people's effort should be spent on relevant to whether a particular proposal has merit all of its own.
IMHO, the proposal has no merit and is therefore a waste of time. Clearly you disagree. That’s fine.
Which GUA and LL are not, no matter how readily available and easily assignable and otherwise equivalent they are in every way but the one. They are not loopback designated by standard (and system implementation). And this matters why?
Owen
So re-purpose 127/8 and if users and developers agree with you, it will become available right about the time IPv6 should have finally managed to obsolete IPv4, no harm no foul. And if it fails at that again, at least we will have 127/8 and cohorts.
Meh, feel free to do whatever you want. In terms of any IETF WG adoption call or consensus call, I’ll object as I consider it useless at best and harmful at worst. Nothing you have said provides any indication that there is sufficient merit to be worth the time I have wasted on this thread, let alone further effort. Owen
participants (6)
-
Dave Taht -
Joe Maimon -
Mark Andrews -
Max Harmony -
Owen DeLong -
William Herrin