On Fri, Oct 16, 2015 at 12:46 AM, Baldur Norddahl wrote:
> Yes but Android refuses to do IPv6 if there is any DHCPv6 on the network.
> It is a bug.
>
That would indeed be a bug, but I'm not aware of such a bug. As long as the
network provides SLAAC as well as DHCPv6, IPv6 should work. If anyone
On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams 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 scenari
On Thu, Jun 11, 2015 at 12:35 AM, Tore Anderson wrote:
> > And that's not counting future applications that can take
> > advantage of multiple IP addresses that we haven't thought of yet, and
> that
> > we will have if we get stuck with
> >
> there-are-more-IPv6-addresses-in-this-subnet-than-grai
pointing to see that this is the position of Google.
>
>
> On Wed, Jun 10, 2015 at 10:58 AM, Lorenzo Colitti
> wrote:
>
>> On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy wrote:
>>
>>> Actually we do support DHCPv6-PD, but Android doesn't even support
>>
On Wed, Jun 10, 2015 at 10:25 PM, George, Wes
wrote:
> The reality is that this whole argument is needlessly conflating multiple
> things in a way that isn't helpful, so I'm going to try to break this into
> pieces in order to make forward progress and try to get us away from what
> is devolving
On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy wrote:
> Actually we do support DHCPv6-PD, but Android doesn't even support DHCPv6
> let alone PD, so that's the discussion here, isn't it?
>
It is possible to implement DHCPv6 without implementing stateful address
assignment.
If there were consensus
On Wed, Jun 10, 2015 at 9:31 PM, Tore Anderson wrote:
> In particular comment 105 is illuminating. Android is apparently fully
> on-board with mobile carriers' desire to break tethering, even going so
> far as to implement a feature whose *sole purpose* is to break
> thethering.
>
> Yet, at the s
On Wed, Jun 10, 2015 at 8:35 PM, Ray Soucy wrote:
> In practice, your device will just not be supported.
>
> As you pointed out, there isn't anything that forces adoption of IPv6
> right now.
>
It's certainly a possibility for both sides in this debate to say "my way
or the highway", and wait an
On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer wrote:
> Seems to me that N will vary depending on what you are trying to do.
Remember, what I'm trying to do is avoid user-visible regressions while
getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no
buts, no requests to the n
On Wed, Jun 10, 2015 at 5:31 PM, Sander Steffann wrote:
> I can also see more deployment issues (much more state in the routers for
> all those PDs, needing huge amounts of /64s (or larger) to be able to deal
> with a few hundred/thousand clients) but it would be very nice if this was
> possible
On Wed, Jun 10, 2015 at 4:13 PM, Karl Auer wrote:
> You need as many as you need. Request them. Worry about it if you don't
> get them. This is exactly what happens when N=1, BTW. A DHCPv6 server is
> almost certainly not going to have an upper limit that significantly
> crimps your style...
Ok
On Wed, Jun 10, 2015 at 3:49 PM, Jon Bane wrote:
> Seriously, this is how you are going to respond? You are claiming you
> know what is best for everyone and I am telling you that I know is best for
> MY network. Who are you to even begin to understand my requirement or
> presume to know them be
On Wed, Jun 10, 2015 at 3:38 PM, Tony Hain wrote:I
claim that there is a platform bug, because there is never a reason to
>
> ignore the WiFi RA. Use the other flag to set a preference if that is
> needed, but ignoring the RA just breaks things in unexpected ways. LC has
> did a hand-wave that the
On Wed, Jun 10, 2015 at 2:36 PM, Hugo Slabbert wrote:
> Pardon my ignorance as I don't currently have field experience with
>> 464xlat, but my understanding of the technique is that it is (for the most
>> part) dependent on the network cooperating (by providing a DNS64 and NAT64)
>> for it to wor
On Wed, Jun 10, 2015 at 12:37 PM, Karl Auer wrote:
> RFC 3315 says you just chuck in multiple IA_NA (or IA_TA) options. The
> server will respond with multiple addresses.
>
> And if a device makes a second (, third, fourth, ..) request with a
> different DUID, it'll get a second (,third, fourth,.
On Wed, Jun 10, 2015 at 12:26 PM, Jon Bane wrote:
>
> DHCPv6 - RFC3315 - Category: Standards Track
> 464XLAT - RFC6877 - Category: Informational
>
Ooo, that's fun, can I play too?
BGP - RFC 4271 - DRAFT STANDARD
USM for SNMPv3 - RFC 3414 - INTERNET STANDARD
On Wed, Jun 10, 2015 at 6:56 AM, Owen DeLong wrote:
> At the end of the day, I see Androids refusal to implement DHCPv6 as about
> the same level of stupidity as Apple’s refusal to implement 464XLAT in iOS.
>
Based on the facts, you could could just as well say that Apple is trying
to advance th
On Wed, Jun 10, 2015 at 3:20 AM, Ray Soucy wrote:
> Clients should support a verity of methods and let network operators choose
> the solution that fits the environment. The whole premise for not
> supporting DHCPv6 seems to be that mobile networks don't need it, but that
> totally ignores 802.1
On Tue, Jun 9, 2015 at 12:14 PM, Paul B. Henson wrote:
> https://code.google.com/p/android/issues/detail?id=32621
>
> It looks like one developer simply refuses to implement it because if he
> did there might be a scenario where somebody might not be able to tether
> 8-/?
That sounds pretty stu
On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong wrote:
> Moving them to IPv6 and hoping that enough of the content providers
> move forward fast enough to minimize the extent of the LSN deployment
> required.
The problem here is not content, it's access. Look at World IPv6 day.
What percentage of
On Tue, May 10, 2011 at 11:22 AM, Owen DeLong wrote:
> In other words, Igor can't turn on records generally until there are
> 182,001 IPv6-only users that are broken from his lack of records.
>
There will be no IPv6-only users. There will only be users with better IPv6
connectivity tha
21 matches
Mail list logo
