Ray Soucy wrote:
I don't really feel I was trying to take things out of context, but the full quote would be:
"If there were consensus that delegating a prefix of sufficient size via DHCPv6 PD of a sufficient size is an acceptable substitute for stateful IPv6 addressing in the environments that currently insist on stateful DHCPv6 addressing, then it would make sense to implement it. In that scenario, Android would still not implement DHCPv6 NA, but it would implement DHCPv6 PD."
To me, that's essentially saying:
"EVEN IF we decided to support DHCPv6-PD, and that's a big IF, we will never support stateful address assignment via DHCPv6."
This rings especially true when compared against the context of everything else you've written on the subject.
I think that's how most others on this list would read it as well.
If that isn't what you meant to say, then I'm sorry. I'm certainly not trying to put words in your mouth.
I still feel that it's a very poor position to take.
Given that you don't speak for Google on the subject, if you're not the decision maker for this issue on Android, could you pull in the people at Google who are, or at least point us to them?
A lot of us would like the chance to make our case and expose the harm that Android is doing by not supporting DHCPv6.
I think the Android team is very overconfident in their ability to shape the direction of IPv6 adoption, especially with years old Android releases being still in production and it taking incredibly long for changes to trickle down through the Android ecosystem.
That delay is also why we have a hard time accepting the mindset that IF you see a need for it in the future you'll add it. That will be 4 to 8 years too late.
So the flip side of that point is; how many decades does it take to trickle things through the operational networks? Having seen this first hand at the operator, infrastructure vendor and OS vendor perspectives, the general network operations community considers anything that makes Application Development harder to be "their problem". Persistent messages like "don't waste time on IPv6 development because we are only going to deploy IPv4 and I need shiny feature X NOW" caused at least one decade of delay in infrastructure products doing anything. Now we appear to be stuck in another decade of delay based on "it is not exactly the same as IPv4". Like it or not, the OS vendors actually cater to the Application Developers, as they are the ones that produce something useful to the end user. Their job is to be the intermediary between the needs of the apps, and the availability (or lack) of network resources. (FWIW: as much as people on this list don’t like them this is exactly why I made sure XP did automated IPv6 over IPv4 tunneling) Fault the OS vendors if you want to, but they are often trying to make the networks appear more capable and consistent than they really are. To a first order this is the primary "innovation" of the iPhone, in telling the carriers "no you don't get to fragment the OS or application functionality". At the end of the day though, N = 1 is the most likely result of an NA deployment today. Once that engrained in the next generation of network operators, they will do everything they can to resist change, because their security architecture and all their tools assume N = 1 (or are we already there?). Taking the opportunity of change to also change the mindset toward PD allows N > 1. Enforcing an NA model where N > 1 eventually fails as N blows out the ND cache. Tony
On Wed, Jun 10, 2015 at 12:29 PM, Lorenzo Colitti <lorenzo@colitti.com> wrote:
On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams <jeffm@iglou.com> wrote:
Then you need to be far more careful about what you say. When you said "Android would still not support..." you, very clearly, made a statement of product direction for a Google product.
Did you intentionally leave the "in that scenario," words that came right before the ones you quoted?
How does a sentence that says "in that scenario, android would <X>" constitute a statement of direction?
-- Ray Patrick Soucy Network Engineer University of Maine System
T: 207-561-3526 F: 207-561-3531
MaineREN, Maine's Research and Education Network www.maineren.net