So out of the current discussions a lot of people have claimed that ipv6 is bloated or suffers from second system syndrome, etc. So I decided to look at a linux kernel (HEAD I assume) and look at the differences between the v6 and v4 directories. I just crudely did a line count as a quick measure: ipv6: 68k lines ipv4: 97k lines ipv4 looks to have the tcp and udp implementations (35k) so backing that out it is about 62k lines. That's pretty comparable. Linux has full routing capability so the kernel implements it for both. So I'm just not getting where this "bloat" is. 10% growth for a second system syndrome seems almost miraculously good, imo. What am i missing? This is in complete agreement with my intuition 30 years ago that it was no big deal, at least from a software standpoint. Mike
It has "features" which are at a minimum problematic and at a maximum show stoppers for network operators. IPv6 seems like it was designed to be a private network communication stack, and how an ISP would use and distribute it was a second though. On 3/19/22 5:29 PM, Michael Thomas wrote:
So out of the current discussions a lot of people have claimed that ipv6 is bloated or suffers from second system syndrome, etc. So I decided to look at a linux kernel (HEAD I assume) and look at the differences between the v6 and v4 directories. I just crudely did a line count as a quick measure:
ipv6: 68k lines
ipv4: 97k lines
ipv4 looks to have the tcp and udp implementations (35k) so backing that out it is about 62k lines. That's pretty comparable. Linux has full routing capability so the kernel implements it for both.
So I'm just not getting where this "bloat" is. 10% growth for a second system syndrome seems almost miraculously good, imo.
What am i missing? This is in complete agreement with my intuition 30 years ago that it was no big deal, at least from a software standpoint.
Mike
On 3/19/22 3:47 PM, Matt Hoppes wrote:
It has "features" which are at a minimum problematic and at a maximum show stoppers for network operators.
IPv6 seems like it was designed to be a private network communication stack, and how an ISP would use and distribute it was a second though.
What might those be? And it doesn't seem to be a show stopper for a lot of very large carriers. Mike
On 3/19/22 5:29 PM, Michael Thomas wrote:
So out of the current discussions a lot of people have claimed that ipv6 is bloated or suffers from second system syndrome, etc. So I decided to look at a linux kernel (HEAD I assume) and look at the differences between the v6 and v4 directories. I just crudely did a line count as a quick measure:
ipv6: 68k lines
ipv4: 97k lines
ipv4 looks to have the tcp and udp implementations (35k) so backing that out it is about 62k lines. That's pretty comparable. Linux has full routing capability so the kernel implements it for both.
So I'm just not getting where this "bloat" is. 10% growth for a second system syndrome seems almost miraculously good, imo.
What am i missing? This is in complete agreement with my intuition 30 years ago that it was no big deal, at least from a software standpoint.
Mike
On 3/19/22 6:50 PM, Michael Thomas wrote:
On 3/19/22 3:47 PM, Matt Hoppes wrote:
It has "features" which are at a minimum problematic and at a maximum show stoppers for network operators.
IPv6 seems like it was designed to be a private network communication stack, and how an ISP would use and distribute it was a second though.
What might those be? And it doesn't seem to be a show stopper for a lot of very large carriers.
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID. We have to sniff the packets to figure out the MAC so that we can authenticate the client and/or assign an IP address to the client properly. It depends how you're managing the network. If you're running PPPoE you can encapsulate in that. But PPPoE is very 1990 and has its own set of problems. For those running encapsulated traffic, authentication to the modem MAC via DHCP that becomes broken. And thus far, I have not seen a solution offered to it. Secondly - and less importantly to deployment, IPv6 also provides a layer of problematic tracking for advertisers. Where as before many devices were behind a PAT, now every device has a unique ID -- probably for the life of the device. Marketers can now pinpoint down not just to an IP address that identifies a single NAT interface, but each individual device. This is problematic from a data collection standpoint.
On 3/19/22 3:56 PM, Matt Hoppes wrote:
On 3/19/22 6:50 PM, Michael Thomas wrote:
On 3/19/22 3:47 PM, Matt Hoppes wrote:
It has "features" which are at a minimum problematic and at a maximum show stoppers for network operators.
IPv6 seems like it was designed to be a private network communication stack, and how an ISP would use and distribute it was a second though.
What might those be? And it doesn't seem to be a show stopper for a lot of very large carriers.
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
We have to sniff the packets to figure out the MAC so that we can authenticate the client and/or assign an IP address to the client properly.
It depends how you're managing the network. If you're running PPPoE you can encapsulate in that. But PPPoE is very 1990 and has its own set of problems. For those running encapsulated traffic, authentication to the modem MAC via DHCP that becomes broken. And thus far, I have not seen a solution offered to it.
I was honestly more interested in the bloat angle, but this sounds like a backend problem of your own making most likely. But I'm not motivated to see if it's actually the case or just a misunderstanding.
Secondly - and less importantly to deployment, IPv6 also provides a layer of problematic tracking for advertisers. Where as before many devices were behind a PAT, now every device has a unique ID -- probably for the life of the device. Marketers can now pinpoint down not just to an IP address that identifies a single NAT interface, but each individual device. This is problematic from a data collection standpoint.
I guess you've not heard of privacy addresses. Or DHCPv6. Mike
I misspoke... it's not UUID... It's DUID. This isn't a backend management issue. This is a protocol issue. The MAC of the interface needs to be sent with a DHCP request so that it can be properly authenticated to the physical device. As long as the client and DHCPv6 server are on the same network interface -- it all works fine. However, when you relay that information, you now lose the MAC address information. Further, because the MAC is disconnected in IPv6 it becomes more difficult to make the connection between IPs on a dual-stack client. Everyone prints the MAC (a unique ID on devices and devices packaging). Almost nobody prints the DUID on a device, so how do you pre-populate your DHCP server? I can see that it encourages "one interface per network" and so encourages bonding, bridging or whatever, but is being able to differentiate the interfaces of a host really so bad? I can't help but feel that it would have been nice for DHCPv6 to send DUID and MAC. On 3/19/22 7:03 PM, Michael Thomas wrote:
On 3/19/22 3:56 PM, Matt Hoppes wrote:
On 3/19/22 6:50 PM, Michael Thomas wrote:
On 3/19/22 3:47 PM, Matt Hoppes wrote:
It has "features" which are at a minimum problematic and at a maximum show stoppers for network operators.
IPv6 seems like it was designed to be a private network communication stack, and how an ISP would use and distribute it was a second though.
What might those be? And it doesn't seem to be a show stopper for a lot of very large carriers.
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
We have to sniff the packets to figure out the MAC so that we can authenticate the client and/or assign an IP address to the client properly.
It depends how you're managing the network. If you're running PPPoE you can encapsulate in that. But PPPoE is very 1990 and has its own set of problems. For those running encapsulated traffic, authentication to the modem MAC via DHCP that becomes broken. And thus far, I have not seen a solution offered to it.
I was honestly more interested in the bloat angle, but this sounds like a backend problem of your own making most likely. But I'm not motivated to see if it's actually the case or just a misunderstanding.
Hi, On Sat, Mar 19, 2022 at 07:11:47PM -0400, Matt Hoppes wrote:
I misspoke... it's not UUID... It's DUID.
This isn't a backend management issue. This is a protocol issue. The MAC of the interface needs to be sent with a DHCP request so that it can be properly authenticated to the physical device.
As long as the client and DHCPv6 server are on the same network interface -- it all works fine. However, when you relay that information, you now lose the MAC address information.
RFC 6939 solves that, since a long time. See also: https://insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the...
Further, because the MAC is disconnected in IPv6 it becomes more difficult to make the connection between IPs on a dual-stack client.
Not sure if I agree with that either. That connection can be made by various other means, see https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv... cheers Enno
Everyone prints the MAC (a unique ID on devices and devices packaging). Almost nobody prints the DUID on a device, so how do you pre-populate your DHCP server? I can see that it encourages "one interface per network" and so encourages bonding, bridging or whatever, but is being able to differentiate the interfaces of a host really so bad? I can't help but feel that it would have been nice for DHCPv6 to send DUID and MAC.
On 3/19/22 7:03 PM, Michael Thomas wrote:
On 3/19/22 3:56 PM, Matt Hoppes wrote:
On 3/19/22 6:50 PM, Michael Thomas wrote:
On 3/19/22 3:47 PM, Matt Hoppes wrote:
It has "features" which are at a minimum problematic and at a maximum show stoppers for network operators.
IPv6 seems like it was designed to be a private network communication stack, and how an ISP would use and distribute it was a second though.
What might those be? And it doesn't seem to be a show stopper for a lot of very large carriers.
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
We have to sniff the packets to figure out the MAC so that we can authenticate the client and/or assign an IP address to the client properly.
It depends how you're managing the network.?? If you're running PPPoE you can encapsulate in that.???? But PPPoE is very 1990 and has its own set of problems.?? For those running encapsulated traffic, authentication to the modem MAC via DHCP that becomes broken.?? And thus far, I have not seen a solution offered to it.
I was honestly more interested in the bloat angle, but this sounds like a backend problem of your own making most likely. But I'm not motivated to see if it's actually the case or just a misunderstanding.
-- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
DHCPv6 Option 79 https://datatracker.ietf.org/doc/html/rfc6939
On Sat, Mar 19, 2022 at 6:58 PM Matt Hoppes < mattlists@rivervalleyinternet.net> wrote:
On 3/19/22 6:50 PM, Michael Thomas wrote:
On 3/19/22 3:47 PM, Matt Hoppes wrote:
It has "features" which are at a minimum problematic and at a maximum show stoppers for network operators.
IPv6 seems like it was designed to be a private network communication stack, and how an ISP would use and distribute it was a second though.
What might those be? And it doesn't seem to be a show stopper for a lot of very large carriers.
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
We have to sniff the packets to figure out the MAC so that we can authenticate the client and/or assign an IP address to the client properly.
It depends how you're managing the network. If you're running PPPoE you can encapsulate in that. But PPPoE is very 1990 and has its own set of problems. For those running encapsulated traffic, authentication to the modem MAC via DHCP that becomes broken. And thus far, I have not seen a solution offered to it.
Secondly - and less importantly to deployment, IPv6 also provides a layer of problematic tracking for advertisers. Where as before many devices were behind a PAT, now every device has a unique ID -- probably for the life of the device. Marketers can now pinpoint down not just to an IP address that identifies a single NAT interface, but each individual device. This is problematic from a data collection standpoint.
Thanks, I didn't think that they'd something that interfered with AAA. Using a MAC address as authentication seems sort of sketch to me in the first place. Mike On 3/19/22 4:14 PM, Tom Beecher wrote:
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
DHCPv6 Option 79
https://datatracker.ietf.org/doc/html/rfc6939
On Sat, Mar 19, 2022 at 6:58 PM Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:
On 3/19/22 6:50 PM, Michael Thomas wrote: > > On 3/19/22 3:47 PM, Matt Hoppes wrote: >> It has "features" which are at a minimum problematic and at a maximum >> show stoppers for network operators. >> >> IPv6 seems like it was designed to be a private network communication >> stack, and how an ISP would use and distribute it was a second though. > > What might those be? And it doesn't seem to be a show stopper for a lot > of very large carriers.
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
We have to sniff the packets to figure out the MAC so that we can authenticate the client and/or assign an IP address to the client properly.
It depends how you're managing the network. If you're running PPPoE you can encapsulate in that. But PPPoE is very 1990 and has its own set of problems. For those running encapsulated traffic, authentication to the modem MAC via DHCP that becomes broken. And thus far, I have not seen a solution offered to it.
Secondly - and less importantly to deployment, IPv6 also provides a layer of problematic tracking for advertisers. Where as before many devices were behind a PAT, now every device has a unique ID -- probably for the life of the device. Marketers can now pinpoint down not just to an IP address that identifies a single NAT interface, but each individual device. This is problematic from a data collection standpoint.
On a public network (such as WiFi - sure). On a private network where the only authentication taking place is to the modem which is provided by the service provider, not so much. It's a closed environment. The modem demarcs to the end-user and the end-user never touches the switching fabric. Interesting about DHCPv6 Option 79. I had not run across that before. I will look into that more. Thank you. On 3/19/22 7:18 PM, Michael Thomas wrote:
Thanks, I didn't think that they'd something that interfered with AAA. Using a MAC address as authentication seems sort of sketch to me in the first place.
Mike
On 3/19/22 4:14 PM, Tom Beecher wrote:
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
DHCPv6 Option 79
https://datatracker.ietf.org/doc/html/rfc6939
On Sat, Mar 19, 2022 at 6:58 PM Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:
On 3/19/22 6:50 PM, Michael Thomas wrote: > > On 3/19/22 3:47 PM, Matt Hoppes wrote: >> It has "features" which are at a minimum problematic and at a maximum >> show stoppers for network operators. >> >> IPv6 seems like it was designed to be a private network communication >> stack, and how an ISP would use and distribute it was a second though. > > What might those be? And it doesn't seem to be a show stopper for a lot > of very large carriers.
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
We have to sniff the packets to figure out the MAC so that we can authenticate the client and/or assign an IP address to the client properly.
It depends how you're managing the network. If you're running PPPoE you can encapsulate in that. But PPPoE is very 1990 and has its own set of problems. For those running encapsulated traffic, authentication to the modem MAC via DHCP that becomes broken. And thus far, I have not seen a solution offered to it.
Secondly - and less importantly to deployment, IPv6 also provides a layer of problematic tracking for advertisers. Where as before many devices were behind a PAT, now every device has a unique ID -- probably for the life of the device. Marketers can now pinpoint down not just to an IP address that identifies a single NAT interface, but each individual device. This is problematic from a data collection standpoint.
DHCPv6 includes the DEVICE Unique Identifier (DUID). DUID can be any one of several things. By far, the most common ones actually do include the MAC address. Some systems allow you to choose which type of DUID they supply. Macs use a long string that includes the EUI-64 at the end: (an expert from a static host entry in dhcpv6d.conf for a Mac host: host-identifier option dhcp6.client-id 00:01:00:01:23:d6:92:16:68:fe:f7:07:11:6f; hardware ethernet 68:fe:f7:07:11:6f; ) Some hosts don’t provide the MAC address, but they provide a device unique identifier which is equally useful for authentication, frankly. For example, a Raritan KVM: host-identifier option dhcp6.client-id 00:02:00:00:35:ae:31:49:54:39:41:30:30:31:34:38 ; HP Printers provide yet another format of DUID: host-identifier option dhcp6.client-id 00:01:00:01:01:e2:85:23:b8:db:ad:ba:db:ad ; It’s a little more awkward than DHCPv4, but once you get used to it, it’s really not so bad. It’s a slight challenge for providing hosts reserved addresses, but otherwise, it’s just larger fields in the log entries. Owen
On Mar 19, 2022, at 16:20 , Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:
On a public network (such as WiFi - sure). On a private network where the only authentication taking place is to the modem which is provided by the service provider, not so much. It's a closed environment. The modem demarcs to the end-user and the end-user never touches the switching fabric.
Interesting about DHCPv6 Option 79. I had not run across that before. I will look into that more. Thank you.
On 3/19/22 7:18 PM, Michael Thomas wrote:
Thanks, I didn't think that they'd something that interfered with AAA. Using a MAC address as authentication seems sort of sketch to me in the first place. Mike On 3/19/22 4:14 PM, Tom Beecher wrote:
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
DHCPv6 Option 79
https://datatracker.ietf.org/doc/html/rfc6939
On Sat, Mar 19, 2022 at 6:58 PM Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:
On 3/19/22 6:50 PM, Michael Thomas wrote:
On 3/19/22 3:47 PM, Matt Hoppes wrote:
It has "features" which are at a minimum problematic and at a
show stoppers for network operators.
IPv6 seems like it was designed to be a private network communication stack, and how an ISP would use and distribute it was a second
maximum though.
What might those be? And it doesn't seem to be a show stopper
for a lot
of very large carriers.
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
We have to sniff the packets to figure out the MAC so that we can authenticate the client and/or assign an IP address to the client properly.
It depends how you're managing the network. If you're running PPPoE you can encapsulate in that. But PPPoE is very 1990 and has its own set of problems. For those running encapsulated traffic, authentication to the modem MAC via DHCP that becomes broken. And thus far, I have not seen a solution offered to it.
Secondly - and less importantly to deployment, IPv6 also provides a layer of problematic tracking for advertisers. Where as before many devices were behind a PAT, now every device has a unique ID -- probably for the life of the device. Marketers can now pinpoint down not just to an IP address that identifies a single NAT interface, but each individual device. This is problematic from a data collection standpoint.
It seems sketchy to me to even retain client MAC information, no? Genuine question. Didn’t we go to a distinct unique identifier system for this very reason? Am I in the 1990s here or? We’re just handing out addresses to UEs and things seem to work fine. For me personally, I find the notation of v6 to be very unasthetic, so I tend to just conceal it from myself now. -LB Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME <https://alexmhoulton.wixsite.com/6x7networks> FCC License KJ6FJJ
On Mar 19, 2022, at 3:56 PM, Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:
On 3/19/22 6:50 PM, Michael Thomas wrote:
On 3/19/22 3:47 PM, Matt Hoppes wrote:
It has "features" which are at a minimum problematic and at a maximum show stoppers for network operators.
IPv6 seems like it was designed to be a private network communication stack, and how an ISP would use and distribute it was a second though. What might those be? And it doesn't seem to be a show stopper for a lot of very large carriers.
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
We have to sniff the packets to figure out the MAC so that we can authenticate the client and/or assign an IP address to the client properly.
It depends how you're managing the network. If you're running PPPoE you can encapsulate in that. But PPPoE is very 1990 and has its own set of problems. For those running encapsulated traffic, authentication to the modem MAC via DHCP that becomes broken. And thus far, I have not seen a solution offered to it.
Secondly - and less importantly to deployment, IPv6 also provides a layer of problematic tracking for advertisers. Where as before many devices were behind a PAT, now every device has a unique ID -- probably for the life of the device. Marketers can now pinpoint down not just to an IP address that identifies a single NAT interface, but each individual device. This is problematic from a data collection standpoint.
On Mar 20, 2022, at 07:17, Lady Benjamin Cannon of Glencoe <lb@6by7.net> wrote:
It seems sketchy to me to even retain client MAC information, no? Genuine question.
Didn’t we go to a distinct unique identifier system for this very reason?
Am I in the 1990s here or?
We’re just handing out addresses to UEs and things seem to work fine. For me personally, I find the notation of v6 to be very unasthetic, so I tend to just conceal it from myself now.
Correct me if I’m wrong, but it sounds like you’re viewing this from a service provider perspective, in which case everything you’ve said is basically correct. However, the enterprise world is very different. Right, wrong, or otherwise, many enterprises feel a strong compulsion to have very strict control over addressing and relatively direct accountability of “x address = y employee” (regardless of whether that’s actually true or not). In those environments, yes, IPv6 does present a learning curve and some additional challenges. They are not insurmountable and if you were starting from scratch needing to build your enterprise on IPv6, it would actually be less difficult than IPv4. IPv4, however, has the advantage of well trodden paths for enterprise solutions in this space. IPv6 will get there as more enterprises start to deploy IPv6, but right now both sides of that process suffer from the classic chicken/egg problem. The problem is slow to get solved because there are no chickens asking for a solution. Chickens aren’t asking for it because there are no eggs to create chickens that need IPv6. Owen
-LB
Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net <mailto:ben@6by7.net> "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME <https://alexmhoulton.wixsite.com/6x7networks>
FCC License KJ6FJJ
On Mar 19, 2022, at 3:56 PM, Matt Hoppes <mattlists@rivervalleyinternet.net <mailto:mattlists@rivervalleyinternet.net>> wrote:
On 3/19/22 6:50 PM, Michael Thomas wrote:
On 3/19/22 3:47 PM, Matt Hoppes wrote:
It has "features" which are at a minimum problematic and at a maximum show stoppers for network operators.
IPv6 seems like it was designed to be a private network communication stack, and how an ISP would use and distribute it was a second though. What might those be? And it doesn't seem to be a show stopper for a lot of very large carriers.
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
We have to sniff the packets to figure out the MAC so that we can authenticate the client and/or assign an IP address to the client properly.
It depends how you're managing the network. If you're running PPPoE you can encapsulate in that. But PPPoE is very 1990 and has its own set of problems. For those running encapsulated traffic, authentication to the modem MAC via DHCP that becomes broken. And thus far, I have not seen a solution offered to it.
Secondly - and less importantly to deployment, IPv6 also provides a layer of problematic tracking for advertisers. Where as before many devices were behind a PAT, now every device has a unique ID -- probably for the life of the device. Marketers can now pinpoint down not just to an IP address that identifies a single NAT interface, but each individual device. This is problematic from a data collection standpoint.
This is going to be one of the big things the US Federal govt requirements for agencies to meet the IPv6-only benchmarks will need. Solutions and products are going to have to mature quickly for agencies to hit 80% IPv6-only by end of FY25. On Sun, Mar 20, 2022 at 4:38 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:
On Mar 20, 2022, at 07:17, Lady Benjamin Cannon of Glencoe <lb@6by7.net> wrote:
It seems sketchy to me to even retain client MAC information, no? Genuine question.
Didn’t we go to a distinct unique identifier system for this very reason?
Am I in the 1990s here or?
We’re just handing out addresses to UEs and things seem to work fine. For me personally, I find the notation of v6 to be very unasthetic, so I tend to just conceal it from myself now.
Correct me if I’m wrong, but it sounds like you’re viewing this from a service provider perspective, in which case everything you’ve said is basically correct.
However, the enterprise world is very different. Right, wrong, or otherwise, many enterprises feel a strong compulsion to have very strict control over addressing and relatively direct accountability of “x address = y employee” (regardless of whether that’s actually true or not).
In those environments, yes, IPv6 does present a learning curve and some additional challenges. They are not insurmountable and if you were starting from scratch needing to build your enterprise on IPv6, it would actually be less difficult than IPv4. IPv4, however, has the advantage of well trodden paths for enterprise solutions in this space. IPv6 will get there as more enterprises start to deploy IPv6, but right now both sides of that process suffer from the classic chicken/egg problem. The problem is slow to get solved because there are no chickens asking for a solution. Chickens aren’t asking for it because there are no eggs to create chickens that need IPv6.
Owen
-LB
Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME <https://alexmhoulton.wixsite.com/6x7networks>
FCC License KJ6FJJ
On Mar 19, 2022, at 3:56 PM, Matt Hoppes < mattlists@rivervalleyinternet.net> wrote:
On 3/19/22 6:50 PM, Michael Thomas wrote:
On 3/19/22 3:47 PM, Matt Hoppes wrote:
It has "features" which are at a minimum problematic and at a maximum show stoppers for network operators.
IPv6 seems like it was designed to be a private network communication stack, and how an ISP would use and distribute it was a second though.
What might those be? And it doesn't seem to be a show stopper for a lot of very large carriers.
Primarily the ability to end-to-end authenticate end devices. The primary and largest glaring issue is that DHCPv6 from the client does not include the MAC address, it includes the (I believe) UUID.
We have to sniff the packets to figure out the MAC so that we can authenticate the client and/or assign an IP address to the client properly.
It depends how you're managing the network. If you're running PPPoE you can encapsulate in that. But PPPoE is very 1990 and has its own set of problems. For those running encapsulated traffic, authentication to the modem MAC via DHCP that becomes broken. And thus far, I have not seen a solution offered to it.
Secondly - and less importantly to deployment, IPv6 also provides a layer of problematic tracking for advertisers. Where as before many devices were behind a PAT, now every device has a unique ID -- probably for the life of the device. Marketers can now pinpoint down not just to an IP address that identifies a single NAT interface, but each individual device. This is problematic from a data collection standpoint.
Michael Thomas wrote:
So out of the current discussions a lot of people have claimed that ipv6 is bloated or suffers from second system syndrome, etc.
IPv6 optional header chain, even after it was widely recognized that IPv4 options are useless/harmful and were deprecated is an example of IPv6 bloat. Extensive use of link multicast for nothing is another example of IPv6 bloat. Note that IPv4 works without any multicast.
So I decided to look at a linux kernel (HEAD I assume) and look at the differences between the v6 and v4 directories.
See above. That is an improper way to evaluate IPv6 bloat. An example of second system syndrome of over-engineering without bloat is various timing parameters specified for ND, even though timing requirements are different depending on link types, which means there can be no standard timing parameters applicable to all the link types. Another example of over-engineering is SLAAC to *statefully* maintain address configuration state in fully distributed way only to promote inconsistencies requiring DAD. An example of under-engineering is lack of the following consideration of rfc791: The number 576 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information. For example, this size allows a data block of 512 octets plus 64 header octets to fit in a datagram. The maximal internet header is 60 octets, and a typical internet header is 20 octets, allowing a margin for headers of higher level protocols. as IPv6 optional headers can be arbitrary lengthy, it is not guaranteed that 512B DNS message can be sent over UDP over IPv6. And, there are a lot lot lot more. Masataka Ohta
On Mar 20, 2022, at 22:41, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Michael Thomas wrote:
So out of the current discussions a lot of people have claimed that ipv6 is bloated or suffers from second system syndrome, etc.
IPv6 optional header chain, even after it was widely recognized that IPv4 options are useless/harmful and were deprecated is an example of IPv6 bloat.
Extensive use of link multicast for nothing is another example of IPv6 bloat. Note that IPv4 works without any multicast.
Yes, but IPv6 works without any broadcast. At the time IPv6 was being developed, broadcasts were rather inconvenient and it was believed that ethernet switches (which were just beginning to be a thing then) would facilitate more efficient capabilities by making extensive use of link multicast instead of broadcast. Guess what, we are again bad at predicting the future. You have no choice when developing something but to make the best guess about what will happen from the information available at the time. Turns out multicast was arguably a wrong guess, but all indications available at the time were that it was a good bet. There is still a valid argument to be made that in a switched ethernet world, multicast could offer efficiencies if networks were better tuned to accommodate it vs. broadcast. That’d be IPv4 unfriendly, but in a world where IPv4 is eventually deprecated and broadcasts are no longer necessary, the potential is there.
So I decided to look at a linux kernel (HEAD I assume) and look at the differences between the v6 and v4 directories.
See above. That is an improper way to evaluate IPv6 bloat.
An example of second system syndrome of over-engineering without bloat is various timing parameters specified for ND, even though timing requirements are different depending on link types, which means there can be no standard timing parameters applicable to all the link types.
Another example of over-engineering is SLAAC to *statefully* maintain address configuration state in fully distributed way only to promote inconsistencies requiring DAD.
SLAAC doesn’t “statefully” maintain address state in the network or in remote systems. Obviously some level of statefulness is required on each local host or it would need to repeat the address acquisition process for each unconnected frame (whether initiating a connected session or a connectionless frame). DAD is there to avoid inconsistencies and more gracefully handle situations where addresses get duplicated. IPv4 is particularly bad at this and the “over engineering” you speak of here was seen as a solution to that problem in IPv4.
An example of under-engineering is lack of the following consideration of rfc791:
The number 576 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information. For example, this size allows a data block of 512 octets plus 64 header octets to fit in a datagram. The maximal internet header is 60 octets, and a typical internet header is 20 octets, allowing a margin for headers of higher level protocols.
as IPv6 optional headers can be arbitrary lengthy, it is not guaranteed that 512B DNS message can be sent over UDP over IPv6.
It is guaranteed that a 512 octet DNS message can be sent over UDP if it does not contain extension headers. You can argue that extension headers should have been more carefully considered in RFC791, but two factors come into play there: 1. I’m not sure the idea of extension headers had been fleshed out by the time RFC791 was written. It is one of the earliest IPv6 RFCs. 2. Even with full consideration of IPv6 extension headers, I think 576 is still a reasonable MINIMUM MTU, since a minimum MTU that can account for all extension headers would exceed the common 1500 octet MTU prevalent at the time (and still relatively prevalent today). It’s clear from the text of RFC791 that this number is by definition a compromise between competing factors, wherein there is on one side the desire to keep the minimum MTU as small as possible and on the other side, the need for the minimum MTU to accommodate a reasonable size payload under the majority of circumstances. For better or worse, I think that 576 is probably as good a compromise as can be reached. So I disagree with your characterization of this as under-engineered. Owen
Owen DeLong wrote:
IPv6 optional header chain, even after it was widely recognized that IPv4 options are useless/harmful and were deprecated is an example of IPv6 bloat.
Extensive use of link multicast for nothing is another example of IPv6 bloat. Note that IPv4 works without any multicast.
Yes, but IPv6 works without any broadcast. At the time IPv6 was being developed, broadcasts were rather inconvenient and it was believed that ethernet switches (which were just beginning to be a thing then) would facilitate more efficient capabilities by making extensive use of link multicast instead of broadcast.
No, the history around it is that there was some presentation in IPng WG by ATM people stating that ATM, or NBMA (Non-Broadcast Multiple Access)in general, is multicast capable though not broadcast capable, which was blindly believed by most, if not all excluding *me*, people there. It should be noted that IPv6 was less bloat because ND abandoned its initial goal to support IP over NBMA.
Turns out multicast was arguably a wrong guess, but all indications available at the time were that it was a good bet.
See above.
There is still a valid argument to be made that in a switched ethernet world, multicast could offer efficiencies if networks were better tuned to accommodate it vs. broadcast.
That is against the CATENET model that each datalink only contain small number of hosts where broadcast is not a problem at all. Though, in CERN, single Ethernet with thousands of hosts was operated, of course poorly, it was abandoned to be inoperational a lot before IPv6, which is partly why IPv6 is inoperational. Masataka Ohta
Admitting to not having read every message in these threads, but would like to highlight a bit of the history. IMnsHO, the otherwise useful history is missing a few steps. 1) The IAB selected ISO CLNP as the next version of IP. 2) The IETF got angry, disbanded, replaced, and renamed IAB. 3) On the Big-Internet list, my Practical Internet Protocol Extensions (PIPE) was an early proposal, and I'd registered V6 with IANA. I was self-funding. PIPE was cognizant of the needs of ISPs and deployment. 4) Lixia Zhang wrote me that Steve Deering was proposing something similar, and urged us to pool our efforts. That became Simple Internet Protocol (SIP). We used 64 bit addresses. We had a clear path for migration, using the upper 32-bits for the ASN and the old IPv4 address in the lower 32-bits. We had running code. 5) The IP Address Extension (IPAE) proposal had some overlapping features, and we asked them to merge with us. That added some complexity. 6) The Paul Francis (the originator of NAT) Polymorphic Internet Protocol (PIP) had some overlapping features, so we also asked them to merge with us (July 1993). More complexity in the protocol header chaining. 7) The result was SIPP. We had 2 interoperable implementations: Naval Research Labs, and KA9Q NOS (Phil Karn and me). There were others well underway. 8) As noted by John Curran, there was a committee of "powers that be". After IETF had strong consensus for SIPP, and we had running code, the "powers that be" decided to throw all that away. 9) The old junk was added back into IPv6 by committee. There was also a mention that the Linux IP stack is fairly compact and that IPv6 is somewhat smaller than the IPv4. That's because the Linux stack was ported by Alan Cox from KA9Q NOS. We gave Alan permission to change from our personal copyright to GPL. It has a lot of the features we'd developed, such as packet buffers and pushdown functions for adding headers, complimentary to BSD pullup. They made SIPP/IPv6 fairly easy to implement. On 3/22/22 10:04 AM, Masataka Ohta wrote:
Owen DeLong wrote:
IPv6 optional header chain, even after it was widely recognized that IPv4 options are useless/harmful and were deprecated is an example of IPv6 bloat.
Extensive use of link multicast for nothing is another example of IPv6 bloat. Note that IPv4 works without any multicast.
Yes, but IPv6 works without any broadcast. At the time IPv6 was being developed, broadcasts were rather inconvenient and it was believed that ethernet switches (which were just beginning to be a thing then) would facilitate more efficient capabilities by making extensive use of link multicast instead of broadcast.
No, the history around it is that there was some presentation in IPng WG by ATM people stating that ATM, or NBMA (Non-Broadcast Multiple Access)in general, is multicast capable though not broadcast capable, which was blindly believed by most, if not all excluding *me*, people there.
Both Owen and Masataka are correct, in their own way. IPv4 options were recognized as harmful. SIPP used header chains instead. But the whole idea was to speed processing, eliminating hop-by-hop. Then the committees added back the hop by hop processing (type 0). Terrible! Admittedly, I was also skeptical of packet shredding (what we called ATM). Sadly, the Chicago NAP required ATM support, and that's where my connections were located.
It should be noted that IPv6 was less bloat because ND abandoned its initial goal to support IP over NBMA.
Neighbor Discovery is/was agnostic to NBMA. Putting all the old ARP and DHCP and other cruft into the IP-layer was my goal, so that it would be forever link agnostic.
There is still a valid argument to be made that in a switched ethernet world, multicast could offer efficiencies if networks were better tuned to accommodate it vs. broadcast.
That is against the CATENET model that each datalink only contain small number of hosts where broadcast is not a problem at all. Though, in CERN, single Ethernet with thousands of hosts was operated, of course poorly, it was abandoned to be inoperational a lot before IPv6, which is partly why IPv6 is inoperational.
Yes, we were also getting a push from Fermi Labs and CERN for very large numbers of nodes per link, rather than old ethernet maximum. That's the underlying design for Neighbor Discovery. Less chatty. Also, my alma mater was Michigan State University, operating the largest bridged ethernet in the world in the '80s. Agreed, it was "inoperational". My epiphany was splitting it with KA9Q routers. Suddenly the engineering building and the computing center each had great throughput. Turns out it was the administration's IBM that had been clogging the campus. Simple KA9Q routers didn't pass the bad packets. That's how I'd become a routing over bridging convert. Still, there are data centers with thousand port switches. Also, TRILL.
William Allen Simpson wrote:
6) The Paul Francis (the originator of NAT) Polymorphic Internet Protocol (PIP) had some overlapping features, so we also asked them to merge with us (July 1993). More complexity in the protocol header chaining.
With the merger, Paul Francis was saying he was unhappy because PIP is dead. So the merger is not voluntary for him and the added complexity is technically meaningless.
IPv4 options were recognized as harmful. SIPP used header chains instead. But the whole idea was to speed processing, eliminating hop-by-hop.
Then the committees added back the hop by hop processing (type 0). Terrible!
Really? But, rfc1710 states: The SIPP option headers which are currently defined are: Hop-by-Hop Option Special options which require hop by hop processing
Admittedly, I was also skeptical of packet shredding (what we called ATM).
Packet shredding harmed router architecture, not protocols. Many routers are shredding packets internally for no good reason. Instead, ATM-centric view that "all the world will be covered by ATM and global IP could be used only over ATM" harmed protocols including IPv6 a lot.
Neighbor Discovery is/was agnostic to NBMA. Putting all the old ARP and DHCP and other cruft into the IP-layer was my goal, so that it would be forever link agnostic.
To make "IP uber alles", link-dependent adaptation mechanisms between IP and links are necessary. So, "ND uber alles" is a wrong goal.
Yes, we were also getting a push from Fermi Labs and CERN for very large numbers of nodes per link, rather than old ethernet maximum.
And the reason was that they want to use IPv4 and DECNET without being annoyed by *dual* *stack* routers!
That's the underlying design for Neighbor Discovery. Less chatty.
Just wrong requirement. Large Ethernet segments work poorly by itself. Worse, even if some L3 might be causing additional damages, the damages won't go away if IPv6 is added.
Turns out it was the administration's IBM that had been clogging the campus.
SNA? Masataka Ohta
On 3/23/22 2:25 AM, Masataka Ohta wrote:
William Allen Simpson wrote:
6) The Paul Francis (the originator of NAT) Polymorphic Internet Protocol (PIP) had some overlapping features, so we also asked them to merge with us (July 1993). More complexity in the protocol header chaining.
With the merger, Paul Francis was saying he was unhappy because PIP is dead. So the merger is not voluntary for him and the added complexity is technically meaningless.
He seemed happy at the Amsterdam 1993 meeting, but as time went on he was sidelined. Likewise, I eventually regretted having joined with the others. We lost control of the main ideas. For example, originally V6 was designed to use shortest path first interior routing. All the announcements were Link State, everything was in place. I still wince at the memory of the PARC meeting where Eric stated that RIP was good enough for V4, so it is good enough for V6. Then he was assigned to be my "co-author". So I quit. What you know as Neighbor Discovery was not the original design. Nor was RIPv6 needed. When I was giving a talk at Google 25 years later I was asked why that happened (by a then member of the IAB). A sore spot, long remembered. Committee-itis at its worst.
IPv4 options were recognized as harmful. SIPP used header chains instead. But the whole idea was to speed processing, eliminating hop-by-hop.
Then the committees added back the hop by hop processing (type 0). Terrible!
Really? But, rfc1710 states:
The SIPP option headers which are currently defined are:
Hop-by-Hop Option Special options which require hop by hop processing
Yep, that was one of the reasons I quit. Digging out my files, I'd forked my documents by July 17, 1994. (That's the last date I'd touched them, so it was before then.) RFC 1710 was later. Also, I registered IPvB with Jon Postel. These are all old nroff files, but I could hand format a bit and post things here. Not that it makes much difference today, yet some of my ideas made it into Fibre Channel and InfiniBand.
On 3/23/22 2:25 AM, Masataka Ohta wrote:
William Allen Simpson wrote:
Neighbor Discovery is/was agnostic to NBMA. Putting all the old ARP and DHCP and other cruft into the IP-layer was my goal, so that it would be forever link agnostic.
To make "IP uber alles", link-dependent adaptation mechanisms between IP and links are necessary. So, "ND uber alles" is a wrong goal.
Meant to reply to this separately. I've implemented on the order of 35+ protocols, most of them predating IP. My first IP implementation was 1979 for the Perkin-Elmer 7/16. The link layer was X.25 to talk to Merit and over Telenet (not telnet -- Telenet was a provider in those days). John Gilmore recently gave a good history of the ARP origin. Note that for PPP, we also had to negotiate a link layer shim. Some folks then grabbed that effort, instead of building their own, resulting in such monstrosities as PPP over Ethernet. After so many times reinventing the wheel, IP uber alles is a better goal. Speaking as somebody familiar with the effort.
William Allen Simpson wrote:
After so many times reinventing the wheel, IP uber alles is a better goal. Speaking as somebody familiar with the effort.
I'm afraid you misunderstand my point.
John Gilmore recently gave a good history of the ARP origin.
ARP is perfectly good for CSMA/CD but not so good for CSMA/CA where broadcast/multicast is unreliable. So, with wifi, we should rely on repeated beacon from base stations for AR of the base stations and rely on unicast from clients to register them to base stations, which should act as proxy for communications between clients, which is a totally different protocol from ARP. Without such recognition today, wifi users should be suffering from some inefficiencies when link is congested, which is often the case. Other link technology should also require AR mechanism of its own. As such, performing AR with IP is not so meaningful. Worse, even DHCP, which assumes reliable broadcast, does not work so efficiently over congested wifi. Masataka Ohta
Hello Ohta-San I tried exactly what you suggested for IPv6 with RFC 8505 and 8929. But to few people in mainstream networks realize what you just said. It started long long ago with the idea to use inverse ARP for the registration, I guess it is still doable but I am not optimistic about adoption considering that v6 is a lot worse with more addresses and DAD. We are editing the piece on proxy ARP at this very moment at .11me. APs are indeed supposed to proxy both v4 and v6. What is less clear is how they form a deterministic state for that. Regards, Pascal
Le 28 mars 2022 à 15:55, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> a écrit :
William Allen Simpson wrote:
After so many times reinventing the wheel, IP uber alles is a better goal. Speaking as somebody familiar with the effort.
I'm afraid you misunderstand my point.
John Gilmore recently gave a good history of the ARP origin.
ARP is perfectly good for CSMA/CD but not so good for CSMA/CA where broadcast/multicast is unreliable.
So, with wifi, we should rely on repeated beacon from base stations for AR of the base stations and rely on unicast from clients to register them to base stations, which should act as proxy for communications between clients, which is a totally different protocol from ARP.
Without such recognition today, wifi users should be suffering from some inefficiencies when link is congested, which is often the case.
Other link technology should also require AR mechanism of its own.
As such, performing AR with IP is not so meaningful. Worse, even DHCP, which assumes reliable broadcast, does not work so efficiently over congested wifi.
Masataka Ohta
Pascal Thubert (pthubert) wrote:
I tried exactly what you suggested for IPv6 with RFC 8505 and 8929. But to few people in mainstream networks realize what you just said.
I found, theoretically by reading 802.11 specification, broadcast/multicast reliability problem and reported to IPv6 WG about 20 years ago. So, I'm pleased to know that some people recognize it as a real problem and worked on it. Thank you.
It started long long ago with the idea to use inverse ARP for the registration, I guess it is still doable but I am not optimistic about adoption considering that v6 is a lot worse with more addresses and DAD.
Aren't IP addresses are assigned from APs? Then, the APs can construct ARP table without actually running ARP or inverse ARP, I'm afraid.
We are editing the piece on proxy ARP at this very moment at .11me. APs are indeed supposed to proxy both v4 and v6. What is less clear is how they form a deterministic state for that.
An ARP table entry can be created when an IP address is assigned during registration process and destroyed if the registration is invalidated. Or, do I misunderstand anything? Masataka Ohta
Hello Ohta-san
An ARP table entry can be created when an IP address is assigned during registration process and destroyed if the registration is invalidated.
Or, do I misunderstand anything?
You're perfectly correct. This is exactly what the registration would be for. I'm concerned about its adoption that I do not see coming on Wi-Fi/ Ethernet, even for v6 (SLAAC) where the problem is a lot worse*. The IoT world already adopted the registration model, though. Millions of nodes on 802.15.4 radios are deployed to prove it works. We even redistribute RFC 8505 in routing protocols that carry host routes in IoT networks (RPL), which is how we avoid your lookup issue on a wide low power mesh network. Extending the registration to IPv4 is easy, we could even use mapped addresses and be done. But what magic will trigger attention / adoption when adoption is not showing in IPv6? Keep safe; Pascal * APs today snoop DHCP; DHCP is observable and stateful, with a lifetime that allows to clean up. So snooping it is mostly good enough there. The hassle is the SL in SLAAC which causes broadcasts and is not deterministically observable; this problem is specific to IPv6. We already have the registration to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in mainline APs and STAs.
-----Original Message----- From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sent: mardi 29 mars 2022 10:57 To: Pascal Thubert (pthubert) <pthubert@cisco.com>; nanog@nanog.org Subject: Re: IPv6 "bloat" history
Pascal Thubert (pthubert) wrote:
I tried exactly what you suggested for IPv6 with RFC 8505 and 8929. But to few people in mainstream networks realize what you just said.
I found, theoretically by reading 802.11 specification, broadcast/multicast reliability problem and reported to IPv6 WG about 20 years ago. So, I'm pleased to know that some people recognize it as a real problem and worked on it. Thank you.
It started long long ago with the idea to use inverse ARP for the registration, I guess it is still doable but I am not optimistic about adoption considering that v6 is a lot worse with more addresses and DAD.
Aren't IP addresses are assigned from APs? Then, the APs can construct ARP table without actually running ARP or inverse ARP, I'm afraid.
We are editing the piece on proxy ARP at this very moment at .11me. APs are indeed supposed to proxy both v4 and v6. What is less clear is how they form a deterministic state for that.
An ARP table entry can be created when an IP address is assigned during registration process and destroyed if the registration is invalidated.
Or, do I misunderstand anything?
Masataka Ohta
On 3/29/22 5:21 AM, Pascal Thubert (pthubert) via NANOG wrote:
* APs today snoop DHCP; DHCP is observable and stateful, with a lifetime that allows to clean up. So snooping it is mostly good enough there. The hassle is the SL in SLAAC which causes broadcasts and is not deterministically observable; this problem is specific to IPv6. We already have the registration to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in mainline APs and STAs.
[heavy sigh] All of these things were well understood circa 1992-93. That's why the original Neighbor Discovery was entirely link state. ND link state announcements handled the hidden terminal problem. (That is, where node A can hear node B, node B can hear node C, and node C can hear node A, but A cannot hear C.) ND LSAs are/were flexible enough to handle both AP (cell) and mesh (AMPR) networks. Thus, it was not reliant on central Access Points. We envisioned mesh networks were the future. Each node should handle its own discovery and routing. SLAAC is bloat. RIPv6 is bloat. DHCPv6 is bloat. Those are reasons operators have been complaining about IPv6.
On 3/31/22 7:44 AM, William Allen Simpson wrote:
[heavy sigh]
All of these things were well understood circa 1992-93.
That's why the original Neighbor Discovery was entirely link state.
ND link state announcements handled the hidden terminal problem.
Also, it almost goes without saying that the original ND tried to handle the near-far problem. For example, where I'm talking to a far away AP streaming to the TV in front of me. At my home, I've had to wire the TV. Streaming to the AP, then the AP sending the same traffic over the same wireless band to the TV caused lots of drops and jitter. The near-far problem can be detected and solved. That's the reason for the Metric field. Furthermore, one of the messages in this thread mentioned trying to backport v6 features to v4. We've already been down that road. IPsec and MobileIP were developed for v6. After quitting the v6 project(s), I'd backported both of them to v4. Like v6, then they were assigned to others who ruined them. Committee-itis at its worst.
Fun, I had a parallel experience with NEMO that I implemented in IOS. But I mostly read the fate of MIP and NEMO as a lack of ask. Which is similar to the lack of desire today for the uplifts we made to IPv6 as a whole, and ND in particular. Anyway, RPL has a lot to do with what we learned there, including the abstract objective function that yields the metrics you are talking about, typically including things like ETX/ETX^2, RSSI and LQI. So yes, things that make sense eventually emerge. Keep safe. Pascal
-----Original Message----- From: William Allen Simpson <william.allen.simpson@gmail.com> Sent: jeudi 31 mars 2022 14:10 To: nanog@nanog.org Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: IPv6 "bloat" history
On 3/31/22 7:44 AM, William Allen Simpson wrote:
[heavy sigh]
All of these things were well understood circa 1992-93.
That's why the original Neighbor Discovery was entirely link state.
ND link state announcements handled the hidden terminal problem.
Also, it almost goes without saying that the original ND tried to handle the near-far problem. For example, where I'm talking to a far away AP streaming to the TV in front of me.
At my home, I've had to wire the TV. Streaming to the AP, then the AP sending the same traffic over the same wireless band to the TV caused lots of drops and jitter.
The near-far problem can be detected and solved. That's the reason for the Metric field.
Furthermore, one of the messages in this thread mentioned trying to backport v6 features to v4.
We've already been down that road. IPsec and MobileIP were developed for v6. After quitting the v6 project(s), I'd backported both of them to v4. Like v6, then they were assigned to others who ruined them. Committee-itis at its worst.
Don't sigh! You envisioned it and we built it, William. We have IPv6 mesh networks with thousands on nodes per mesh deployed around you. The standard is called WI-SUN. WI-SUN totals millions of nodes deployed in North America; so what you described cannot not only be envisioned as you did, it can be built and deployed at scale, even on low power far reach wireless. The core L3 components for Wi-SUN are RFC 8505 which is your link state ND thingy, RFC 6550 that does the routing over what OSPF called P2MP and which really means non-transitive, and RFC 9010 that redistribute the former in the latter. We are now working on registering multicast, anycast and prefixes in the same model. It's just that the wired world (including operators) are mostly unaware of these capabilities. Whether they are even interested is not a given either. Louis the XVth said "après moi le déluge". I read pretty much the same thing on the list in the recent days as a migration strategy. Certainly, complaining from a comfort zone is a lot easier than acting out to solve the problem. "La critique est aisée mais l'art est difficile" is another good one. I claim that bashing at the IETF for IPv6 as it was 20 years ago is unfair and that a little refresh / resync is in order. If what we produced since in an attempt to solve the issues you describe can help, then ask for it, amend it, say something, so something. Today, decoupling the L1/2 (physical) network from the L3 abstractions of subnet and link is totally doable. This yields a world of possibilities for deployments. For all those (or the very few) who care, there's https://datatracker.ietf.org/doc/html/draft-thubert-6man-ipv6-over-wireless-... Keep safe; Pascal PS : When I say that DHCP mostly does the trick is not that I like it, but that customers (think EVPN) are reasonably happy with the result, while SLAAC is a lot worse for pretty much the whole collection of its design points, and cherry on the cake, the onlink model.
-----Original Message----- From: William Allen Simpson <william.allen.simpson@gmail.com> Sent: jeudi 31 mars 2022 13:44 To: nanog@nanog.org Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: IPv6 "bloat" history
* APs today snoop DHCP; DHCP is observable and stateful, with a lifetime
On 3/29/22 5:21 AM, Pascal Thubert (pthubert) via NANOG wrote: that allows to clean up. So snooping it is mostly good enough there. The hassle is the SL in SLAAC which causes broadcasts and is not deterministically observable; this problem is specific to IPv6. We already have the registration to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in mainline APs and STAs.
[heavy sigh]
All of these things were well understood circa 1992-93.
That's why the original Neighbor Discovery was entirely link state.
ND link state announcements handled the hidden terminal problem. (That is, where node A can hear node B, node B can hear node C, and node C can hear node A, but A cannot hear C.) ND LSAs are/were flexible enough to handle both AP (cell) and mesh (AMPR) networks.
Thus, it was not reliant on central Access Points. We envisioned mesh networks were the future. Each node should handle its own discovery and routing.
SLAAC is bloat.
RIPv6 is bloat.
DHCPv6 is bloat.
Those are reasons operators have been complaining about IPv6.
Pascal Thubert (pthubert) wrote:
You're perfectly correct. This is exactly what the registration would be for. I'm concerned about its adoption that I do not see coming on Wi-Fi/ Ethernet, even for v6 (SLAAC) where the problem is a lot worse*.
You can't expect people still working primarily on v6 have much sense of engineering.
* APs today snoop DHCP; DHCP is observable and stateful, with a lifetime that allows to clean up. So snooping it is mostly good enough there. The hassle is the SL in SLAAC which causes broadcasts and is not deterministically observable; this problem is specific to IPv6. We already have the registration to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in mainline APs and STAs.
As broadcast/multicast packets are first sent to APs as unicast packets with ACKs, snooping by APs should be reliable at L2. So, by snooping DAD, which is ugly, ARP table can be constructed. A problem, however, is that there is no ACK above L2, that is, there is no end to end ACK, which means, if something goes wrong above L2, the result can be weird. Masataka Ohta
Pascal Thubert (pthubert) wrote:
You're perfectly correct. This is exactly what the registration would be for. I'm concerned about its adoption that I do not see coming on Wi-Fi/ Ethernet, even for v6 (SLAAC) where the problem is a lot worse*.
You can't expect people still working primarily on v6 have much sense of engineering.
That includes me
* APs today snoop DHCP; DHCP is observable and stateful, with a lifetime that allows to clean up. So snooping it is mostly good enough there. The hassle is the SL in SLAAC which causes broadcasts and is not deterministically observable; this problem is specific to IPv6. We already have the registration to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in mainline APs and STAs.
As broadcast/multicast packets are first sent to APs as unicast packets with ACKs, snooping by APs should be reliable at L2.
Well, up to the N retries. After that the stack is not even aware that the multicast was not delivered. Oh but that's just the beginning of the story; yes we mostly can form an initial state and it mostly appears to work and people are mostly satisfied. And then you realize: - there's no way to know how long the device will you that address - there's no way to know how many addresses the device will form - there's no way to know how many addresses the device has already formed and which (at least MLD can do that) - there's no clean way to know is an address is still in use (e.g., without reviving it in the host stack) - there's no way to know which is the most recent location of the address (unless you have a fine time distribution and that costs) - there's no way to know if 2 locations are OK (anycast) - there's no way to know for sure that the claimer is the owner Snooping DHCP you expect: - one address per MAC (that's it's pretty limiting but that protects the network) - A MAC address or least a unique ID to differentiate duplicates (but not recognize a thief) - An upper bound for the state lifetime based on the lease Certainly a bad guy doing impersonation and DOS can play havoc in such network, but at least between good guys we get something we can operate. I'm not saying that snooping DHCP is fully deterministic but it's orders of magnitude better than snooping SLAAC when it comes to forming a state like an association than SLAAC. Knowing that you base things like EVPN on such state, using SLAAC is building on sand. Ideally you'd want: - a negotiated contract for a number of addresses with a lifetime, etc - a provable ownership so we route to the legitimate owner and can do SAVI - a sense of mobility so we can route the packets to the latest location - a sense of anycast vs unicast so we can install routing properly based on that - the capability to indicate whether the address should be redistributed, a sense of weight in ECMP, etc... We've done just that, and with that, we're effectively providing a deterministic state that we can redistribute in routing or ARP/ND proxy. In the case of EVPN that gives this: https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-sig... Then again, retrofitting the ND registration for IPv4 addresses is piece of cake, but IPv4 is DHCP only and the pain does not really feel; so people may not be inclined to make the steps for IPv4. To be seen.
So, by snooping DAD, which is ugly, ARP table can be constructed.
A Proof of Concept, yes, an enterprise-class-quality network, no. If you try, start populating the hot-line before you turn the lights on 😊
A problem, however, is that there is no ACK above L2, that is, there is no end to end ACK, which means, if something goes wrong above L2, the result can be weird.
Yes, and all the other things above. E.g., a DAD coming from the wire that is sent over the wireless is not deterministically delivered and a duplicate is often missed. I do not need to continue the endless list do I? Keep safe; Pascal
Masataka Ohta
Pascal Thubert (pthubert) wrote:
You can't expect people still working primarily on v6 have much sense of engineering.
That includes me
Sorry for confusion. I mean "people still working primarily on v6" are people who insist on IPv6 and ND as is, because any required repair on it would delay the day when IPv6 is fully deployed. Worse, actually, though they insist packet format stay same, semantics has been randomly changing a lot as they wish.
As broadcast/multicast packets are first sent to APs as unicast packets with ACKs, snooping by APs should be reliable at L2.
Well, up to the N retries. After that the stack is not even aware that the multicast was not delivered.
That is a unicast problem. But, I understand your point. That is, though it can be remedied by upper layer ACKs, there can be NACKs but no ACKs for DAD.
Oh but that's just the beginning of the story;
Yup.
yes we mostly can form an initial state and it mostly appears to work and people are mostly satisfied. And then you realize:
- there's no way to know how long the device will you that address
With some interval, an AP can unicast fake DAD to the device, I think, though it wastes power to do so.
- there's no clean way to know is an address is still in use (e.g., without reviving it in the host stack)
See above, though I don't think it clean.
- there's no way to know which is the most recent location of the address (unless you have a fine time distribution and that costs)
Yup.
- there's no way to know if 2 locations are OK (anycast)
If you mean IPv6 anycast to allow 2 or more hosts sharing an anycast address, it is just broken not useful for any purpose and ignored. Instead, IPv4 style anycast is widely deployed for IPv6.
- there's no way to know for sure that the claimer is the owner
You may use IPSEC, though securely configuring security key for IPSEC is at least as difficult as securely configuring address without IPSEC, which means requiring cryptographic security for DHCP is a bad idea.
Certainly a bad guy doing impersonation and DOS can play havoc in such network, but at least between good guys we get something we can operate.
I'm sure there are a lot of security holes in or around IPv6 I haven't noticed yet.
I'm not saying that snooping DHCP is fully deterministic but it's orders of magnitude better than snooping SLAAC when it comes to forming a state like an association than SLAAC.
Of course.
So, by snooping DAD, which is ugly, ARP table can be constructed.
A Proof of Concept, yes, an enterprise-class-quality network, no. If you try, start populating the hot-line before you turn the lights on
I merely said "constructed", which does not imply "maintained".
E.g., a DAD coming from the wire that is sent over the wireless is not deterministically delivered and a duplicate is often missed.
Even with a single AP, as DAD to terminals is multicast (from the AP) and unreliable, duplicate is often missed.
I do not need to continue the endless list do I?
If you think people still working primarily on v6, with my meaning, have much sense of engineering, you should. Masataka Ohta
Hello Ohta-san
- there's no way to know if 2 locations are OK (anycast)
If you mean IPv6 anycast to allow 2 or more hosts sharing an anycast address, it is just broken not useful for any purpose and ignored.
One case I have in mind is when one wants to bundle multiple physical interfaces as one logical P2MP interface that reaches different routers, e.g., for server multihoming. There's a single owner and a single address, but it is presented to both routers on different physical interfaces and can be routed to any of those. Then the routers inject the address in some overlay and may fight unless they realize that they work on behalf of the same end point. Basically I'm talking about a proper L3 abstraction for cases where LAG / Etherchannel are used today. K8S needs a unique IP like that.
Instead, IPv4 style anycast is widely deployed for IPv6.
I guess you mean the one we configure on a server loopback for load balancing? Certainly. The end result is the same for the routing (weighted ECMP) so for all I know we can use the same signals. Keep safe; Pascal
participants (10)
-
Crist Clark -
Enno Rey -
Lady Benjamin Cannon of Glencoe -
Masataka Ohta -
Matt Hoppes -
Michael Thomas -
Owen DeLong -
Pascal Thubert (pthubert) -
Tom Beecher -
William Allen Simpson