24 ms·

Android’s IPv6 Is Still Broken

108 points by altmind 6y ago

vetinari 6y ago
> Android still has a broken IPv6 implementation in 2020. By design. They are not going to fix it. There are a couple of valid arguments from Google and Lorenzo Colitti, but they are pretty weak. Any care to substantiate, why they are weak? I'm going to substantiate, why their argument is strong: 1) With DHCPv6, the network operator can force your device to obtain only single IP address. With SLAAC, you can invent your own, any amount you want, it just has to be within the same subnet; the /64, smallest subnet, is pretty huge. 2) For tethering with IPv6, you need multiple IP addresses. You cannot do NAT as you do with IPv4. Therefore, with IPv6, telcos could disable the tethering function of the phones / charge extras, just by suitably configuring their network. It is obvious, that the major supplier of mobile OS won't allow doing that. Hence, no DHCPv6.
- steerablesafe 6y ago
  > 2) For tethering with IPv6, you need multiple IP addresses. You cannot do NAT as you do with IPv4. I definitely don't want to see NAT with IPv6, but what makes it impossible?
  - garaetjjte 6y ago
    It's possible. https://tools.ietf.org/id/draft-mrw-nat66-00.html https://tools.ietf.org/id/draft-mrw-nat66-00.html https://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/ch18s04.html https://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/ch18s04.html
    - elp 6y ago
      Its also in active use by some styles of server load balancers. Keepalived in nat mode is one that springs to my mind. The "nat is evil" objection was a moral high horse in the IETF around the time that Android adopted this policy. They may have a point but its largely irrelevant in the real world.
    - vetinari 6y ago
      Note that the IETF draft expired 9 years ago. Yes, Cisco tried, but it went nowhere.
    - qalmakka 6y ago
      NAT66 is indeed possible, and it actually happened to me to use it, but it's really ugly and clunky to use. This is mostly because you are forced to use ULAs, which almost every IP stack by default rightfully considers as private addresses (see RFC 3484). So, if a host has a valid IPv4 route for 0.0.0.0/0 and one for the IPv6 internet that refers to an ULA, its resolver will almost always prioritise the former route unless you configure it to do otherwise (i.e. on Glibc you can change how getaddrinfo() works by editing its label table in /etc/gai.conf).
      - joecool1029 6y ago
        Since running wireguard with algo.sh seems to be popular now, this is the situation you'll end up in with most ipv6 supporting cloud hosting providers. Digital Ocean only gives 16 ipv6 addresses to the best of my knowledge, others are probably limited to only 1.
        ninjaguardsheep 6y ago
        I moved from Digital Ocean to Hetzner for my personal VPSes recently. One of the reasons was that Hetzner assigns ipv6 addresses in /64 blocks. Rent an ipv6 enabled vps: get a /64. Rent an additional "floating ip": get a /64.
        amaccuish 6y ago
        I moved from OWH because they only assigned a /128 to VPSes, so you're sharing a /64 with other servers. That was problematic because I run my own email server, and blacklists for IPv6 tend to be specific to a /64, meaning neighbouring servers landed my own server on blacklists (i.e. they blanket blacklist the whole /64). And obvs cloud providers sadly host a lot of spammers. In the end, since OVH even after being asked for years offer no option for /64s on VPSes, I moved to Hetzner, where a VPS gets it's own /64, so only I am responsible for my mail server's reputation.
        Avamander 6y ago
        I just recently had the same issue, I really don't understand why the fsck they're doing that s*. Don't they have billions of IPv6 addresses?
- barbegal 6y ago
  > With DHCPv6, the network operator can force your device to obtain only single IP address. So if your network admin does that, surely they have good reason, they basically want to stop you using 464xlat. Any good network admin should allow a device to ask for as many IPv6 addresses as it needs. Or is there a reason why that is not possible? I think IPv6 is quite complicated, people don't fully understand it (it's not the same as IPv4 with a bigger address space) which means lots of conversations like this where it seems easy to just implement IPv6 but the nuances of the protocol mean it isn't. There is also lots of code that is broken because of this same lack of understanding meaning more workarounds to get everything to work.
  - vetinari 6y ago
    > Any good network admin should allow a device to ask for as many IPv6 addresses as it needs. Or is there a reason why that is not possible? Business. You can extract more money from customers (we are talking telcos there, not your local network). IPv6 is in some aspects simpler, as it removes warts that IPv4 has. Many issues with deployment are not because IPv6 is complicated, but different.
- zamadatix 6y ago
  1 & 2 are related and false. It's nice to have multiple addresses but nothing about v6 says you can't tether in the same way as you did on v4 it's just simpler to avoid if you can. That being said these arguments are very narrow focused anyways and that's the real reason they are weak - phones connect to more than just the telco provider which is what the article covers.
- joecool1029 6y ago
  >Therefore, with IPv6, telcos could disable the tethering function of the phones / charge extras, just by suitably configuring their network. Most carriers count tethering traffic from packets received with a TTL decremented by 1, whether or not you NAT it is irrelevent. This was the case for ipv4 and looks to be the case for ipv6 thanks to this very recent commit: https://github.com/aosp-mirror/platform_frameworks_base/commit/aa8cecec810466f60452bdb0df0f4f6e341d5cd2 https://github.com/aosp-mirror/platform_frameworks_base/comm...
corty 6y ago
DHCPv6 is broken. Addresses are assigned not based on MAC addresses like in DHCPv4, but based on UUIDs. Whether the UUID is per host, hardware, boot or phase of the moon or just random is essentially random, making it totally useless for any kind of managed network. One might as well just go with the simpler alternative of using SLAAC. Any admin claiming DHCPv6 is somehow better for a managed network than the "anarchy" of SLAAC is deluding themselves. There are patches and extensions doing MAC address based assignments, but those are only sparsely supported in network hardware and software. For the configuration tasks that DHCP also is used for beyond address assignment, there are better alternatives like anycast, zeroconf and SLAAC extensions. The only thing that would make DHCP useful again in 2020 would be strong cryptographic authentication for devices, maybe tied in with 802.1x and MAC layer encryption. Therefore I think android is just ahead of the curve in getting rid of DHCPv6.
- deleted 6y ago
  [deleted]
- spystath 6y ago
  As long as the DUID does not change, though, is it really important how the DHCP address is mapped? MAC addresses can be spoofed, even randomised at every boot if one is so inclined. They are not any more unique as the DUID in the end of the day.
  - corty 6y ago
    The MAC address can be obtained from the outside of the box of your system, so deployment is "scan the MAC barcode, register for autoinstall on boot, done". "Big enterprise" deployment for which one is supposed to need DHCPv6. Also, DHCPv4 still uses MAC addresses, if one uses dual stack as opposed to v6-only, one might want to correlate the v4- and v6-address given to a device.
    - boomlinde 6y ago
      In DHCPv6 it is perfectly fine to use MAC-based DUID-LL, though, if you want to support a "figure it out from the outside of the box" use case in your product. Just as someone can choose to use DUID-LLT or DUID-UUID in their DHCPv6 product, someone can not to print the MAC address and to randomize the MAC address on any basis in their DHCP (v4) product.
avian 6y ago
Is it just me or did we actually start regressing in terms of moving things off IPv4? A couple of years ago I had a working IPv6 connection at home with a static /64 delegation. I had full IPv6 connectivity at work. Since I had IPv6 connectivity on my laptop ~90% of the time I actually moved a lot of my own private services to be IPv6 only, since that helped a lot with the usual background of port scans and other random annoyances. Now I'm forced to move these things back to IPv4. My home ISP has first moved off static delegations in favor of dynamic ones via DHCPv6, and then broke IPv6 routing completely [1] and after a few weeks of me complaining still seemingly has no interest in fixing it. The place I work for now has no IPv6 connectivity and has no plans for it in the future. Many people I talk with don't believe that IPv6 is the future and I commonly hear that they have forcibly disabled it on their computers due to this or that random problem. [1] https://www.tablix.org/~avian/blog/archives/2020/05/on_missing_ipv6_router_advertisements/ https://www.tablix.org/~avian/blog/archives/2020/05/on_missi...
- magicalhippo 6y ago
  My ISP had a page about IPv6, but they've since removed it and when asked now say IPv6 is only supported by their own router box. They do DHCPv6 as well, with a single /64. Which makes IPv6 a PITA. Of course it doesn't help that a lot of software (hello pfSense) is written around the idea that everybody will get a static /56 or similar that'll never ever change. Which is a pretty silly assumption IMHO.
  - thequux 6y ago
    My ISP (Telenet in Belgium) may just be unusually good, but, while there's fairly sparse documentation on IPv6 and their DHCPv6 only gave me a /64 by default, all I needed to do to get more was to configure my router's DHCP client to request a larger delegation. I didn't need to even contact their support line. At the moment I'm only asking for a /60, because that's all I need, but I strongly suspect that a /56 or even larger is easily available.
    - deleted 6y ago
      [deleted]
Kronen 6y ago
That website is broken too
swiley 6y ago
Just another in the long list of things that’s remained broken in android for many years. If you’re worried about novice users getting stuck make defaults but don’t break things.
Jonnax 6y ago
Should we care about enterprises? It looks like the setup they want will be pretty crap for home users if that got implemented by ISPs. You won't be able to tether if ISPs / Mobile networks decide to use the DHCP to give you a single IP. This stance of Google's benefits consumers. Howv many consumers are there of mobile phones and broadband are there in the world compared to workers in a corporate LAN? I feel like the question that needs to be asked sometimes is: Will this enterprise feature negatively affect normal home users. Imagine your mobile phone network gave you 1 IPv6 address rather than a subnet. That is bad. But Google standing firm on not implementing the ability to do so, has meant that they gotta implement prefix delegation.
- Kronen 6y ago
  If you are going to be fair, the question is how many consumers are there who use tethering?
  - Jonnax 6y ago
    There are more than billion android phones. How many corporate networks are there? How many people use laptops and are outside their home and want to use their mobile network?
jrockway 6y ago
I mean, there are two sets of standards. Google picked one, the author picked the other. The other 2000 words of the article seems to be a rant about how Google makes money off of ads.
- ken 6y ago
  Isn't it more like "Google picked one, and Microsoft/Apple/IBM/Linux/*BSD/Cisco/Oracle/HP/... picked the other"? Besides Google's, the only OSs I see which support IPv6 but not DHCPv6 are VMS, Symbian, and z/OS. https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_...
lmm 6y ago
It's a bit much to call something "broken" because it won't support the configuration you want, particularly when that configuration itself could reasonably be called "broken". It sounds like DHCPv6 means giving up most of the benefits of IPv6. In which case better to migrate right than migrate twice.
JoeAltmaier 6y ago
Ok IPV6 is one of those ideas that was obsolete by the time it was deployed. 12 bytes? Why not 16? Why not a UUID for each node? No management; no guessing who's is who's. Heck, use a new one for every connection.
- poizan42 6y ago
  Without a system with prefixes every router needs to hold the next step for every single ip address in use in memory all the time and needs to be able to look them up fast.
  - JoeAltmaier 6y ago
    And today we can't do that? That's what I mean by, obsolete before it was deployed. IPV6 was designed in an age of lesser storage/higher cost memory and embedded processor power. And no, not every one. Store the ones routed thru you. That's all you need. Look them up and keep a cache.
    - poizan42 6y ago
      Every node on a local network would need to be able to know whether another node is on the local network (unless you want all traffic to go through a router). So do you send arp requests for every ip you try to contact? Distribute a list through DHCP? All upstream routers needs to know about your node. So every time someone somewhere in the world connects a new device a message gets sent up to the core routers of the internet? And the core routers needs to keep track of routing tables in the size of billions and be able to look entries up in nano seconds.
      - JoeAltmaier 6y ago
        Thanks, yes those seem like possible algorithms that would work great with today's technology. And yes, every time new traffic appears at a 'core' router, entering it into a cache would be another great algorithm. But they do that now, so no patents for us. I love it when somebody 'objects' to a plan, then proceeds to describe the solution succinctly.
eqvinox 6y ago
> "Initially, Microsoft operating systems did support SLAAC but not RDNSS, Android did not want to support DHCPv6. That meant that you couldn’t support these two operating systems on the same subnet." This is incorrect. You can run SLAAC (with or without RDNSS) and stateless DHCPv6 on the same subnet. Even more, running DHCPv6 correctly actually requires sending RAs with the O or M bit set, so you're almost doing SLAAC anyway (setting M disables SLAAC, O does not.) Sensible (= stateless) DHCPv6 is an addition to SLAAC/RDNSS to allow pushing additional config. It is not a replacement.
allarm 6y ago
> You could, of course, run both SLAAC and DHCPv6 simultaneously, but why? Because it’s what you supposed to do by design? Here’s a good thread on the IETF IPv6 working group mailing list about it: https://mailarchive.ietf.org/arch/msg/ipv6/mqa0qZvlFF8lQWjdZi8UrY7wmLk/ https://mailarchive.ietf.org/arch/msg/ipv6/mqa0qZvlFF8lQWjdZ...

108 points by altmind 6y ago

> Android still has a broken IPv6 implementation in 2020. By design. They are not going to fix it. There are a couple of valid arguments from Google and Lorenzo Colitti, but they are pretty weak. Any care to substantiate, why they are weak? I'm going to substantiate, why their argument is strong: 1) With DHCPv6, the network operator can force your device to obtain only single IP address. With SLAAC, you can invent your own, any amount you want, it just has to be within the same subnet; the /64, smallest subnet, is pretty huge. 2) For tethering with IPv6, you need multiple IP addresses. You cannot do NAT as you do with IPv4. Therefore, with IPv6, telcos could disable the tethering function of the phones / charge extras, just by suitably configuring their network. It is obvious, that the major supplier of mobile OS won't allow doing that. Hence, no DHCPv6.

steerablesafe 6y ago
> 2) For tethering with IPv6, you need multiple IP addresses. You cannot do NAT as you do with IPv4. I definitely don't want to see NAT with IPv6, but what makes it impossible?
- garaetjjte 6y ago
  It's possible. https://tools.ietf.org/id/draft-mrw-nat66-00.html https://tools.ietf.org/id/draft-mrw-nat66-00.html https://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/ch18s04.html https://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/ch18s04.html
  - elp 6y ago
    Its also in active use by some styles of server load balancers. Keepalived in nat mode is one that springs to my mind. The "nat is evil" objection was a moral high horse in the IETF around the time that Android adopted this policy. They may have a point but its largely irrelevant in the real world.
  - vetinari 6y ago
    Note that the IETF draft expired 9 years ago. Yes, Cisco tried, but it went nowhere.
  - qalmakka 6y ago
    NAT66 is indeed possible, and it actually happened to me to use it, but it's really ugly and clunky to use. This is mostly because you are forced to use ULAs, which almost every IP stack by default rightfully considers as private addresses (see RFC 3484). So, if a host has a valid IPv4 route for 0.0.0.0/0 and one for the IPv6 internet that refers to an ULA, its resolver will almost always prioritise the former route unless you configure it to do otherwise (i.e. on Glibc you can change how getaddrinfo() works by editing its label table in /etc/gai.conf).
    - joecool1029 6y ago
      Since running wireguard with algo.sh seems to be popular now, this is the situation you'll end up in with most ipv6 supporting cloud hosting providers. Digital Ocean only gives 16 ipv6 addresses to the best of my knowledge, others are probably limited to only 1.
      - ninjaguardsheep 6y ago
        I moved from Digital Ocean to Hetzner for my personal VPSes recently. One of the reasons was that Hetzner assigns ipv6 addresses in /64 blocks. Rent an ipv6 enabled vps: get a /64. Rent an additional "floating ip": get a /64.
      - amaccuish 6y ago
        I moved from OWH because they only assigned a /128 to VPSes, so you're sharing a /64 with other servers. That was problematic because I run my own email server, and blacklists for IPv6 tend to be specific to a /64, meaning neighbouring servers landed my own server on blacklists (i.e. they blanket blacklist the whole /64). And obvs cloud providers sadly host a lot of spammers. In the end, since OVH even after being asked for years offer no option for /64s on VPSes, I moved to Hetzner, where a VPS gets it's own /64, so only I am responsible for my mail server's reputation.
        Avamander 6y ago
        I just recently had the same issue, I really don't understand why the fsck they're doing that s*. Don't they have billions of IPv6 addresses?
barbegal 6y ago
> With DHCPv6, the network operator can force your device to obtain only single IP address. So if your network admin does that, surely they have good reason, they basically want to stop you using 464xlat. Any good network admin should allow a device to ask for as many IPv6 addresses as it needs. Or is there a reason why that is not possible? I think IPv6 is quite complicated, people don't fully understand it (it's not the same as IPv4 with a bigger address space) which means lots of conversations like this where it seems easy to just implement IPv6 but the nuances of the protocol mean it isn't. There is also lots of code that is broken because of this same lack of understanding meaning more workarounds to get everything to work.
- vetinari 6y ago
  > Any good network admin should allow a device to ask for as many IPv6 addresses as it needs. Or is there a reason why that is not possible? Business. You can extract more money from customers (we are talking telcos there, not your local network). IPv6 is in some aspects simpler, as it removes warts that IPv4 has. Many issues with deployment are not because IPv6 is complicated, but different.
zamadatix 6y ago
1 & 2 are related and false. It's nice to have multiple addresses but nothing about v6 says you can't tether in the same way as you did on v4 it's just simpler to avoid if you can. That being said these arguments are very narrow focused anyways and that's the real reason they are weak - phones connect to more than just the telco provider which is what the article covers.
joecool1029 6y ago
>Therefore, with IPv6, telcos could disable the tethering function of the phones / charge extras, just by suitably configuring their network. Most carriers count tethering traffic from packets received with a TTL decremented by 1, whether or not you NAT it is irrelevent. This was the case for ipv4 and looks to be the case for ipv6 thanks to this very recent commit: https://github.com/aosp-mirror/platform_frameworks_base/commit/aa8cecec810466f60452bdb0df0f4f6e341d5cd2 https://github.com/aosp-mirror/platform_frameworks_base/comm...

corty 6y ago

DHCPv6 is broken. Addresses are assigned not based on MAC addresses like in DHCPv4, but based on UUIDs. Whether the UUID is per host, hardware, boot or phase of the moon or just random is essentially random, making it totally useless for any kind of managed network. One might as well just go with the simpler alternative of using SLAAC. Any admin claiming DHCPv6 is somehow better for a managed network than the "anarchy" of SLAAC is deluding themselves. There are patches and extensions doing MAC address based assignments, but those are only sparsely supported in network hardware and software. For the configuration tasks that DHCP also is used for beyond address assignment, there are better alternatives like anycast, zeroconf and SLAAC extensions. The only thing that would make DHCP useful again in 2020 would be strong cryptographic authentication for devices, maybe tied in with 802.1x and MAC layer encryption. Therefore I think android is just ahead of the curve in getting rid of DHCPv6.

deleted 6y ago
[deleted]
spystath 6y ago
As long as the DUID does not change, though, is it really important how the DHCP address is mapped? MAC addresses can be spoofed, even randomised at every boot if one is so inclined. They are not any more unique as the DUID in the end of the day.
- corty 6y ago
  The MAC address can be obtained from the outside of the box of your system, so deployment is "scan the MAC barcode, register for autoinstall on boot, done". "Big enterprise" deployment for which one is supposed to need DHCPv6. Also, DHCPv4 still uses MAC addresses, if one uses dual stack as opposed to v6-only, one might want to correlate the v4- and v6-address given to a device.
  - boomlinde 6y ago
    In DHCPv6 it is perfectly fine to use MAC-based DUID-LL, though, if you want to support a "figure it out from the outside of the box" use case in your product. Just as someone can choose to use DUID-LLT or DUID-UUID in their DHCPv6 product, someone can not to print the MAC address and to randomize the MAC address on any basis in their DHCP (v4) product.

avian 6y ago

Is it just me or did we actually start regressing in terms of moving things off IPv4? A couple of years ago I had a working IPv6 connection at home with a static /64 delegation. I had full IPv6 connectivity at work. Since I had IPv6 connectivity on my laptop ~90% of the time I actually moved a lot of my own private services to be IPv6 only, since that helped a lot with the usual background of port scans and other random annoyances. Now I'm forced to move these things back to IPv4. My home ISP has first moved off static delegations in favor of dynamic ones via DHCPv6, and then broke IPv6 routing completely [1] and after a few weeks of me complaining still seemingly has no interest in fixing it. The place I work for now has no IPv6 connectivity and has no plans for it in the future. Many people I talk with don't believe that IPv6 is the future and I commonly hear that they have forcibly disabled it on their computers due to this or that random problem. [1] https://www.tablix.org/~avian/blog/archives/2020/05/on_missing_ipv6_router_advertisements/ https://www.tablix.org/~avian/blog/archives/2020/05/on_missi...

magicalhippo 6y ago
My ISP had a page about IPv6, but they've since removed it and when asked now say IPv6 is only supported by their own router box. They do DHCPv6 as well, with a single /64. Which makes IPv6 a PITA. Of course it doesn't help that a lot of software (hello pfSense) is written around the idea that everybody will get a static /56 or similar that'll never ever change. Which is a pretty silly assumption IMHO.
- thequux 6y ago
  My ISP (Telenet in Belgium) may just be unusually good, but, while there's fairly sparse documentation on IPv6 and their DHCPv6 only gave me a /64 by default, all I needed to do to get more was to configure my router's DHCP client to request a larger delegation. I didn't need to even contact their support line. At the moment I'm only asking for a /60, because that's all I need, but I strongly suspect that a /56 or even larger is easily available.
  - deleted 6y ago
    [deleted]

Kronen 6y ago

That website is broken too

swiley 6y ago

Just another in the long list of things that’s remained broken in android for many years. If you’re worried about novice users getting stuck make defaults but don’t break things.

Jonnax 6y ago

Should we care about enterprises? It looks like the setup they want will be pretty crap for home users if that got implemented by ISPs. You won't be able to tether if ISPs / Mobile networks decide to use the DHCP to give you a single IP. This stance of Google's benefits consumers. Howv many consumers are there of mobile phones and broadband are there in the world compared to workers in a corporate LAN? I feel like the question that needs to be asked sometimes is: Will this enterprise feature negatively affect normal home users. Imagine your mobile phone network gave you 1 IPv6 address rather than a subnet. That is bad. But Google standing firm on not implementing the ability to do so, has meant that they gotta implement prefix delegation.

Kronen 6y ago
If you are going to be fair, the question is how many consumers are there who use tethering?
- Jonnax 6y ago
  There are more than billion android phones. How many corporate networks are there? How many people use laptops and are outside their home and want to use their mobile network?

jrockway 6y ago

I mean, there are two sets of standards. Google picked one, the author picked the other. The other 2000 words of the article seems to be a rant about how Google makes money off of ads.

ken 6y ago
Isn't it more like "Google picked one, and Microsoft/Apple/IBM/Linux/*BSD/Cisco/Oracle/HP/... picked the other"? Besides Google's, the only OSs I see which support IPv6 but not DHCPv6 are VMS, Symbian, and z/OS. https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_...

lmm 6y ago

It's a bit much to call something "broken" because it won't support the configuration you want, particularly when that configuration itself could reasonably be called "broken". It sounds like DHCPv6 means giving up most of the benefits of IPv6. In which case better to migrate right than migrate twice.

JoeAltmaier 6y ago

Ok IPV6 is one of those ideas that was obsolete by the time it was deployed. 12 bytes? Why not 16? Why not a UUID for each node? No management; no guessing who's is who's. Heck, use a new one for every connection.

poizan42 6y ago
Without a system with prefixes every router needs to hold the next step for every single ip address in use in memory all the time and needs to be able to look them up fast.
- JoeAltmaier 6y ago
  And today we can't do that? That's what I mean by, obsolete before it was deployed. IPV6 was designed in an age of lesser storage/higher cost memory and embedded processor power. And no, not every one. Store the ones routed thru you. That's all you need. Look them up and keep a cache.
  - poizan42 6y ago
    Every node on a local network would need to be able to know whether another node is on the local network (unless you want all traffic to go through a router). So do you send arp requests for every ip you try to contact? Distribute a list through DHCP? All upstream routers needs to know about your node. So every time someone somewhere in the world connects a new device a message gets sent up to the core routers of the internet? And the core routers needs to keep track of routing tables in the size of billions and be able to look entries up in nano seconds.
    - JoeAltmaier 6y ago
      Thanks, yes those seem like possible algorithms that would work great with today's technology. And yes, every time new traffic appears at a 'core' router, entering it into a cache would be another great algorithm. But they do that now, so no patents for us. I love it when somebody 'objects' to a plan, then proceeds to describe the solution succinctly.

eqvinox 6y ago

> "Initially, Microsoft operating systems did support SLAAC but not RDNSS, Android did not want to support DHCPv6. That meant that you couldn’t support these two operating systems on the same subnet." This is incorrect. You can run SLAAC (with or without RDNSS) and stateless DHCPv6 on the same subnet. Even more, running DHCPv6 correctly actually requires sending RAs with the O or M bit set, so you're almost doing SLAAC anyway (setting M disables SLAAC, O does not.) Sensible (= stateless) DHCPv6 is an addition to SLAAC/RDNSS to allow pushing additional config. It is not a replacement.

allarm 6y ago

> You could, of course, run both SLAAC and DHCPv6 simultaneously, but why? Because it’s what you supposed to do by design? Here’s a good thread on the IETF IPv6 working group mailing list about it: https://mailarchive.ietf.org/arch/msg/ipv6/mqa0qZvlFF8lQWjdZi8UrY7wmLk/ https://mailarchive.ietf.org/arch/msg/ipv6/mqa0qZvlFF8lQWjdZ...